Daytona
Daytona provides programmatically managed sandboxes for running code in isolated environments. Linux containers are the default, and Linux VM, Windows, GPU, and macOS sandbox classes are available for agents and developers who need different operating systems, hardware, or isolation behavior.
| Pricing model | Pay-as-you-go per second for reserved vCPU, RAM, and disk |
|---|---|
| Pricing The headline compute price as the provider states it. Sorting ranks prices stated per vCPU over time, converted to hourly. Other pricing models sort after, unranked. | $0.0504 per vCPU-hour |
| Free while idle Whether a stopped, paused, or sleeping sandbox costs nothing. | ✓ |
| Elastic Resources flex with what the sandbox actually uses, and the bill follows: yes when the provider bills on active or observed use, no when capacity is reserved or allocated and billed while it runs. | ✕ |
| Memory snapshots Whether RAM state survives a pause and resume, not just disk. | ✓ |
| Wake on request Whether a stopped sandbox wakes automatically on inbound traffic. | – |
| Start / resume Typical time from create or resume to running. Sorting ranks stated times, converted to seconds; claims with no figure sort after, unranked. | ~27 ms spin-up; under 90 ms end-to-end |
| Max runtime The longest a sandbox may run. | No fixed limit |
| Isolation The isolation technology between sandboxes. | Linux namespaces and isolated containers for container sandboxes; full virtual machines with their own kernel for Linux and Windows VM sandboxes; isolated containers with exclusive GPU allocation for GPU sandboxes |
| GPUs Whether GPU instances are available for sandboxes. | ✓ |
| Docker Whether Docker containers can run inside the sandbox. | ✓ |
| SDKs | Python, TypeScript, Ruby, Go, Java |
✓ yes · ✕ no · – no cited public fact.
Daytona supports memory-preserving pause/resume and hot snapshots for Linux VM and Windows sandboxes; container sandboxes clear memory on every stop. Daytona bills stopped and paused sandboxes for reserved disk only and does not bill archived container sandboxes. Daytona deletes GPU sandboxes automatically when they stop. macOS sandboxes run through use.computer, and Daytona documents no lifecycle or billing behavior for them.
Sources
- https://www.daytona.io/definitions/d/docker-in-docker
- https://github.com/daytonaio/daytona/issues/4461
- https://www.daytona.io/docs/en/language-server-protocol/
- https://www.daytona.io/
- https://www.daytona.io/docs/en/
- https://www.daytona.io/docs/en/snapshots/
- https://www.daytona.io/dotfiles/vms-pause-and-fork
- https://www.daytona.io/dotfiles/fastest-growing-infra-company-in-history
- https://www.daytona.io/docs/en/limits/
- https://www.daytona.io/docs/en/preview/
- https://www.daytona.io/docs/llms-full.txt
- https://www.daytona.io/pricing
- https://www.zenml.io/blog/e2b-vs-daytona
- https://www.daytona.io/docs/en/sandboxes/
- https://www.daytona.io/docs/en/architecture/
- https://www.daytona.io/docs/en/isolation/
- https://www.daytona.io/docs/en/persistence/
- https://www.daytona.io/docs/en/billing/
- https://www.daytona.io/docs/en/python-sdk/
- https://www.daytona.io/docs/en/typescript-sdk/
- https://www.daytona.io/docs/en/ruby-sdk/
- https://www.daytona.io/docs/en/go-sdk/
- https://www.daytona.io/docs/en/java-sdk/
Last verified 2026-09-22. Corrections land through the update log.