# Daytona

> Linux containers by default and real VMs on request, with a 15-minute idle stop, a 10 GiB disk cap and two regions.

Website: https://www.daytona.io  
Guide page: https://botperch.com/providers/daytona/  
Checked: 2026-10-28

**Short answer:** One always-on personal agent (2 vCPU / 4 GiB / 20 GiB) costs about $122.07 a month here, with a catch: 20 GiB of disk is over the 10 GiB limit. The AI model adds about $14.70 a month on top (GLM 5.3, 30 requests a day at 40k tokens each, median zero-retention price; from $6.84 at the cheapest host). Fits well: A Docker or Windows workload: the VM and Windows classes have their own kernel, and Docker-in-Docker is documented.

Daytona sells sandboxes for AI-generated code: a Linux container by default, or a Linux VM, Windows, GPU or macOS sandbox when the workload needs one. The unit is created and driven through five SDKs, a CLI, a REST API and an MCP server.
The classes are not interchangeable. Pause, resume, fork and memory snapshots exist only on the VM classes; archive exists only on containers; GPU sandboxes run in containers and vanish on stop.
It began as an open-source development-environment company. That repository is archived, and the managed platform is closed source.

**Who it is for:** Teams building an agent product who want a fast container by default and a full VM when Docker, Windows or a real kernel is needed.

**Isolation:** Linux containers by default: dedicated namespaces, enforced resource limits and root inside, sharing the runner's kernel. Linux VM and Windows sandboxes have their own kernel. Docker-in-Docker is documented; nested virtualisation is Linux-VM only and must be enabled for the organisation. GPU sandboxes are containers with exclusive GPU allocation.

**Sizes and regions:** Default 1 vCPU / 1 GB / 3 GiB; the organisation ceiling is 4 vCPU / 8 GB / 10 GiB of disk. Named presets include daytona-medium 2/4/8 and daytona-large 4/8/10; Windows presets go to 4/16/50. GPU sandboxes attach up to 8 GPUs, each adding up to 16 vCPU / 192 GB / 512 GB. Two shared regions, us and eu.

## How it charges

- model: Per-second billing on reserved resources, with no plan fee. Tiers are prepaid top-ups that set an organisation-wide pool.
- meter: vCPU $0.0504/hour, memory $0.0162/GiB-hour and disk $0.000108/GiB-hour after the first 5 GiB. Windows adds $0.0858/vCPU-hour, which reads either as a replacement rate or a surcharge.
- stopped: Stopped and paused sandboxes bill reserved disk only; memory is not billed. Archived and deleted sandboxes bill nothing.
- planFee: No plan fee. Tier 1 needs only a verified email; Tier 2 is a $25 top-up, Tier 3 $500, and Tier 4 $2,000 every 30 days.
- minimum: $200 of free compute with no card, but it cannot be spent on GPU sandboxes.

Per second on reserved vCPU, memory and disk; stopped sandboxes bill disk only.
- $200 of free compute with no card, not usable on GPU sandboxes.
- The 10 GiB per-sandbox disk cap contradicts 50 GiB Windows presets; the cap is applied here.

## Monthly cost for each preset workload

- A personal agent that stays on (Hermes, OpenClaw): $122.07 (catch: 20 GiB of disk is over the 10 GiB limit.)
- A coding agent for one developer: $55.75 (catch: 40 GiB of disk is over the 10 GiB limit.)
- A code interpreter inside your product: $55.38
- A browser agent for a small team: $830.70
- Self-hosted n8n for a small team: $122.07 (catch: 20 GiB of disk is over the 10 GiB limit.)
- A Discord or Slack bot for one server: $60.84
- Claude Code for a team of five: $278.76 (catch: 40 GiB of disk is over the 10 GiB limit.)
- A scraper that runs four times a day: $1.67
- Your own remote MCP server: $49.01
- A: 1,000 short tasks: $27.69
- B: one always-on box: $245.32 (catch: 50 GiB of disk is over the 10 GiB limit.)
- C: three hours a day: $16.09 (catch: 20 GiB of disk is over the 10 GiB limit.)

## Fits well

- A Docker or Windows workload: the VM and Windows classes have their own kernel, and Docker-in-Docker is documented.
- A fast container for untrusted code, priced per reserved vCPU and second, with $200 of free compute and no card.
- A GPU sandbox alongside the CPU ones: up to 8 GPUs per sandbox, though on shared capacity and preemptible.
- Browser or desktop agents: a VNC desktop and a computer-use API are first-class.

## Fits badly

- A workload that needs more than 10 GiB of disk on a Linux sandbox; the 50 GiB presets are Windows only.
- An agent that runs long jobs with no inbound traffic: a container stops after 15 idle minutes even mid-build.
- Full internet on a small account: Tier 1 and 2 are network-restricted and cannot be overridden per sandbox.
- A strict per-tenant boundary: any organisation member or API key can exec in any running sandbox.

## Features

- **Isolation** (partly): Containers; VM on request. Linux containers by default: dedicated namespaces, enforced resource limits and root inside, sharing the runner's kernel. Linux VM and Windows classes have their own kernel. Docker-in-Docker is documented; nested virtualisation is Linux-VM only and must be enabled. [source](https://www.daytona.io/docs/en/isolation.md) [docs](https://www.daytona.io/docs/en/isolation)
- **Sizes and regions** (partly): 4 vCPU / 8 GiB / 10 GiB. Default 1 vCPU / 1 GB / 3 GiB; the organisation ceiling is 4 vCPU / 8 GB / 10 GiB, with daytona-large at 4/8/10. Windows presets reach 4/16/50 and GPU sandboxes attach up to 8 GPUs. Two shared regions, us and eu. [source](https://www.daytona.io/docs/en/sandboxes.md) [docs](https://www.daytona.io/docs/en/regions)
- **Lifecycle** (partly): VM pause: RAM; container stop. Pause exists only on Linux VM and Windows sandboxes; a container stop keeps the filesystem and loses memory. Stopped and paused sandboxes bill reserved disk only, and archive is container-only. [source](https://www.daytona.io/docs/en/sandboxes.md) [docs](https://www.daytona.io/docs/en/sandboxes#sandbox-lifecycle)
- **Snapshots and forks** (partly): Hot: RAM (VM); cold: disk. Cold snapshots capture the filesystem from a stopped sandbox; hot snapshots capture filesystem and memory from a started VM. Containers support cold only. Fork duplicates a Linux VM's filesystem and memory. Snapshots go inactive after 14 days unused. [source](https://www.daytona.io/docs/en/sandboxes.md) [docs](https://www.daytona.io/docs/en/snapshots)
- **Storage** (partly): 10 GiB cap; volumes free. The whole disk persists and bills in stopped and paused states at $0.000108/GiB-hour. Volumes are S3-backed FUSE mounts, 100 per organisation, free, and not usable for block storage such as database tables. [source](https://www.daytona.io/docs/en/volumes.md) [docs](https://www.daytona.io/docs/en/volumes)
- **Idle and waking** (partly): 15 min container; 60 min VM. Container and GPU auto-stop after 15 idle minutes by default; VM classes auto-pause after 60. Only lifecycle calls, preview requests, SSH and Toolbox calls reset it. An optional TTL destroys in any state; a stopped container archives after 7 days. [source](https://www.daytona.io/docs/en/sandboxes.md) [docs](https://www.daytona.io/docs/en/sandboxes#auto-stop-interval)
- **Reaching it** (partly): Token, or signed URL. Preview links are authenticated unless public is true. The standard token is sandbox-wide, opens the terminal and toolbox, and cannot be revoked; signed URLs are per port, 60 seconds by default and 24 hours maximum. [source](https://www.daytona.io/docs/en/preview.md) [docs](https://www.daytona.io/docs/en/preview)
- **Custom domains** (partly): Own proxy. No native custom domain. The documented route is your own preview proxy, which can also start stopped sandboxes before forwarding. [source](https://www.daytona.io/docs/en/custom-preview-proxy.md) [docs](https://www.daytona.io/docs/en/custom-preview-proxy)
- **Outbound network** (partly): Tier 3 for internet. Tier 1 and 2 are restricted and cannot be overridden per sandbox; Tier 3 and 4 get full internet. Per-sandbox controls are block-all, CIDR, domain or an upstream proxy. No static egress IP or egress price is published. [source](https://www.daytona.io/docs/en/network-limits.md) [docs](https://www.daytona.io/docs/en/network-limits)
- **Keys and secrets** (yes): No, proxy headers only. A dtn_secret_… placeholder is swapped by an outbound proxy in HTTPS request headers only; bodies and query strings fail. A secret without an allowlist is substituted for every host. [source](https://www.daytona.io/docs/en/secrets.md) [docs](https://www.daytona.io/docs/en/secrets)
- **Ways to drive it** (yes): Yes, playground. A dashboard Playground, web terminal, VNC desktop, five SDKs, a REST API, a CLI, a first-party MCP server, and webhooks that need support to enable. [source](https://www.daytona.io/docs/en/playground.md) [docs](https://www.daytona.io/docs/en/tools/cli)
- **Built-in agents** (partly): None; guides. No hosted agent or preinstalled harness. First-party guides cover Claude Code, Codex, Cursor, Devin, Gemini CLI, OpenCode, Amp and Kiro; computer use is a first-class API. [source](https://trust.daytona.io/) [docs](https://www.daytona.io/docs/en/guides/openclaw)
- **Teams and accounts** (partly): Org-wide resource pool. Tiers are prepaid top-ups that set an org-wide vCPU, memory and disk pool. Any member or API key can address any running sandbox. SSO is Enterprise; audit logs are role-gated and export is coming soon. [source](https://www.daytona.io/docs/en/organizations.md) [docs](https://www.daytona.io/docs/en/organizations)
- **Billing models** (partly): $0.0504/vCPU-hour. Reserved vCPU at $0.0504/hour, memory at $0.0162/GiB-hour and disk at $0.000108/GiB-hour, billed per second with no plan fee. Windows adds $0.0858/vCPU-hour, which may replace or add to the Linux rate. [source](https://www.daytona.io/pricing) [docs](https://www.daytona.io/docs/en/billing)
- **Trials and free tiers** (yes): $200 credit, no card. A $200 free compute credit with no card, and Tier 1 access by email verification. The credit is not available for GPU sandboxes; its expiry is not published. [source](https://www.daytona.io/pricing) [docs](https://www.daytona.io/docs/en/limits#tiers)
- **The company** (partly): Daytona Platforms Inc.; 99.95% Tier 4+. Daytona Platforms Inc., New York address, Delaware law; Delaware incorporation unconfirmed. Founded 2023; $91M raised after a $60M Series B at a $1B valuation. SLA 99.95% with credits for Tier 4+; A SOC 2 Type II report covering December 2025 to March 2026 is available from the trust centre; ISO 27001 is in progress. [source](https://www.daytona.io/sla)

## Capabilities

- Its own virtual machine: partly (containers by default). By default each sandbox is a container sharing the host's kernel; a real virtual machine is a separate kind you have to choose. [source](https://www.daytona.io/docs/en/sandboxes)
- Root access: yes (root in the sandbox) [source](https://www.daytona.io/docs/en/isolation)
- Docker inside: yes (Docker-in-Docker) [source](https://www.daytona.io/docs/en/snapshots)
- Nested virtualisation: partly (Linux VM class only). Nested virtual machines only work on the Linux VM class, and the feature has to be switched on for your organisation. [source](https://www.daytona.io/docs/en/sandboxes)
- Your own image: yes (Dockerfile or OCI image) [source](https://www.daytona.io/docs/en/declarative-builder)
- Any size you like: partly (presets, custom on request). You pick from fixed sizes, and anything different needs a custom limit arranged through support. [source](https://www.daytona.io/docs/en/sandboxes)
- Large machines: partly (4 cores / 8 GiB; more with GPUs). A normal sandbox stops at 4 cores and 8 GB; larger machines only come attached to graphics cards. [source](https://www.daytona.io/docs/en/sandboxes)
- Resize while running: partly (grow only, support must enable). You can add cores and memory while it runs, but you cannot shrink them, and the feature has to be switched on by support first. [source](https://www.daytona.io/docs/en/sandboxes)
- GPUs: yes (up to 8 GPUs) [source](https://www.daytona.io/docs/en/gpu-sandboxes)
- Choose the region: yes (US or EU) [source](https://www.daytona.io/docs/en/regions)
- Runs in the EU: yes (eu region) [source](https://www.daytona.io/docs/en/regions)
- Pause keeps memory: partly. Only the full virtual machine can be paused with memory; a container sandbox loses what was running. [source](https://www.daytona.io/docs/en/sandboxes.md)
- Pre-started pools: partly. Pools exist, but they must be switched on for your organisation by asking support. [source](https://www.daytona.io/docs/en/warm-pools)
- Starts in under a second: yes (Under 90 ms) [source](https://www.daytona.io/)
- Snapshots of files: yes [source](https://www.daytona.io/docs/en/snapshots.md)
- Snapshots with memory: partly. Memory snapshots are only for full virtual machines; container sandboxes get files only. [source](https://www.daytona.io/docs/en/snapshots.md)
- Copy a running machine: yes [source](https://www.daytona.io/docs/en/sandboxes.md)
- Pick an older snapshot: yes [source](https://www.daytona.io/docs/en/snapshots.md)
- Reusable templates: yes [source](https://www.daytona.io/docs/en/snapshots.md)
- Automatic backups: no [source](https://www.daytona.io/docs/en/snapshots.md)
- Files survive a stop: yes [source](https://www.daytona.io/docs/en/sandboxes.md)
- Separate volumes: yes. Volumes are network filesystems, not block disks, so a database table store is a poor fit. [source](https://www.daytona.io/docs/en/volumes.md)
- One volume, several machines: yes. Writes are not transactional, so two machines writing one file means the last write wins. [source](https://www.daytona.io/docs/en/volumes.md)
- Mount outside storage: yes [source](https://www.daytona.io/docs/en/mount-external-storage)
- Large disk: no (10 GiB cap). The organisation ceiling is 10 GiB of disk per sandbox, though some Windows presets list 50 GiB. [source](https://www.daytona.io/docs/en/sandboxes.md)
- Can stay on indefinitely: yes [source](https://www.daytona.io/docs/en/sandboxes.md)
- Choose the idle timeout: yes (Minutes, or 0) [source](https://www.daytona.io/docs/en/sandboxes.md)
- Wakes on a request: no [source](https://www.daytona.io/docs/en/sandboxes.md)
- Scheduled runs: no [source](https://www.daytona.io/docs/en/regions)
- Public link to a port: yes (public flag) [source](https://www.daytona.io/docs/en/preview.md)
- Private link: yes (Token or signed link) [source](https://www.daytona.io/docs/en/preview.md)
- Real SSH: yes (Token, 60 min) [source](https://www.daytona.io/docs/en/ssh-access.md)
- Terminal in the browser: yes (Dashboard) [source](https://www.daytona.io/docs/en/web-terminal.md)
- Tunnel to your computer: not-published [source](https://www.daytona.io/docs/en/ssh-access.md)
- Non-web ports: not-published [source](https://www.daytona.io/docs/en/preview.md)
- Your own domain: partly (Own proxy). You have to run your own forwarding service under your domain; the provider does not attach the domain for you. [source](https://www.daytona.io/docs/en/custom-preview-proxy.md)
- Automatic HTTPS: no. You run the forwarding service, so you also get and renew the certificate. [source](https://www.daytona.io/docs/en/custom-preview-proxy.md)
- Outbound data included: not-published [source](https://www.daytona.io/pricing)
- Allow only some sites: yes (Domain or address list) [source](https://www.daytona.io/docs/en/network-limits.md)
- Turn the internet off: yes (block-all) [source](https://www.daytona.io/docs/en/network-limits.md)
- Fixed outgoing IP: not-published [source](https://www.daytona.io/docs/en/network-limits.md)
- Stored secrets: yes (Stored secrets) [source](https://www.daytona.io/docs/en/secrets.md)
- Secrets the agent cannot read: yes (Header only) [source](https://www.daytona.io/docs/en/secrets.md)
- Limited API keys: yes (Permission scopes) [source](https://www.daytona.io/docs/en/api-keys.md)
- Create from the website: yes [source](https://www.daytona.io/docs/en/playground.md)
- Command-line tool: yes [source](https://www.daytona.io/docs/en/mcp.md)
- Python SDK: yes [source](https://www.daytona.io/docs/en/architecture.md)
- TypeScript SDK: yes [source](https://www.daytona.io/docs/en/architecture.md)
- Documented HTTP API: yes [source](https://www.daytona.io/docs/en/architecture.md)
- MCP server: yes [source](https://www.daytona.io/docs/en/mcp.md)
- Interactive terminal over the API: yes [source](https://www.daytona.io/docs/en/pty.md)
- Files over the API: yes [source](https://www.daytona.io/docs/en/file-system-operations.md)
- Coding agents preinstalled: partly. OpenClaw is in the default snapshot, but Claude Code and Codex are not; those need an install step. [source](https://www.daytona.io/docs/en/guides/openclaw/openclaw-run-secure-sandbox.md)
- Send it a prompt: no. No agent is hosted and there is no prompt call; you install and drive the agent. [source](https://www.daytona.io/docs/en/guides/claude/claude-code-run-cli-sandbox.md)
- One-click Hermes: no. Daytona documents OpenClaw but not Hermes, so there is no one-click route. [source](https://www.daytona.io/docs/en/guides/openclaw/openclaw-run-secure-sandbox.md)
- One-click OpenClaw: partly. OpenClaw is in the default snapshot, but you still run a command to start and configure it. [source](https://www.daytona.io/docs/en/guides/openclaw/openclaw-run-secure-sandbox.md)
- Browser built in: not-published [source](https://www.daytona.io/docs/en/computer-use.md)
- Desktop for computer use: yes [source](https://www.daytona.io/docs/en/computer-use.md)
- Runs other platforms' agents: yes [source](https://www.daytona.io/docs/en/guides/claude/claude-code-run-cli-sandbox.md)
- Team workspace: yes [source](https://www.daytona.io/docs/en/organizations.md)
- Roles and permissions: partly. Roles decide who can manage the organisation, but any member or key can still run commands in any running sandbox. [source](https://www.daytona.io/docs/en/organizations.md)
- Single sign-on: partly. SSO is available only on the Enterprise plan for collaborative organisations. [source](https://www.daytona.io/docs/en/sso.md)
- Hard spending cap: partly. The ceiling is a prepaid pool of computing resources rather than a dollar amount, and running sandboxes are not stopped when it runs out. [source](https://www.daytona.io/docs/en/billing.md)
- Usage alerts: not-published [source](https://www.daytona.io/docs/en/billing.md)
- Audit log: partly. The log exists, but exporting it for an audit is not shipped yet. [source](https://www.daytona.io/docs/en/audit-logs.md)
- Billed per second: yes (per second) [source](https://www.daytona.io/pricing)
- CPU billed only while working: no (reserved size). You pay for the cores and memory you reserved, not the ones the work used. [source](https://www.daytona.io/docs/en/billing)
- Paused costs only storage: yes (disk only) [source](https://www.daytona.io/docs/en/billing)
- No monthly fee: yes (none) [source](https://www.daytona.io/pricing)
- Flat monthly price: no (metered parts). The bill is cores plus memory plus disk per second. [source](https://www.daytona.io/docs/en/billing)
- Ongoing free tier: no (one-off $200). The $200 is a one-time credit, not something that returns every month. [source](https://www.daytona.io/pricing)
- Free starting credit: yes ($200) [source](https://www.daytona.io/pricing)
- Try without a card: yes (no card) [source](https://www.daytona.io/pricing)
- Public status page: yes [source](https://status.app.daytona.io/)
- Uptime promise (SLA): partly (99.95%, Tier 4+). The 99.95% target exists, but service credits go only to Tier 4 and above. [source](https://www.daytona.io/sla)
- SOC 2 report: yes (Type II) [source](https://trust.daytona.io/)
- Data processing agreement: yes [source](https://www.daytona.io/dpa)
- Open source or self-hostable: partly (BYOC, Enterprise). Only the sandbox compute runs on your own machines, only after Daytona enables it, and the control plane stays Daytona's. [source](https://www.daytona.io/docs/en/bring-your-own-compute.md)

## Usability

- Dashboard: Yes: a dashboard with a browser Playground for creating sandboxes and running SDK operations, plus Terminal and VNC tabs.
- Without code: Partly. The Playground creates a sandbox and generates SDK snippets; operating one from the browser works, but building one is still a form of code.
- Signup: Google or GitHub login, no card, $200 of free compute. Tier 1 needs only a verified email; GPU sandboxes cannot use the free credit.
- Docs: Agent-readable docs with llms.txt and a 3.3 MB llms-full.txt, five SDKs, a CLI and a first-party MCP server. Support is email, Slack, chat, video and forums with no response-time commitment.
- Trips people up: The 15-minute idle stop ignores a running build or inference job.
- Trips people up: The standard preview token opens the whole sandbox and cannot be revoked.
- Trips people up: Tier 1 and 2 cannot reach the open internet, so package installs fail.
- Trips people up: Any organisation member can exec in any running sandbox.
- Trips people up: 50 GiB disks exist only on Windows.

## Company

- Legal entity: Daytona Platforms Inc., at a New York address. Delaware incorporation is unconfirmed by the company; its terms name Delaware law. [source](https://www.daytona.io/terms-of-service)
- Founded and leadership: 2023, by Ivan Burazin (CEO), Vedran Jukić (CTO) and Goran Draganić (Chief Architect). [source](https://www.daytona.io/about)
- Funding: $91M total after a $60M Series B at a $1B valuation in October 2026, led by FirstMark Growth. [source](https://www.daytona.io/dotfiles/daytona-raises-60m-series-b-to-build-the-agent-cloud)
- Headcount: Twelve people are named on the about page; no total is published.
- Status and SLA: Status page components showed 99.768% at the lowest. The SLA promises 99.95%, but credits go only to Tier 4 and above. [source](https://www.daytona.io/sla)
- Certification: A SOC 2 Type II report covering December 2025 to March 2026 is available from the trust centre (checked 29 October 2026; earlier only a bridge letter was published). ISO 27001 is marked in progress while the badge is displayed. [source](https://trust.daytona.io/)
- Price changes: No notice period: fees may change by posting the change on the service. [source](https://www.daytona.io/terms-of-service)

## Caveats

- **Every sandbox is said to have a dedicated kernel, then said to be a container** (contradiction): The sandboxes page claims a dedicated kernel for every sandbox and two paragraphs later says sandboxes run as Linux containers by default. The isolation page is explicit that containers get namespaces and only VM classes get their own kernel.
- **Startup is quoted as sub-90 ms and as sub-200 ms** (contradiction): The homepage claims sub-90 ms from code to execution; the careers page says sub-200 ms. Neither is a measured figure for a cold sandbox.
- **The 10 GiB disk cap and the 50 GiB Windows presets cannot both be the maximum** (open): The sandboxes page states a 10 GB per-sandbox disk maximum and, on the same page, lists Windows presets with 30 and 50 GB. Treating 10 GiB as the real Linux cap is the profile's judgement call: a 50 GiB Linux sandbox needs a raised limit with no published price or approval path beyond support.
- **Startup credits are $50k or $100k** (contradiction): The pricing page offers up to $50k in credits; the startups page offers up to $100k. Both are live.
- **Audit logs are an Enterprise feature on one page and a permission on another** (contradiction): The pricing page lists SSO and audit logs under Enterprise; the audit-log page gates them by role instead, and says compliance export is coming soon.
- **Roles do not protect running sandboxes** (open): Any member of an organisation, and any API key valid for it, can exec in every running sandbox whatever their role. A write:sandboxes key can also mount any secret in the organisation.
- **The standard preview token is a sandbox-wide credential** (open): It is not restricted to the port requested, opens the web terminal and the toolbox, and cannot be revoked. Signed URLs are the shareable form: 60 seconds by default, 24 hours maximum.
- **The open-source repository is archived** (open): The public repo says development moved to a private codebase in June 2026. The managed service is closed source, so the archived code is not what you are buying.
- **Two documentation trees describe different products** (open): The default docs are v0.226; /docs/en/v2/ documents an alpha with different API hosts and a different macOS model, including Daytona-managed Mac reservations.

## Sources

- [Docs](https://www.daytona.io/docs)
- [Sandboxes](https://www.daytona.io/docs/en/sandboxes.md)
- [Isolation](https://www.daytona.io/docs/en/isolation.md)
- [Billing](https://www.daytona.io/docs/en/billing.md)
- [Limits and tiers](https://www.daytona.io/docs/en/limits.md)
- [Pricing](https://www.daytona.io/pricing)
- [SLA](https://www.daytona.io/sla)
- [Terms](https://www.daytona.io/terms-of-service)