One API to create, exec, and delete Firecracker microVMs. The hosted API is a small capacity-limited demo with $0.50 in credits, not a production cloud. Self-hosting is the production path.
Three ways a sandbox comes up. Every create response tells you which one you got, with the full timing trace.
| boot path | p50 | p95 | what it is |
|---|---|---|---|
| hot_pool | 38 ms | ||
| 61 ms | warm microVM claimed from the pool — curated images | ||
| snapshot_restore | 45 ms | ||
| 65 ms | golden image snapshot restored — empty-pool creates land here now, and so does the perpetual-standby wake | ||
| cold_boot | ~1.2 s | ~1.5 s | fresh rootfs boot — only the first run of a brand-new image, or a volume-attached sandbox |
| base shape | 1 vCPU · 2 GB · 8 GB disk | $0.009 / hr | ≈ $0.0000025 / second | | metering | per second | no minimum | meter stops at delete | | bigger shapes | linear in resources | 2× memory ≈ 2× price | quote returned on every create |
don't trust this table — every create returns its own boot_path
,
timings_ms
, and metered quote. trust those.
Leave a sandbox alone and it stops burning RAM and money — without dying. workdir snapshots it, frees the memory, and parks it at $0, then brings it back with its disk and processes intact the instant your next call lands. Your code never knows it slept.
| state | cost | what happens |
|---|---|---|
| running | per-second | |
| full vCPU + RAM, metered by the second while it works | ||
| idle, still hot | per-second | |
| after ~a minute idle the guest hands its unused RAM back to the host (virtio-balloon) — a 2 GB sandbox drops to ~57 MB resident while staying instantly responsive | ||
| idle → standby | $0 / hr | |
| snapshotted to disk, RAM freed, parked — the meter stops the moment it parks | ||
| wake | no extra | |
the next exec / file / port call auto-resumes it in ~50 ms (~80 ms for the full API round trip) — no resume API, no cold boot, state intact (survives a daemon restart, too) |
||
| fork | per-second | |
| clone a live sandbox into an instant sibling from its snapshot — same disk, its own id |
most sandboxes make you choose: pay to keep one warm, or lose its state when it times out. standby is the third option — a sandbox that's always there and only costs you while it's actually doing something.
The same microVM runs more than a shell. Give an agent a real browser to drive, hand it storage that outlives the box, and run far more of them per node — all behind the one API.
| capability | what you get |
|---|---|
| computer-use desktops | the browser image boots headed Chrome on a virtual display — drive it programmatically over CDP (Chrome DevTools Protocol, e.g. Playwright connectOverCDP ), watch it live over VNC/noVNC, or grab a one-call GET /browser/screenshot PNG. Built for browser agents and computer-use. |
| persistent volumes | attach block storage that outlives the sandbox. Delete the box, keep the disk, re-attach it to the next one — survives standby and resume too. volumes: [{ volume_id, mount_path }] . |
| interactive terminal | a real TTY in every sandbox: GET /v1/sandboxes/:id/pty upgrades to a WebSocket bridged onto an in-guest pseudo-terminal — job control, ^C , vim, the lot. Point xterm.js at it and you have a live terminal. |
| live metrics | GET /v1/sandboxes/:id/metrics — what a sandbox actually uses vs. what it reserves: host-resident memory, guest memory stats, network counters. The same honesty as boot_path , for runtime. |
| in-RAM density | one read-only base image and one golden memory image are shared across every microVM — single copies in host RAM — while each VM's writes land in its own overlay. Many more sandboxes per node, same isolation. |
| instant fork | clone a running sandbox into an independent sibling from its live snapshot — same disk state, its own id and network. Great for fan-out and branch-and-try. |
volumes are the durable counterpart to standby: standby keeps a running sandbox cheap, volumes keep its data around even after it's gone.
Their published numbers, their marketing's best case, rounded in their favor.
| workdir | e2b | modal | fly machines | |
|---|---|---|---|---|
| isolation | firecracker microVM | firecracker microVM | gVisor container | firecracker microVM |
| create → ready | 38 ms hot · 45 ms restore · ~1.2 s cold | |||
| ~150 ms | ~1 s | ~300 ms | ||
| idle sandbox | $0 · auto-resumes | |||
| killed on timeout | scales to zero | auto-stop, you wire it | ||
| 1 vCPU · 2 GB | $0.009 / hr | |||
| ~$0.13 / hr | ~$0.15 / hr | ~$0.015 / hr | ||
| boot path disclosed | every create | — | — | — |
| self-host | one command | diy cluster | — | — |
| open source | AGPL-3.0, all of it | infra only | — | — |
mid-2026 list prices for the closest comparable shape; latencies as advertised by each. spot an error? open an issue and we'll fix the table.
One command on a KVM box turns it into a sandbox fleet — the same binary our cloud runs, scheduler, billing, and preview proxy included.
Your agents, on your metal. You can read every line of the thing they execute on, cap their network, and add capacity by plugging in another server. No quotas, no noisy neighbors, no usage report you can't audit.
The hosted cloud at workdir.dev exists for the impatient — same code, same prices, zero setup. It's a convenience, not a moat.
curl -fsSL https://workdir.dev/install.sh | sudo bash
impatient? take a hosted key → first sandbox in under a minute.