Every sandbox puts a wall around your code. Three technologies draw that wall in very different places. Follow the boundary from the thinnest to the thickest, one scroll at a time.
Every sandbox answers the same question: how strong should the wall around your code be, and how fast should it come up? Push for a stronger wall and you usually pay in start-up time. The three main models, plus gVisor in between, are just different answers to that one trade.
An isolate runs your code inside a shared runtime process, and the boundary is the language VM itself. It starts in about 50ms (Cloudflare), but it shares the host kernel with everything else. Perfect for trusted, short JavaScript, weakest of the four for code you did not write.
A container isolates your code with kernel features, namespaces and cgroups, and starts in about 90ms (Daytona). The catch: it still shares the one host kernel. That kernel is a large, shared attack surface, so a single kernel bug can reach the host.
gVisor slips a small kernel written in user space between your code and the host. It intercepts system calls and answers most of them itself, so far fewer ever reach the host kernel. A thicker wall than a container, lighter than a full VM. Modal uses it, at about 800ms to start.
A microVM boots a whole guest, its own kernel on virtual hardware, through hardware virtualization. The host kernel is not shared. That is the thickest wall of the four, and modern ones still boot in roughly 150 to 400ms (E2B, Vercel, Fly). This is the default for untrusted code.
The wall only matters when something goes wrong. Break out of an isolate or a container and you are on the shared host kernel, next to every other tenant. Break out of a microVM and you are still inside a throwaway guest. Same escape, very different blast radius.
Strength is not free, but it is cheaper than the old intuition says. Isolates start around 50ms, containers around 90ms, microVMs around 150ms. Note the twist: gVisor sits between a container and a microVM on strength, yet is the slowest to start here at about 800ms.
Match the wall to the code. Trusted, short JavaScript is happy in an isolate. Your own code in a dev environment is fine in a container. The moment you run untrusted or AI-generated code, you want the kernel boundary of a microVM. That is the choice, in one line.
"Sandbox" sounds like one thing, but under the hood a sandbox is a choice of boundary. The question is always the same: when your code misbehaves, where does the damage stop? The answer depends on which of three isolation models you are standing on, with gVisor as a fourth option in the middle.
Picture a single dial from thin and fast to thick and slower. A V8 isolate sits at the thin end: your code runs in a shared process and the boundary is the language runtime, so it starts in about 50ms but leans on a lot of shared machinery. A microVM sits at the thick end: your code gets its own kernel on virtual hardware, a real wall, and still boots in roughly 150 to 400ms. A container lands in between at about 90ms, and gVisor adds a user-space kernel that trades some speed for a smaller shared surface.
The differences look academic until code breaks out. A container and an isolate both share the one host kernel, so a successful escape puts an attacker next to every other workload on that machine. gVisor shrinks that risk by handling most system calls in user space, so fewer calls touch the host kernel at all. A microVM removes the shared kernel entirely: each run has its own, so a breakout stays inside a disposable guest. For code an AI agent just wrote, that is exactly the property you want, which is why microVMs are the default across the AI sandbox pillar.
The reflex is "a VM per run must be slow and heavy." That was true of full virtual machines, not of microVMs. Firecracker and its peers strip the virtual hardware down to almost nothing, so a fresh guest boots in the low hundreds of milliseconds with only a few MiB of overhead. The strongest wall is now within a rounding error of the weaker ones on start-up, which is why the whole market moved this way.
| Sandbox | Start | Isolation | $/vCPU-hr | GPU |
|---|---|---|---|---|
| Cloudflare Sandbox SDK | 50ms | V8 isolate + container | $0.072 | No |
| Daytona | 90ms | Docker container | $0.05 | Yes |
| E2B | 150ms | Firecracker microVM | $0.05 | No |
| Fly.io Machines | 300ms | microVM | $0.07 | Yes |
| Vercel Sandbox | 400ms | Firecracker microVM | $0.128 | No |
| Modal | 800ms | gVisor | $0.14 | Yes |
Live from our vendor data, verified and dated on each vendor page. Start times mix cold boots, warm resumes and isolate starts, see the benchmark for the method.
A container shares the host's kernel and draws its boundary with namespaces and cgroups, so one kernel bug can reach the host. A microVM boots its own guest kernel through hardware virtualization, so a breakout stays inside the guest. That extra kernel is the whole difference, and it is why microVMs are the default for untrusted code.
Neither, exactly. gVisor runs a small kernel in user space that intercepts the workload's system calls and handles most of them itself, so far fewer calls ever reach the host kernel. It is lighter than a full microVM but a thicker wall than a plain container. Modal uses it, and it starts in roughly 800ms in our data.
A microVM. Because each run gets its own kernel, generated code that deletes files, opens sockets or loops forever only touches the disposable guest. E2B, Vercel Sandbox and Fly Machines all take this route.
They are a thin boundary built for trusted, short-lived JavaScript, and they start in about 50ms (Cloudflare). For arbitrary untrusted code they are the weakest of the four, since the isolate shares a process and the host kernel with everything else. Great for speed, not for code you do not trust.
Modern microVMs like Firecracker strip the virtual hardware down to the minimum, so they boot in about 150ms with only a few MiB of overhead. The old "VMs are slow" intuition came from full virtual machines, not from these.
In our dataset: Cloudflare pairs a V8 isolate with a container (about 50ms), Daytona is a Docker container (about 90ms), Modal runs on gVisor (about 800ms), and E2B, Vercel Sandbox and Fly Machines are microVMs (about 150 to 400ms).
Pricing changes, new entrants, benchmark refreshes and one sharp take from Eve Harper. Read by engineers choosing where their agents and apps run. No fluff. Read the archive.