On this page · 4 min
What boxd is
A full computer, not a container. Every boxd machine is a VM with its own kernel, root, systemd, Docker and nested virtualization. It starts at 2 vCPU, 8 GiB and 100 GB of disk and goes to 8 vCPU and 32 GiB without asking.
Composable. Machine specs describe a ready machine in code, snapshots keep it warm, disks outlive it, a private network joins your machines, more than 100 integrations and automations run code on a schedule or an event, and any machine can create and drive others, signed in as itself. The same parts are in the CLI on your laptop, the CLI inside every machine, the Python and TypeScript SDKs, the API and the console.
Your app is still running when it wakes. A sleeping machine keeps its memory. An HTTPS or SSH request wakes it, and the app answered in 156 ms, the same process, nothing restarted.
New machines start with your stack up. Set a machine up once and snapshot it. A machine created from that snapshot answered its first request 1.19 s after the create command.
Coding agents built in. Claude Code, Codex and OpenCode on every machine, with headless Chrome, a desktop in the browser and Docker. API keys stay outside: the machine holds a placeholder and our proxy swaps in the real value.
No session limit. A machine runs until you delete it. It sleeps when idle and wakes on the next request.
Reachable like a server. Plain SSH on its own port, an HTTPS URL per port, custom and wildcard domains, raw TCP and UDP ports, and Tailscale or NetBird for your company network.
You pay for what's used. RAM on memory in use, disk on what's written, and a hibernated machine pays only for its disk. No plan fee.
Self-host it. Free up to 16 vCPUs on your own Google Cloud or AWS account, the same release as boxd cloud.
Composable, and fast because of it
A sandbox API gives you one block and leaves the rest to your code. boxd gives you the blocks and they fit: a machine spec describes a ready machine, a snapshot keeps it warm, an automation wakes on a pull request, creates a machine from that snapshot, runs the job and deletes it, signed in as the machine it runs on. Nothing outside boxd is needed.
That combination is why boxd ran the CI of 10 open-source projects 6× faster than one GitHub-hosted job, 5× faster than one Blacksmith job, 7× faster than one Vercel CI task (medians, every machine 2 vCPU). The CI benchmark
One by one
vs E2B. E2B runs short-lived sandboxes from an SDK, with a time limit on every run. A boxd machine is a full computer that stays, wakes on a request with your app still running, and comes with coding agents installed.
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.
vs Modal. Modal sandboxes are short-lived, end after 24 hours at most, and can't be stopped and started again. A boxd machine stays until you delete it and sleeps with your app running.
vs Vercel Sandbox. Vercel Sandbox runs sessions of up to 24 hours and brings back the disk, not the running processes. A boxd machine keeps its memory while it sleeps, so your app is still running when a request wakes it.
vs Blaxel. Blaxel sandboxes suspend within seconds and resume fast, with the filesystem held in memory. A boxd machine is a full computer with a 100 GB disk, plain SSH and coding agents installed.
vs Cloudflare Sandbox. Cloudflare Sandbox gives your Worker a container on the edge, with a disk that's wiped when it stops. A boxd machine is a persistent VM with its own disk, SSH and URL, that you can use without writing a Worker.
Moving off Runloop. Runloop is winding down, with transition support ending on 13 November 2026. boxd keeps what Runloop devboxes did and adds memory: a machine wakes on a request with your processes still running.
Persistent VMs over SSH, like boxd: boxd vs exe.dev and boxd vs sprites.dev.
How we measured
On boxd's production cluster. Where we have no measurement, we don't print a number.
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.