SmolVM vs. Firecracker: Which MicroVM Should Actually Isolate Your AI Agent's Code?

A self-hosted platform choosing a microVM runtime for AI-agent code execution in September 2026 has four real options on the table, not one. Firecracker has been the default answer for two years. SmolVM, a single-executable microVM that launched April 17, 2026, undercuts its headline boot number. Alibaba's OpenSandbox and Docker's own Sandboxes feature both shipped in the same window, racing on the same tradeoff curve. Here's what actually separates them — measured, not marketed:

Two of those rows need a methodology note before you read anything into them. Firecracker's 125–150ms is a genuine cold boot with no prewarming; SmolVM's numbers are also cold boots, just on different host platforms, so the two are comparable. Firecracker's sub-50ms figure is a different measurement — a snapshot restore from a warm pool, a capability SmolVM doesn't have yet. Compare cold-to-cold and warm-to-warm, not one runtime's best case against the other's worst.

What SmolVM actually is — and what actually isolates it from the host kernel​

SmolVM comes from smol-machines, a Y Combinator-backed startup, and it picked up 482 points on Hacker News the day it launched. The pitch is legitimate: a single static executable, no daemon, no separate jailer process, that boots a hardware-isolated Linux VM in under 200 milliseconds. On Linux, it's built on libkrun, Red Hat's embeddable KVM library that also powers Podman's VM mode. On macOS, it uses Apple's Hypervisor.framework directly — the same virtualization layer Docker Desktop already relies on, which is why SmolVM is one of very few microVM runtimes that runs natively on a developer's laptop without a Linux VM underneath it.

That matters for the question this post is actually asking — what isolates untrusted agent-generated code from the host kernel — because the honest answer is: the same class of boundary Firecracker uses. Both libkrun and Firecracker sit on top of KVM. Both hand the guest a real, separate Linux kernel with hardware-enforced memory isolation. Escaping either one requires breaking out of that guest kernel and the hypervisor underneath it.

That's a fundamentally harder bar than the alternative most people compare it to: gVisor, which intercepts a container's syscalls in a userspace process called the Sentry rather than handing it a real kernel at all. gVisor's isolation is real and dramatically reduces host kernel attack surface, but it is a process boundary, not a hardware one. SmolVM and Firecracker are both on the hardware side of that line.

Where they diverge is track record, not architecture class. Firecracker's minimalism is deliberate and audited: about 50,000 lines of Rust implementing exactly five virtio devices — network, block, vsock, serial console, and a minimal keyboard controller — versus QEMU's roughly two million lines of C emulating everything a real PC might have. That gap is Firecracker's actual security pitch, and it's been load-bearing at AWS Lambda and Fargate scale since 2018 with zero disclosed escape-class CVEs.

SmolVM has none either — but it has none because it's four months old, not because anyone has spent four years trying to break it. "Production-adjacent, not production-hardened" is the fair read. A new hardware VM boundary is still a hardware VM boundary; it just hasn't been shot at yet.

Firecracker's density math — and why the memory numbers alone don't settle it​

The headline density numbers favor Firecracker by a wide margin: 5–15MB of overhead per instance versus SmolVM's 40–80MB. Put a real box against that gap. A Hetzner CX32 — 4 vCPUs, 8GB RAM, the class of node a self-hosted fleet would actually run a sandbox tier on — has roughly 7GB usable after host overhead. At the midpoint of each range (10MB for Firecracker, 60MB for SmolVM), that's room for about 700 Firecracker instances held in memory versus about 116 for SmolVM. A 6x difference, and on paper it looks decisive.

It isn't, by itself, because memory is the wrong bottleneck to check first. A CX32 has four vCPUs. Whether the sandboxes underneath are Firecracker or SmolVM, you cannot concurrently execute more than a small multiple of four before CPU contention — not memory — decides how many agent tasks actually run at once. The memory numbers matter for a different question: how many warm, idle sandboxes a fork-and-resume architecture can hold ready in a pool without paying a full cold boot on every request. That's a real advantage for Firecracker's warm-pool designs specifically, because holding 700 idle VMs in reserve costs a fraction of the RAM that 116 would. But if your workload is "spin up a sandbox, run it, tear it down" rather than "keep a large warm pool resident," the memory gap narrows to an operational nicety, not the deciding factor.

The boot-time gap under load tells a cleaner story. Firecracker's sub-50ms snapshot-restore path beats SmolVM's 90–260ms cold start categorically, because SmolVM doesn't have a snapshot-restore path yet — every sandbox pays the full cold-boot cost, every time. For a sustained, high-throughput sandbox tier serving many short-lived agent tasks per minute, that's the number that actually compounds.

OpenSandbox and Docker Sandboxes aren't the fourth and fifth VMM​

It's worth correcting the premise before it goes further: OpenSandbox and Docker Sandboxes are not raw hypervisor choices the way SmolVM and Firecracker are. They sit a layer up.

Alibaba's OpenSandbox, open-sourced in March 2026 under Apache 2.0 and already past 3,800 GitHub stars, is an orchestration and API layer — multi-language SDKs, a unified sandbox API, Docker/Kubernetes runtimes for coding agents, GUI agents, and RL training. Underneath, it explicitly supports gVisor, Kata Containers, or Firecracker as pluggable isolation backends.

That's the detail that matters for this post's actual question: OpenSandbox's isolation guarantee is not a fixed property of the platform, it's whichever backend the operator configures. Point it at Firecracker or Kata and you get a real hardware VM boundary. Leave it on a lighter-weight gVisor default and you get a process boundary with a smaller kernel attack surface but no hypervisor between the guest and the host. If you adopt OpenSandbox for anything running untrusted third-party code, the backend selection is the security decision — treat it as one, not as a default to accept.

Docker Sandboxes is further from a raw VMM in a different direction: it's a finished product (the sbx CLI) aimed at running Claude Code, Codex, Gemini, and Kiro safely on a developer's own machine or CI runner. Docker deliberately didn't build on Firecracker, because Firecracker is Linux/KVM-only and Docker needed macOS and Windows parity — so it wrote a new cross-platform VMM instead, using Apple's virtualization.framework on macOS and Hyper-V on Windows, wrapped in five isolation layers (hypervisor, network, Docker Engine, workspace, credential proxy). It's a legitimate hardware boundary, and a genuinely useful answer to "how do I let an agent run unsupervised on my laptop without trusting it with my host." It is not, today, a server-side, multi-tenant sandbox-as-a-service primitive a PaaS would run at fleet density — it's optimized for one developer's one machine, not for packing hundreds of tenant sandboxes onto a shared Linux box.

The actual decision matrix​

None of this resolves to "pick the fastest boot number." It resolves to matching the runtime to what's actually being isolated:

• A dense, Linux-only, multi-tenant fleet running untrusted third-party agent code at scale — the shape of workload a self-hosted PaaS's own deploy-triggered build and test execution is — should default to Firecracker. It has the smallest attack surface, the best memory density for a warm pool, sub-50ms resume once that pool exists, and four years of production hardening at hyperscale that nothing else on this list can currently claim.
• A small ops team that wants less operational surface and needs the same tooling to work on both a Linux fleet and contributors' Mac laptops should pilot SmolVM for semi-trusted, in-house workloads — but not hand it the primary isolation boundary for arbitrary tenant code yet. Zero CVEs on a four-month-old project is an absence of evidence, not evidence of absence.
• A team already standardized on Docker tooling that wants agent sandboxing on developer machines and CI, not a server-side multi-tenant fleet, is the correct audience for Docker Sandboxes as shipped today.
• Anyone adopting OpenSandbox for untrusted code should pin the backend to Kata or Firecracker explicitly and audit that configuration, rather than trusting whatever ships as the default.

The one wrong move is leaving this choice to the tenant. A platform's language runtime, its database version, even its region — those are reasonable knobs to expose. The isolation boundary between one tenant's arbitrary shell commands and the next tenant's workspace is not a preference; it's the platform's actual security guarantee, and a self-hosted PaaS should make that call once, on the operator's side, the same way it decides what hypervisor its own Machine primitive runs on. Bex's own agent-triggered execution paths — running a tenant's build and test commands as part of a deploy workflow initiated by an agent — default to Firecracker for exactly this reason: it's the option with a track record long enough to trust with code the platform didn't write.

What would change the answer​

SmolVM's trajectory is worth tracking, not dismissing. libkrun and Hypervisor.framework are not experimental technology — they're production dependencies of Podman and Docker Desktop already. What SmolVM lacks isn't architecture, it's mileage: a public bug bounty history, a multi-year run at real production scale, the kind of adversarial attention Firecracker has absorbed since 2018. If that accumulates over the next year without an escape-class finding, the density and portability tradeoffs will look a lot more attractive for the primary boundary, not just the pilot. Until then, "fastest cold boot" and "most trustworthy with code you didn't write" are answered by two different runtimes — and a self-hosted platform's own default should track the second question, not the first.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.

Sources:

• SmolVM Explained: Sub-200ms MicroVMs vs Firecracker — particula.tech
• smolvm - MicroVMs that boot in under 200ms — Korben
• Smol Machines: Fast, Portable Linux VMs with smolvm — AIToolly
• alibaba/OpenSandbox — GitHub
• What is Alibaba OpenSandbox? — Northflank
• Why MicroVMs: The Architecture Behind Docker Sandboxes — Docker
• Docker Sandboxes: Run Claude Code and More Safely — Docker
• What is AWS Firecracker? — Northflank
• Firecracker vs gVisor: Which isolation technology should you use? — Northflank