microVMs Explained: Firecracker vs gVisor for Secure Workloads in 2026

A Linux container shares one kernel with everything else on the host. That single shared kernel is also the single largest part of the attack surface. The day a multi-tenant platform runs code it does not fully trust — customer functions, CI jobs, AI agents executing tools — that shared kernel stops being an implementation detail and becomes a security decision.

Firecracker and gVisor are the two most widely deployed answers to that decision. Both add isolation between an untrusted workload and the host kernel, but they do it in fundamentally different ways. This article explains how each one works, where they are strong, where they are not, and how to choose between them in production.

The Problem: One Shared Kernel#

Standard container runtimes — Docker, containerd, CRI-O — isolate processes with Linux namespaces and cgroups, and they restrict syscalls with seccomp and capabilities. This is good isolation for trusted code. It is not a security boundary you want to bet a multi-tenant platform on.

The reason is simple: every container calls directly into the same host kernel. The Linux kernel exposes roughly 350 system calls, and a single exploitable bug in any of them can become a container escape. Namespaces reduce what a process can see; they do not change which kernel handles its syscalls.

So the question for untrusted workloads is: how do we stop a compromised workload from reaching the host kernel directly? Firecracker and gVisor give two different answers.

How Firecracker Works#

Firecracker is a virtual machine monitor (VMM). Built by AWS in Rust, it powers AWS Lambda and AWS Fargate. Instead of sharing the host kernel, each Firecracker microVM boots its own guest kernel on top of hardware virtualization (KVM).

The isolation boundary is the hardware virtualization layer. An untrusted workload talks to its own guest kernel; that guest kernel is separated from the host by the CPU's virtualization features. To reach the host, an attacker would have to escape the guest kernel and break out of the VM — a much higher bar than exploiting one host syscall.

Firecracker stays fast by being deliberately minimal:

• A stripped-down device model — only virtio-net, virtio-block, a serial console, and a one-button keyboard controller. No BIOS, no PCI, no USB.
• A boot time around 125 ms to application code.
• A memory overhead of roughly 5 MB per microVM.
• One Firecracker process per VM, sandboxed further with seccomp, namespaces, and cgroups.

That combination — a real VM boundary with near-container startup — is why Firecracker became the default for serverless platforms running millions of short-lived, untrusted invocations.

How gVisor Works#

gVisor takes the opposite approach: it does not use hardware virtualization at all. Built by Google and used in Google Cloud Run and GKE Sandbox, gVisor inserts a userspace kernel — a component called runsc — between the workload and the host.

When a sandboxed process makes a system call, it never reaches the host kernel directly. The call is intercepted and served by gVisor's own kernel, written in Go, which re-implements a large part of the Linux syscall surface in userspace. Only a small, tightly controlled set of operations is ever forwarded to the host.

The effect is a dramatically smaller host attack surface. The workload can issue any syscall it likes, but it is talking to runsc, not to the host. A bug in the emulated syscall affects the sandbox, not the host kernel.

The trade-offs are different from Firecracker:

• No KVM required, which matters in nested-virtualization environments where you cannot get hardware virtualization (some cloud VMs, some CI runners).
• Syscall overhead: every intercepted call pays a userspace round-trip. Syscall-heavy and I/O-heavy workloads feel this most.
• Compatibility gaps: because gVisor re-implements the kernel, some less-common syscalls or /proc features are unsupported or behave differently.

Firecracker vs gVisor: Side-by-Side#

Performance: What Actually Costs You#

The honest summary is that neither option is free, and the cost shows up in different places.

Firecracker pays its cost at boot and memory: you spin up a real (if tiny) VM, so there is a per-VM kernel and memory floor. For long-running services this overhead is negligible; for very high-churn, sub-second workloads it is the thing you tune.

gVisor pays its cost per syscall. CPU-bound work that rarely touches the kernel runs close to native. But workloads that hammer the kernel — lots of small network calls, heavy file I/O, frequent fork/exec — pay a measurable tax because every one of those calls is intercepted.

A useful rule of thumb:

• Compute-heavy, syscall-light → gVisor's overhead is small.
• I/O-heavy or syscall-heavy → Firecracker's model often wins.
• Strongest isolation per dollar of risk → Firecracker's VM boundary is easier to reason about for compliance.

How to Choose#

The decision is rarely about which technology is "better." It is about your constraints. Here is the framework I use.

Choose Firecracker when:

• You run genuinely untrusted, multi-tenant code (functions-as-a-service, customer-submitted jobs, sandboxed AI tool execution).
• You can get KVM (bare metal or nested virtualization is available).
• You want the cleanest possible isolation story for auditors: a VM boundary is well understood.

Choose gVisor when:

• You cannot get hardware virtualization (some managed environments, nested CI).
• You want container-native ergonomics and a drop-in OCI runtime (runsc) under Kubernetes.
• Your workloads are compute-bound and tolerant of minor syscall compatibility gaps.

Stay with standard containers + seccomp when:

• The code is trusted (your own services), and namespaces, cgroups, seccomp, and a hardened profile are an appropriate boundary. Do not pay isolation overhead you do not need.

Where This Fits in a Security Architecture#

microVMs and userspace kernels are one layer, not a complete strategy. In a defense-in-depth design they sit alongside, not instead of:

• least-privilege IAM and short-lived credentials,
• network policy and egress control around the sandbox,
• seccomp and capability dropping even inside the sandbox,
• image provenance and supply-chain verification for what runs in the first place.

The sandbox limits blast radius when something inside it is compromised. It does not remove the need for the rest of the controls.

Frequently Asked Questions#

Is gVisor a virtual machine? No. gVisor does not use hardware virtualization. It runs a userspace kernel (runsc) that intercepts the workload's system calls and serves them itself, forwarding only a small set to the host kernel.

Is Firecracker slower than a container? At steady state, no. A running Firecracker microVM performs close to a container. The visible cost is startup (~125 ms) and a small per-VM memory floor, which matters only for very high-churn workloads.

Can I run Firecracker or gVisor under Kubernetes? Yes. gVisor ships an OCI runtime (runsc) usable as a RuntimeClass. Firecracker integrates through projects like Kata Containers and firecracker-containerd to present a CRI-compatible runtime.

Which is more secure, Firecracker or gVisor? Both reduce the host attack surface significantly. Firecracker's hardware-virtualization boundary is generally easier to reason about for compliance, while gVisor's userspace kernel shrinks the host syscall surface without needing KVM. The right answer depends on your threat model and infrastructure.

Do I need either if my code is trusted? Usually not. For first-party, trusted workloads, namespaces plus a strong seccomp profile are typically sufficient. Reserve microVMs and gVisor for code you do not fully trust.

Takeaway for 2026#

The shared host kernel is the quiet assumption behind most container deployments, and it is fine — until you run code you do not trust. At that point you need a real boundary.

Firecracker gives you that boundary with hardware virtualization and near-container startup, which is why it underpins serverless at scale. gVisor gives you a smaller host attack surface without KVM, which is why it fits container-native platforms that cannot assume bare metal.

Pick based on three things: whether you can get KVM, how syscall-heavy your workloads are, and how strong an isolation story your auditors need. Match the boundary to the threat — and do not pay for isolation your workloads do not require.