microVMs vs gVisor
MicroVMs (like Firecracker) are the industry preferred choice for high-security agent sandboxes, but gVisor is the preferred choice for high-density enterprise platforms (like Google).
If you are building an agent infrastructure startup today (like E2B or Modal), you almost certainly choose MicroVMs. If you are Google, you use gVisor.
The Case for MicroVMs (The "Safety First" Choice)
Most specialized AI agent sandboxes use Firecracker or Cloud Hypervisor because they provide a hardware-level boundary.
- Why it's preferred for agents: When an LLM writes code, it is "untrusted." A MicroVM provides a real (but tiny) Linux kernel and uses hardware virtualization (KVM). Even if the AI agent manages to crash the guest kernel, it is physically trapped by the CPU’s virtualization features.
- Full Compatibility: Because it’s a "real" Linux environment, the agent can run anything—complex Python libraries, binary C++ extensions, or niche networking tools.
- The Trade-off: Each MicroVM requires its own dedicated slice of RAM and its own guest kernel. This makes them "heavier" than gVisor.
- Who uses it: E2B (the leading agent sandbox), Fly.io, AWS Lambda, and Modal.
The Case for gVisor (The "Scale First" Choice)
gVisor is a software-level boundary. It intercepts system calls in "user-space."
- Why it's preferred for platforms: It is incredibly "thin." You can pack thousands of gVisor sandboxes onto a single physical server because they share more of the underlying resources.
- Cold Start Speed: gVisor can start nearly instantly. While Firecracker is fast (150ms), gVisor is faster. For a platform like Google Cloud, saving 100ms across a billion executions equals massive savings.
- The Trade-off: Security is "softer" than a MicroVM. Since it's an emulation layer, there is a larger "attack surface." Additionally, because gVisor "pretends" to be a Linux kernel, some complex code or system calls might not work perfectly (compatibility issues).
- Who uses it: Google (it powers Gemini’s Code Interpreter and Vertex AI), and Google Cloud Run.
Comparison Table
| Feature | MicroVM (Firecracker) | gVisor |
|---|---|---|
| Isolation Type | Hardware (KVM/Virtualization) | Software (Syscall Interception) |
| Security Level | Maximum. "Escape" is extremely difficult. | High. But "Escape" is theoretically easier. |
| Compatibility | 100%. It is a real Linux kernel. | ~90%. Some low-level calls fail. |
| Density | Lower (More RAM per instance). | Extreme. Very little overhead. |
| Boot Time | ~100ms - 250ms | <50ms |
| Best For | Third-party code execution (Agents). | Internal multi-tenant services at scale. |
The "Agentic" Context: Why MicroVMs are winning the startup war
When a developer allows an AI agent to run code, they are terrified of a "Container Escape."
- If you use gVisor, you are relying on Google’s code to catch every possible malicious trick.
- If you use a MicroVM, you are relying on the CPU hardware itself to block the escape.
For most developers building agents, the hardware boundary of a MicroVM provides the "sleep-at-night" security required to let an LLM run wild.
The Verdict:
- Build with MicroVMs (Firecracker) if you are building an agentic app where the AI will be writing and running its own code, or if you need 100% compatibility with every Python library.
- Build with gVisor if you are building a massive platform with millions of users and your primary goal is reducing the cost of infrastructure and maximizing boot speed.
How do they use KVM differently?
Both gVisor and MicroVMs (like AWS Firecracker) use KVM to create a security boundary, but they use it for fundamentally different architectural reasons.
1. How MicroVMs (Firecracker) use KVM
A MicroVM is essentially a "stripped-down" version of traditional virtualization.
- The Payload: It boots a real, standard Linux Kernel.
- The Role of KVM: KVM is used in the traditional way: it provides hardware-assisted isolation to create a virtual CPU (vCPU) and memory space.
- Syscall Handling: When an application inside a MicroVM makes a system call (e.g.,
open()), it is handled by the Guest Linux Kernel inside that VM. The host kernel never sees that syscall. - Device Emulation: MicroVMs use a minimalist VMM (Virtual Machine Monitor) to provide basic virtio devices (network, block storage).
2. How gVisor uses KVM
gVisor is not a VM; it is a user-space kernel (called the Sentry). It implements the Linux Syscall API in Go.
- The Payload: It does not boot a Linux kernel. It runs the "Sentry" process.
- The Role of KVM: gVisor uses KVM as a "Platform." Instead of using KVM to run a guest OS, it uses KVM's capability to switch the CPU into a restricted mode. This allows the Sentry to intercept every system call the application makes with very low overhead.
- Syscall Handling: When an application inside gVisor makes a system call, the CPU "traps" into the Sentry (via KVM). The Sentry then decides whether to allow the call, simulate it, or pass a safe version of it to the host kernel.
- Device Emulation: There is no hardware emulation. The Sentry handles all file and network I/O.
The flow:
- The Sentry (the gVisor process) opens
/dev/kvm. - It asks the KVM kernel module to set up a sandbox.
- The Sentry then places your application inside that sandbox.