MicroVM

A microVM is a hardware-virtualized VM stripped to the parts a single workload needs: a small VMM (typically 80-110K lines of Rust instead of QEMU's 1.7M lines of C), 4-5 emulated devices instead of dozens, and a guest kernel chosen for boot speed instead of generality. The result is a VM that boots in ~125 ms with <5 MiB of memory overhead but still gets the full hardware boundary KVM provides.

The category got a name and a working reference implementation when AWS open-sourced Firecracker in 2018, having built it for Lambda. By 2026 it's the substrate underneath most serious AI-agent sandboxing — see microvm-2026 for the industry readout, matryoshka-isolation for how microVMs nest with containers.

What "micro" means

A microVM is "micro" along five axes:

VMM size. Firecracker is ~83K lines of Rust; Cloud Hypervisor is ~106K. Both are dramatically smaller than QEMU and have correspondingly smaller attack surfaces.
Emulated device count. Firecracker emulates ~5 devices (virtio-net, virtio-block, virtio-vsock, serial, KVM clock). No legacy PCI, no USB, no audio, no graphics. The principle: every device is attack surface, so don't ship the ones you don't need.
Boot time. ~125 ms cold for Firecracker, ~28 ms with snapshot-restore, <20 ms for FreeBSD-tuned setups (Colin Percival), ~200 ms for a minimal Linux 6.18 boot. Compare 30-60 s for a traditional VM, 3-15 s for a Kubernetes pod schedule.
Memory overhead. <5 MiB per VM, which makes "VM per request" or "VM per agent session" viable rather than absurd.
Featureset. No nested virtualization, no GPU passthrough, no CPU hotplug, no Windows guest support — at least not in the canonical Firecracker. Cloud Hypervisor adds these back at the cost of size and slightly slower boot, occupying the "Swiss Army knife" position.

Why hardware isolation matters

Containers (namespaces + cgroups + seccomp) share the host kernel. The Linux kernel is ~40M LOC of C with 450+ syscalls — a continuously-updated attack surface. Container escape CVEs land regularly (CVE-2024-21626 Leaky Vessels, CVE-2025-9074 Docker Desktop, CVE-2025-23266 NVIDIAScape, several runc CVEs in 2025; the microvm-2026 table catalogues them).

A microVM replaces the shared kernel boundary with a hardware boundary. The guest kernel is isolated; an exploit inside has to break out of the VM via a hypervisor CVE, which is rare enough that working hypervisor exploits sell for $250K-$500K bounties. The trade is real engineering complexity for a much smaller and slower-moving attack surface.

The Firecracker / Cloud Hypervisor split

The two reference VMMs in 2026:

Firecracker (AWS) — "scalpel." Built for Lambda. Five devices, no GPU, no nested virt, no hotplug, no Windows guest. ~83K LOC Rust. Best for short-lived single-purpose workloads.
Cloud Hypervisor (Intel-led, multi-vendor) — "Swiss Army knife." Nested KVM (since Dec 2025), VFIO device passthrough, CPU/memory hotplug, Windows guests. ~106K LOC Rust. Slightly slower boot, slightly bigger attack surface.

Decision criteria from microvm-2026: pick Cloud Hypervisor if you need /dev/kvm inside the VM (Docker-in-Docker, Android emulators), Windows, or complex hotplug. Otherwise Firecracker.

Both share the rust-vmm crate ecosystem — improvements to vm-memory or virtio-queue benefit both, plus libkrun, Dragonball, crosvm, and others.

Where microVMs are running in 2026

AWS Lambda — every function invocation since 2018 runs inside Firecracker
Fly.io Machines — Firecracker since 2020
Kata Containers — drop-in OCI runtime that puts a microVM behind every Kubernetes pod (QEMU/Cloud Hypervisor/Firecracker backends)
Spindle — Tangled's self-hostable CI runner: one QEMU microVM per workflow, NixOS configured from the workflow YAML, a Rust vsock guest agent
AI-agent sandboxes — Fly.io Sprites, E2B, Vercel Sandbox, AWS Bedrock AgentCore, Microsandbox, Docker Sandboxes (Desktop 4.58, Jan 2026), and ~10 more (see microvm-2026)
Chrome OS — crosvm runs Linux (Crostini) and Android VMs on Chromebooks
Lima (CNCF Incubating) — macOS Linux-VM tooling, 20K★, expanded into agent sandboxing in 2026

Adjacent things microVMs aren't

Application kernel sandboxes (gVisor, when its page exists). Userspace Linux kernel reimplementation in Go. ~50 ms startup, smaller memory footprint, GPU compatibility via nvproxy. No hypervisor, no guest kernel — different point on the isolation/compatibility spectrum.
V8 isolates (Cloudflare Workers). Sub-ms startup but JS-only, no Linux interface. Different category.
Container-only (runc, namespaces, cgroups). Different security model — see microvm-2026 for the head-to-head.

Operational reality

The honest cost of microVMs isn't performance overhead (single-digit %) — it's operations. You manage:

A guest kernel (build, sign, ship, patch)
A rootfs image (build, version, distribute)
A VMM (deploy, monitor, sandbox itself)
Networking (TAP devices or virtio-net + bridge), unless you're using libkrun's transparent socket impersonation
Storage (virtio-block + a backing format)

This is genuine engineering work. The article's framing: it's worth it when you run untrusted code, when you need multi-tenant isolation, or when you operate at a scale where a single container escape costs more than the VMM operational burden.

Notable VMMs and their roles

rust-vmm — shared crate ecosystem; nearly all modern microVMs are downstream of it
Firecracker — AWS, the canonical "small Lambda VMM"
Cloud Hypervisor — multi-vendor; the larger-featureset general-purpose option
libkrun (Red Hat) — library-based VMM, sub-200 ms startup, transparent socket impersonation, paravirtualized GPU on macOS; powers Microsandbox and crun
crosvm (Google) — Chrome OS VMM, rust-vmm proof point
QEMU microvm — QEMU's stripped-down option (-M microvm): no PCI, no ACPI, virtio-mmio only, qboot firmware, direct kernel boot, triple-fault shutdown; older and larger than the Rust VMMs but matures features Firecracker won't add and serves as the C-vintage reference implementation of the same architecture