# boxd vs Daytona

> A Daytona sandbox is a container unless you pick its VM class. Every boxd machine is a full VM with its own kernel, starts at 2 vCPU and 8 GiB, and keeps your app running while it sleeps.

Checked 2026-10-30. Every Daytona claim links to Daytona's own docs or pricing. Web page: https://boxd.sh/compare/daytona/

## At a glance

|  | boxd | Daytona |
| --- | --- | --- |
| **Where boxd is ahead** |  |  |
| Full VM, own kernel | Yes, every machine | Container by default; VM class opt-in |
| Default size | 2 vCPU · 8 GiB · 100 GB | 1 vCPU · 1 GiB · 3 GiB |
| Wakes on a request | Yes, HTTPS or SSH · app answers in 156 ms | No; build your own proxy |
| Built-in integrations | 100+, credentials kept out | No |
| Schedules and event triggers | Cron and events; sleeps between runs | Lifecycle webhooks only |
| Self-host | Yes, free to 16 vCPUs | Repo archived; BYOC only |
| **Where Daytona is ahead** |  |  |
| GPUs | No | Yes, H100 to B300 |
| CPU test (runs/s) | 12.6 (our run) | 21.52 (VM class) |
| SOC 2 | SOC 2 in progress | SOC 2 Type II |

## Use boxd when

- You want a full VM without choosing a class
- You need more than 4 vCPU or 8 GiB
- Your process should keep running when nobody watches
- You want to self-host a maintained release

## Use Daytona when

- You need GPUs, Windows or macOS
- You create huge numbers of short container sandboxes
- You need SOC 2, HIPAA or SAML today

## Where boxd stands out

### A full VM, every time

Every boxd machine has its own kernel, root, systemd, Docker and nested virtualization. Daytona's default sandbox is a container on a shared kernel, without systemd; its VM class is opt-in and can only start from an existing VM image.

### Composable: the sandbox is one part of the kit

Daytona has no built-in integrations and no schedules or event triggers (its webhooks only report lifecycle events), and sandboxes share a network only as a parent and its children. Put together, boxd's parts ran the CI of 10 open-source projects 6× faster than one GitHub-hosted job.

|  | boxd | Daytona |
| --- | --- | --- |
| **Composable** |  |  |
| Ready machine described in code | Machine specs, built on one another | Declarative builder; not for VMs |
| Machines create machines | Yes, signed in as the machine | Not published |
| Built-in integrations | 100+, credentials kept out | No |
| Schedules and event triggers | Cron and events; sleeps between runs | Lifecycle webhooks only |
| Standalone disks | Yes, outlive the machine | S3-backed volumes, shared |
| Private network between machines | Org network, split by tags | Parent and child sandboxes only |
| Tailscale or NetBird | Both, built in | Install a client yourself, Tier 3+ |
| Agent skills or MCP | Agent skills; no MCP server | MCP server and agent skill |

### Sized like a real computer

boxd machines start at 2 vCPU, 8 GiB and 100 GB, and go to 8 vCPU and 32 GiB without asking. Daytona's default is 1 vCPU, 1 GiB and 3 GiB of disk, with an org ceiling of 4 vCPU and 8 GiB.

### Your app keeps running

A Daytona container stops after 15 idle minutes even while a process runs, and nothing wakes it on a request. A boxd machine sleeps with its memory kept and an HTTPS request brings it back: the app answered in 156 ms.

### Self-host it, maintained

Daytona moved its core to a private codebase in June 2026 and archived the open repo. boxd self-hosts on your Google Cloud or AWS account, free up to 16 vCPUs, on the same release as boxd cloud.

boxd's timings were measured on its production cluster on 2026-10-29, ten runs each, from a client in the same datacenter: a hibernated machine's app answered an HTTPS request in 156 ms median; a new machine from a snapshot answered 1.19 s after the create command.

## Side by side

|  | boxd | Daytona |
| --- | --- | --- |
| **The machine** |  |  |
| Full VM, own kernel | Yes, every machine | Container by default; VM class opt-in ([source](https://www.daytona.io/docs/en/isolation.md)) |
| Default size | 2 vCPU · 8 GiB · 100 GB | 1 vCPU · 1 GiB · 3 GiB ([source](https://www.daytona.io/docs/en/sandboxes.md#resources)) |
| Largest, self-serve | 8 vCPU · 32 GiB | 4 vCPU · 8 GiB (org default) ([source](https://www.daytona.io/docs/en/sandboxes.md#resources)) |
| Root, systemd, Docker | Yes, plus nested virtualization | Root and Docker; no systemd in containers ([source](https://www.daytona.io/docs/en/vpn-connections.md)) |
| CPU test (runs/s) | 12.6 (our run) | 21.52 (VM class) ([source](https://github.com/starslingdev/hpc-sandbox-benchmarks/blob/main/LEADERBOARD.md)) |
| **Composable** |  |  |
| Ready machine described in code | Machine specs, built on one another | Declarative builder; not for VMs ([source](https://www.daytona.io/docs/en/declarative-builder.md)) |
| Machines create machines | Yes, signed in as the machine | Not published ([source](https://www.daytona.io/docs/en/authentication.md)) |
| Built-in integrations | 100+, credentials kept out | No ([source](https://www.daytona.io/docs/en/linked-accounts.md)) |
| Schedules and event triggers | Cron and events; sleeps between runs | Lifecycle webhooks only ([source](https://www.daytona.io/docs/en/webhooks.md)) |
| Standalone disks | Yes, outlive the machine | S3-backed volumes, shared ([source](https://www.daytona.io/docs/en/volumes.md)) |
| Private network between machines | Org network, split by tags | Parent and child sandboxes only ([source](https://www.daytona.io/docs/en/sandboxes.md)) |
| Tailscale or NetBird | Both, built in | Install a client yourself, Tier 3+ ([source](https://www.daytona.io/docs/en/vpn-connections.md)) |
| Agent skills or MCP | Agent skills; no MCP server | MCP server and agent skill ([source](https://www.daytona.io/docs/en/mcp.md)) |
| **Ready when you are** |  |  |
| Sleeps with processes kept | Yes, standby and hibernate | VM class only ([source](https://www.daytona.io/docs/en/sandboxes.md)) |
| Wakes on a request | Yes, HTTPS or SSH · app answers in 156 ms | No; build your own proxy ([source](https://www.daytona.io/docs/en/custom-preview-proxy.md)) |
| Starts from a snapshot, app running | Yes · app answers in 1.19 s | VM class only ([source](https://www.daytona.io/docs/en/snapshots.md)) |
| Session limit | None | Stops after 15 idle min ([source](https://www.daytona.io/docs/en/sandboxes.md)) |
| **Built for agents** |  |  |
| Coding agents installed | Claude Code, Codex, OpenCode | Claude Code, Codex, OpenCode ([source](https://www.daytona.io/docs/en/snapshots.md)) |
| SSH | Native, own port per machine | Token through their gateway ([source](https://www.daytona.io/docs/en/ssh-access.md)) |
| HTTPS URL per port | Yes, plus custom domains | Yes, token or signed URL ([source](https://www.daytona.io/docs/en/preview.md)) |
| Raw TCP inbound | Yes, 3 ports per machine | Not published ([source](https://www.daytona.io/docs/en/isolation.md)) |
| Secrets kept out | Yes, swapped in at the proxy | Yes, egress proxy ([source](https://www.daytona.io/docs/en/secrets.md)) |
| **Price** |  |  |
| vCPU-hour | $0.047, CPU used | $0.0504, reserved ([source](https://www.daytona.io/pricing)) |
| RAM GiB-hour | $0.014, memory in use | $0.0162, reserved ([source](https://www.daytona.io/pricing)) |
| While asleep | Hibernated: disk only | Stopped: disk only ([source](https://www.daytona.io/docs/en/billing.md)) |
| **Also worth knowing** |  |  |
| GPUs | No | Yes, H100 to B300 ([source](https://www.daytona.io/pricing)) |
| Regions | Frankfurt (US waitlist) | US, EU ([source](https://www.daytona.io/docs/en/regions.md)) |
| SOC 2 | SOC 2 in progress | SOC 2 Type II ([source](https://trust.daytona.io)) |
| SAML SSO | No | Enterprise ([source](https://www.daytona.io/docs/en/sso.md)) |
| Egress allowlist | Yes | Yes ([source](https://www.daytona.io/docs/en/network-limits.md)) |
| Self-host | Yes, free to 16 vCPUs | Repo archived; BYOC only ([source](https://github.com/daytonaio/daytona)) |

## Where Daytona is stronger

- **Fast container creation.** Under 90 ms to create a container sandbox, with warm pools and 300 to 600 creates a minute.
- **GPUs, Windows and macOS.** Nvidia and AMD GPUs by the second, plus Windows and macOS sandboxes. boxd has none of the three.
- **CPU on this test.** Daytona's VM class scored 21.52 on the StarSling CPU test; boxd scored 12.6.
- **Compliance and enterprise controls.** SOC 2 Type II, HIPAA BAAs, SAML SSO and audit logs.

## Questions

### Is a Daytona sandbox a VM?

Not by default. Daytona's default sandbox is a container that shares the host kernel. It also offers Linux and Windows VM classes, which you have to choose and which start only from existing VM images. Every boxd machine is a VM with its own kernel.

### Can I still self-host Daytona?

Daytona archived its open-source repo in June 2026 and moved development to a private codebase; the last open release stays available but unsupported. For your own infrastructure it now offers BYOC runners attached to its control plane. boxd self-hosts end to end in your own cloud account, free up to 16 vCPUs.

### Does boxd have GPUs?

No. If your agents train or run models on GPUs, Daytona or Modal is the better fit.

## How we measured

### Wake from hibernation

A small Python HTTP server on a default 2 vCPU machine, published on its HTTPS URL. Ten times: hibernate the machine, confirm it reports hibernated, then send one HTTPS request on a new connection from a client machine in the same datacenter. Median 156 ms until the app answered (104–213 ms); a warm request takes about 73 ms, so waking adds about 80 ms. The app's process ID was the same after every wake.

### New machine from a snapshot

A snapshot of that machine with the server running. Ten times: run `boxd new --from-snapshot`, then request the new machine's HTTPS URL until the app answers. Median 1.19 s from the create command to the app's first response (1.14–1.24 s). The first request succeeded every time; nothing was started after boot.

### CPU

The Node.js web tooling test from StarSling's open sandbox benchmark (Phoronix Test Suite 10.8.4, pts/node-web-tooling-1.0.1, Node 22.23.1, two passes per run), on a 4 vCPU machine. Three runs: 12.65, 12.86 and 12.19 runs/s. The other providers' numbers are from StarSling's own published leaderboard, which runs 4 vCPU / 8 GiB; boxd's 4 vCPU size has 16 GiB, which this test doesn't use.

### What these numbers don't include

Your own network distance. Every timing was taken from a client in the same Frankfurt datacenter; from the US, add your round trip on top. A larger app has more memory to bring back, so it takes longer than a small server.

## More comparisons

- [boxd vs E2B](https://boxd.sh/compare/e2b/index.md)
- [boxd vs Modal](https://boxd.sh/compare/modal/index.md)
- [boxd vs Vercel Sandbox](https://boxd.sh/compare/vercel-sandbox/index.md)
- [boxd vs Blaxel](https://boxd.sh/compare/blaxel/index.md)
- [boxd vs Cloudflare Sandbox](https://boxd.sh/compare/cloudflare-sandbox/index.md)
- [Moving off Runloop](https://boxd.sh/compare/runloop/index.md)
- [boxd vs exe.dev](https://boxd.sh/blog/boxd-vs-exe-dev/)
- [boxd vs sprites.dev](https://boxd.sh/blog/boxd-vs-sprites/)
- [All comparisons](https://boxd.sh/compare/index.md)