Firecracker vs gVisor: isolation, overhead and compatibility
Firecracker runs each workload in a microVM with its own Linux kernel; gVisor runs it on a user-space kernel that intercepts system calls.
Runtime chose Firecracker, and still starts a sandbox in about a third of a second. Every Runtime sandbox is a Firecracker microVM with its own Linux kernel, and a new one ran its first Python command 351 ms after the create request at the median, measured over the public internet on 24 September 2026 (speed).
How Firecracker works
Firecracker is a virtual machine monitor written in Rust. It uses the Linux kernel's KVM to create a virtual machine per workload and boots a real guest Linux kernel inside it. The project puts compute-only guest performance at over 95% of bare metal. The guest's hardware is short: Firecracker's site counts "only 5 emulated devices": virtio-net, virtio-block, virtio-vsock, a serial console and a minimal keyboard controller.
The monitor process is itself confined. Seccomp filters limit Firecracker to "the bare minimum set of system calls and parameters" it needs, and a jailer drops its privileges inside cgroups and namespaces, which the project calls "a second line of defense in case the virtualization barrier is ever compromised."
How gVisor works
gVisor puts an application kernel, the Sentry, between the program and the host. It "intercepts application system calls and acts as the guest kernel, without the need for translation through virtualized hardware." The Sentry is written in Go and runs in user space; a separate Gofer process mediates file access, and the runsc OCI runtime plugs it into Docker and Kubernetes.
On the default platform, systrap, the host kernel traps each system call with seccomp and hands it to the Sentry. The Sentry then uses "a minimal set of host system calls", which exclude opening files and creating sockets in the default modes. There is no guest Linux kernel and, in gVisor's words, no "device emulation" at all.
Side by side
| Firecracker | gVisor | |
|---|---|---|
| Isolation boundary | Hardware virtualization (KVM) | A user-space application kernel between the program and the host |
| Kernel the code sees | A real Linux guest kernel of its own | The Sentry, which implements a Linux-like interface |
| What reaches the host | 5 emulated devices, in the project's count, and the VMM's filtered system calls | The Sentry's minimal, enumerated set of host system calls |
| Language | Rust | Go |
| Start time | Up to 125 ms to guest init, in the project's specification | No single figure published |
| Memory overhead | Up to 5 MiB for the VMM on a 1 vCPU, 128 MiB guest | "A small, mostly fixed amount of memory", per the project |
| Compatibility | Runs a Linux kernel, so Linux behaves as Linux | The project names "reduced application compatibility" as the cost |
| Performance | Over 95% of bare metal for compute-only work, per the project | "Higher per-system call overhead", per the project |
| Interface | A RESTful API per process; used under Kata Containers and Flintlock | runsc, an OCI runtime for Docker and Kubernetes |
| Who uses it | AWS Lambda and Fargate; E2B, Vercel Sandbox, Runtime | GKE Sandbox, Cloud Run, App Engine; Modal |
Firecracker's figures are from its specification, measured on AWS metal hosts with a minimal guest. They describe the monitor alone, not a full sandbox.
Is gVisor safer than Firecracker?
They make different bets, and each project argues its own. Firecracker relies on the processor's virtualization boundary plus a tiny device model and a jailed, seccomp-filtered monitor. gVisor relies on a memory-safe kernel that implements Linux itself and touches the host through a short, enumerated list of calls, and it warns that "one should not assume that the mere use of virtualization hardware makes a system more or less secure."
What differs for the code you run: under Firecracker, code that breaks the guest kernel has broken only its own throwaway machine. Under gVisor, code that breaks the Sentry lands in a user-space process whose host surface is, in the project's words, "explicitly enumerated and controlled".
When each fits
- Pick Firecracker when you run untrusted or model-written code and want a full Linux kernel per workload: package managers, compilers, Docker, system tools and anything that expects real Linux behaviour.
- Pick gVisor when you already run containers on Kubernetes or Docker and want a stronger boundary by switching the runtime to runsc, without managing virtual machines or needing KVM on the host.
Why Runtime chose Firecracker
An agent sandbox runs whatever a model writes, so each one gets its own kernel behind a hardware boundary. The rest follows from that:
- Real Linux inside. Ubuntu 24.04, Python 3.12, Node.js 24, Bun, git and
gcc, with
sudoworking. Docker runs in a sandbox aftersudo enable-docker(Docker). - Root inside changes nothing outside. Network rules, CPU, memory and cost are enforced on the host, outside the microVM (security).
- Whole-machine state. A paused sandbox keeps its files, memory and running processes for 1 to 365 days, and a fork copies a running sandbox, memory included.
TypeScriptimport { Sandbox } from "withruntime";await using sbx = await Sandbox.create();const run = await sbx.exec("uname -r"); // the sandbox's own kernelconsole.log(run.stdout);Pythonfrom withruntime import Sandboxwith Sandbox.create() as sbx: run = sbx.exec("uname -r") # the sandbox's own kernel print(run.stdout)Try it on the free trial, 50 sandbox hours with no card:
Terminalnpx withruntime sandbox run --trial -- uname -rMore: microVM vs container, gVisor vs Docker, Runtime vs Modal, run untrusted LLM code.
Sources
Checked 25 September 2026.
- Firecracker, README, specification, design
- gVisor documentation, security model, platforms, performance, users
- Provider isolation from Runtime's comparisons, checked 23 September 2026: E2B, Vercel Sandbox, Modal
Facts on this page were checked on 25 September 2026.