Daytona Self Hosted: Setup, Limits, and Operating Costs

Do not index

Daytona self hosted means taking responsibility for an archived sandbox platform: the last public release remains available, but Daytona says its core development moved to a private codebase in June 2026. The archived Docker Compose setup is explicitly unsuitable for production. If your goal is affordable agent execution, compare that maintenance commitment with managed infrastructure such as Agent37 before committing engineering time.

This guide covers the public sandbox stack, the deployment decisions it leaves to you, and a cost model for choosing your next step. Sources and prices were checked on November 5, 2026. We reviewed the configuration; we did not deploy or benchmark Daytona in this review.

Daytona self hosted: start with the maintenance status

The official repository notice says it will receive no further updates, fixes, or releases. GitHub lists v0.190.0, published June 23, 2026, as the latest release. Its platform code carries the AGPL-3.0 license.

That leaves three different buying decisions. You can operate that archived code, evaluate an independently maintained fork, or buy a managed sandbox service. Each needs its own assessment. A public repository alone does not establish an ongoing patch stream or support commitment.

Keep the archived release's documentation beside its code. Daytona's current hosted quickstart uses a V2 API and alpha SDK versions. Copying today's SDK example into an older server deployment creates a compatibility question you must resolve before debugging your agent.

Self-hosting makes sense when controlling the platform is a requirement and someone owns its maintenance. If you mainly want to reduce execution costs, price managed options first. Our Daytona alternatives guide covers the broader provider decision; this article focuses on operating the archived stack.

What you actually have to operate

Daytona's versioned architecture documentation separates client interfaces, orchestration, and execution. An application calls an API; runners carry out sandbox operations; proxies route traffic to the right environment.

Part of the system	Its job	Your operating responsibility
API, scheduler, and proxy	Coordinate requests and route sandbox traffic	Availability, authentication, upgrades, and endpoint configuration
Runner machines	Create and manage execution environments	Capacity, isolation, disk pressure, and failure recovery
PostgreSQL and Redis	Store platform metadata and support coordination	Access controls, persistence requirements, and recovery procedures
Registry and object storage	Supply images and retain supported state	Storage growth, credentials, retention, and backups

These responsibilities exist even when one Compose command launches everything. A small installation can share a machine, but the control services and workloads still compete for its resources.

Size from your expected concurrency. Reserve capacity for the platform, then add workload memory, CPU, image layers, logs, and recovery headroom. A resource field in a sample configuration is not a measured minimum or a throughput guarantee.

Choose one representative agent job before sizing. Record its peak memory, disk growth, network destinations, and whether it needs Docker. Those measurements tell you more than an advertised sandbox startup time.

Inspect the archived Compose setup before starting it

The Docker deployment README at v0.190.0 describes a local development environment and warns against production use. Treat it as a starting point for a private evaluation.

On a separate evaluation machine with Git, Docker Engine, and Docker Compose available, inspect the versioned files first:

git clone --branch v0.190.0 --depth 1 \
  https://github.com/daytonaio/daytona.git daytona-evaluation
cd daytona-evaluation
git rev-parse HEAD
docker compose -f docker/docker-compose.yaml config --services
docker compose -f docker/docker-compose.yaml config --images

These commands fetch source and inspect configuration. They do not start the stack. Record the resolved commit so another engineer can review the same source.

Pinning the repository tag does not pin every image. The Compose file contains unversioned Daytona images and other moving image references. Establish compatible image versions or digests, retain them in your deployment configuration, and test them together. Otherwise, rebuilding the same Git checkout can pull different binaries.

The sample also contains development credentials, published service ports, privileged services, and disabled sandbox resource limits. Use a disposable host with private access and no production credentials. Plan replacement secrets, authentication, network restrictions, and enforceable limits before exposing workloads to other users. Changing a password alone does not turn the sample into a production deployment.

Once you have reviewed those settings, follow the versioned README for the private lab startup, dashboard access, and default snapshot check. It also documents wildcard proxy DNS for local development. A remote deployment needs addresses and routing that work from the browser, SDK client, proxy, and runner, not just from the host's shell.

Verify the execution boundary and network paths

The archived architecture describes runner-managed instances using Linux namespaces. Today's hosted Daytona documentation describes hardware-isolated virtual machines. Do not transfer the hosted service's isolation claims to an old Compose installation without verifying the runtime you actually deployed.

Start with a practical threat model. Will jobs come from your own developers, paying customers, or anonymous users? Can generated code reach internal databases? Which credentials enter the environment? Is each customer's filesystem separate? Your answers determine the isolation and network controls you need.

Test reachability in both directions. The client must reach the API and execution endpoints; the proxy must reach the runner; the sandbox must reach only the services its job requires. A successful dashboard login proves little about these paths.

For example, run a harmless command through the SDK from the same network your application will use. Then retrieve a file and open a preview endpoint if your product needs previews. Record failures by component so a proxy problem is not mistaken for a broken agent.

Prove recovery before adding more agents

Write a small acceptance test around the versioned sandbox lifecycle. Pin a compatible client version and point it explicitly at your deployment. Confirm that every test is reaching your own API.

Create an environment from the chosen image, execute a command, write a marker file, and retrieve it. Then test the stop and restart behavior you intend to use. Check the marker again and verify what happened to running processes. Test automatic cleanup separately so an idle timer cannot silently invalidate your persistence assumptions.

Next, restart a runner during a disposable job. Measure whether the platform detects the failure and whether your application retries without duplicating side effects. Save job identifiers and outputs outside the disposable environment when your recovery design requires it.

Back up both application data and the platform state needed to find it. Restore into a separate test installation. A backup file is useful only if you can recover the service from it within your acceptable downtime.

These are acceptance criteria to run on your infrastructure, not test results from this article. Keep the results with the deployment version. Repeat them when you change a runner image, SDK, storage configuration, or authentication setup.

Calculate the cost of owning the platform

The software license does not pay for the machines. Build a monthly budget that includes the whole deployment:

Monthly platform cost =
  control services + runner capacity + retained storage
  + backups + network charges + monitoring
  + maintenance hours x your internal hourly cost

Add model tokens and paid tools separately. They remain costs whether the execution platform is self-hosted or managed.

Use aggregate running hours when comparing sandbox services. Ten environments running six hours each consume 60 environment-hours. A host reserved for the whole month can still cost a full month even when those jobs finish quickly. Stopping a child sandbox does not necessarily release or stop billing its parent machine.

For your first estimate, make three columns: expected use, a busy week, and a recovery event. Include spare capacity for retries and image rebuilds. Track storage retained after jobs finish, since saved images, logs, and workspaces can outlive the compute that produced them.

Divide by successful jobs as well as total hours. A cheaper host that needs repeated runs may be a worse purchase for your application. Measure that with your own workload; we have no throughput benchmark that establishes a universal winner.

Compare that commitment with managed sandbox costs

Agent37, our product, supplies managed standard gVisor sandboxes and full VMs. You can run agent workloads directly without operating a Daytona control plane. This is a different infrastructure choice, not a drop-in implementation of Daytona's API.

The current pricing uses a 730-hour month for estimates. Standard compute is $0.80 per vCPU plus $0.70 per GB RAM for that period. Disk is $0.09 per GB. Full VM compute costs 2.5 times the standard compute rate; disk has the same rate.

Here is one workspace with 2 vCPU, 4 GB RAM, and 4 GB disk retained for all 730 hours:

Runtime	60 aggregate running hours	730 running hours
Standard gVisor	$0.72	$4.76
Full VM	$1.26	$11.36

The 60-hour calculations are $4.40 × 60 ÷ 730 + $0.36 for standard, and $11.00 × 60 ÷ 730 + $0.36 for VM. These are resource estimates for running an agent workspace, not sizing or pricing claims for a complete Daytona installation.

Compute bills while awake, including idle CPU time. Stopping or sleeping pauses compute charges; retained disk still bills. Auto-sleep requires configuration. Models and tools cost extra, and credits are excluded from these totals. See the billing reference.

Use standard gVisor for workloads that fit its limits. It cannot run a Docker daemon. Choose a full VM when the job requires Docker or its own Linux kernel. The Ubuntu VM template defaults to 12 GB disk, so its default 2 vCPU/4 GB RAM estimate is $12.08 for 730 running hours. That default does not prove it has enough capacity for Daytona's entire stack.

Questions to settle before choosing

Can I still self-host Daytona?

The archived public release remains available. You need to own deployment, maintenance, and compatibility testing. Evaluate any fork on its actual releases and maintenance record rather than assuming it inherits support from Daytona.

Is the supplied Compose file production-ready?

Its own README says it is unsafe for production. Use it to understand the components and evaluate privately. Production suitability requires a separate engineering assessment of your configuration and workload.

Does self-hosting eliminate sandbox charges?

It changes who bills you. You pay your infrastructure providers and fund operations yourself. Low utilization, retained storage, and maintenance can outweigh a lower compute rate.

When should I choose managed infrastructure?

Choose it when your immediate need is reliable execution and you do not need to own the sandbox control plane. If Daytona API compatibility is essential, test that requirement before switching providers.

For a cost-led evaluation, create an Agent37 sandbox, run one representative job, and record its runtime and disk needs. The instance API documentation covers lifecycle operations. Compare the observed cost with your complete self-hosting budget before committing to either route.

Daytona Self Hosted: What Still Works and What You Own