Firecracker

A ~50K-line Rust Virtual Machine Monitor (VMM) that boots a hardware-isolated microVM in ~125ms with <5 MiB overhead. AWS open-sourced it in 2018; it runs every Lambda invocation and Fargate task, and underpins most AI code-execution sandboxes shipped since 2024. Source: X/@kylejeong, 2026-05-11

What it is

Firecracker is the user-space process that talks to /dev/kvm and boots a microVM — a VM with the "1998 PC" deleted (no BIOS, PCI, VGA, USB, or ACPI). AWS announced it at re:Invent in November 2018; it was already running Lambda in production, and the architecture was published at NSDI '20. It was forked from Google's crosvm, rewritten in Rust, with more than half the code removed. Source: X/@kylejeong, 2026-05-11; emirb.github.io/blog/microvm-2026, 2026-06-21

Measured with cloc in March 2026: ~83,000 lines of Rust. The memory-safe language eliminates entire CVE classes (buffer overflows, use-after-free, double-free) at compile time. Source: emirb.github.io/blog/microvm-2026, 2026-06-21

Architecture

Every Firecracker process is one microVM with exactly three thread types Source: X/@kylejeong, 2026-05-11:

• API thread — a REST server on a Unix socket; accepts configuration before boot and limited actions after. Four HTTP PUTs are the entire control plane.
• VMM thread — emulates the devices the guest sees; handles guest device pokes (trapped out by the CPU) and resumes the guest.
• vCPU threads — one per guest CPU, each in a tight loop asking KVM to run the guest until something interesting happens.

The guest sees exactly four devices: virtio-net (NIC → host TAP), virtio-block (disk → host file IO), virtio-vsock (host intercom by context-id/port, no guest IP), and an 8250 serial UART (boot console).

The security onion

A single KVM boundary is already strong; Firecracker wraps two more layers around it Source: X/@kylejeong, 2026-05-11:

• Jailer — boxes up the VMM before it runs: chroot, a new PID namespace, an unprivileged uid/gid, and cgroup limits, then execs Firecracker inside the jail. A guest-to-host escape lands in a chroot with no other processes visible and no root capabilities.
• seccomp — a per-thread syscall allowlist with three levels; Level 2 (default) also constrains argument values (e.g. ioctl only with KVM_RUN). Each thread gets the minimum surface it can.

Each layer must fail independently for an attacker to reach the host.

Snapshots

Firecracker can snapshot a running microVM (memory + device state) and restore it in milliseconds on a different host, into a fresh VMM process — skipping kernel boot, init, and JIT warmup. This is exactly the mechanism behind AWS Lambda SnapStart: snapshot a warmed-up Java Lambda once, restore on every cold start, taking JVM cold starts from 8+ seconds to sub-second. Source: X/@kylejeong, 2026-05-11

Who uses it

AWS Lambda and Fargate (the original use case), Fly.io Machines, E2B, AWS Bedrock AgentCore, and "almost every AI agent code-execution sandbox you've used in the last eighteen months." Performance numbers: ~125ms boot, <5 MiB overhead, ~150 VMs/sec/host, 2–8% runtime overhead. Source: X/@kylejeong, 2026-05-11; emirb.github.io/blog/microvm-2026, 2026-06-21

Firecracker vs Cloud Hypervisor

Both use KVM and share code through Rust VMM; the difference is philosophy. Firecracker is a scalpel — it deliberately removes features to minimize attack surface (no GPU passthrough, no CPU hotplug, no nested virtualization), perfect for short-lived functions. Cloud Hypervisor is a Swiss Army knife that adds nested KVM, VFIO/GPU passthrough, hotplug, and Windows guests at the cost of a slightly larger surface and a few dozen ms slower boot. Deciding question: if your workloads need Docker-in-Docker, GPUs, /dev/kvm inside the VM, or Windows → Cloud Hypervisor; if only ephemeral compute → Firecracker. Source: emirb.github.io/blog/microvm-2026, 2026-06-21

Relevance to Kevin

The reference microVM VMM behind the agent-infra wave central to Dedalus. Dedalus's own VMM, DHV, is a fork of Cloud Hypervisor rather than Firecracker (it needs the heavier feature set), but Firecracker is the canonical example of the design and the one most competitors (E2B, Fly) build on. See MicroVM and Sandbox Isolation Architecture for the architecture and Containers Are Not a Security Boundary for the why.

---

Timeline

• 2026-06-21 | Page created from Kyle Jeong's (Browserbase) Firecracker explainer and emirb's microVM-isolation survey. Captured the three-thread/four-device architecture, the jailer + seccomp security onion, snapshots/SnapStart, the production user list, and the Firecracker-vs-Cloud-Hypervisor fork. Source: X/@kylejeong, 2026-05-11; Source: emirb.github.io/blog/microvm-2026, 2026-06-21