# 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-microvm|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|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 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

## See also

- [[microvm-2026]] — Beganović's industry readout, the canonical reference
- [[qemu-microvm]] — QEMU's microvm machine type, the C-vintage reference implementation
- [[matryoshka-isolation]] — containers-inside-VMs pattern that's emerging as the dominant architecture
- [[rust-vmm]] — the shared infrastructure under all of these
- [[sandboxing-ai-agents]] — broader sandboxing taxonomy
- [[virtual-machines-versatile-platforms]] — Smith and Nair's taxonomy, the background reading for why "VM" means both a JVM and a Firecracker guest; predates KVM but the ISA-level vs OS-level vs application-level split is what makes the microVM/gVisor/V8-isolate comparison above line up
- [[toolbox/superhq]] — agent orchestrator using microVMs as Layer 1
- [[toolbox/pve-microvm]] — the same architecture packaged for a homelab Proxmox node: host-provided kernel, kernel-agnostic OCI rootfs, sub-300ms boot