Firecracker: Lightweight Virtualization for Serverless Applications
2020 · NSDI · ~11 min read
Read the original paperServerless needs thousands of strangers' functions on one machine, isolated like virtual machines and starting like processes. Firecracker is the small VM that made both true.
The problem: thousands of strangers on one machine
A serverless platform promises to run your function the moment it is called and to charge you only while it runs. To make that pay, the provider must pack thousands of functions from thousands of unrelated customers onto each physical host, start a new one in a fraction of a second, and guarantee that none of them can read, interfere with or even time-attack another. The two existing tools each failed one requirement. Containers are dense and start in milliseconds but share the host kernel, and the Linux kernel’s attack surface is too large to bet a multi-tenant business on. Virtual machines isolate properly, with hardware help, but a conventional VM carries a full device model and firmware, costs hundreds of megabytes and takes seconds to boot.
The idea: a virtual machine with everything unnecessary removed
AWS Lambda had launched on containers inside dedicated per-customer VMs, which worked and wasted machines. Firecracker is the replacement: a virtual machine monitor that uses the Linux kernel’s KVM for the hardware boundary and implements only what a serverless function needs. No BIOS, no PCI bus, no USB, no graphics; a virtual network device, a block device, a serial console, a keyboard that exists only to signal reboot, and a small configuration API. Written in Rust, forked from Chrome OS’s crosvm, it is around fifty thousand lines where QEMU is well over a million.
How it works
A microVM boots an unmodified Linux kernel in about 125 milliseconds and adds under five megabytes of memory overhead, which is what lets a host run thousands of them; the paper reports creating up to 150 microVMs per second on one host. Memory and CPU are oversubscribed on purpose, since most functions idle most of the time, with rate limiters on network and disk so one tenant cannot starve the others.
Pick a host size and a function's memory. Density is what fits; the race is a cold start, drawn to scale.
| sandbox | isolation | memory overhead | cold start | functions per host |
|---|---|---|---|---|
| traditional VM | hardware (hypervisor) | ~512 MB | ~8000 ms | 204 |
| container | shared kernel (namespaces) | ~8 MB | ~60 ms | 963 |
| Firecracker microVM | hardware (KVM) + minimal device model | ~5 MB | ~125 ms | 985 |
Containers were already dense and fast, but they share the host kernel with every other tenant; a provider cannot put strangers' code there. Virtual machines isolate properly but cost hundreds of megabytes and seconds to start. Firecracker keeps the hardware boundary and throws away everything a serverless function will never use: no BIOS, no PCI bus, five devices, and a 50,000-line VMM instead of a million.
The hardware boundary is not the only one. The VMM runs inside a jailer that drops it into fresh namespaces, a chroot and cgroups, removes its privileges, and applies a seccomp filter so the process can make only a short list of system calls. An attacker who escapes the guest kernel and then the VMM still finds themselves in a jail with nothing to use. The paper calls this defence in depth and treats it as the design rather than an extra.
On top of the microVM, Lambda’s architecture keeps warm microVMs in slots on worker hosts, routes an invocation to an existing slot for that function if one is free, and otherwise creates one; later work added snapshot-and-restore so that a “cold” start can resume a pre-initialised memory image rather than booting at all.
What it changed
Firecracker made hardware-isolated sandboxes cheap enough to be the default, and AWS open-sourced it in 2018, before the paper. It runs Lambda and Fargate, and outside AWS it powers Fly.io’s machines, container runtimes such as Kata Containers, and the sandboxes that code-execution and AI-agent products use to run untrusted code. The broader lesson, that the right unit of isolation for the cloud is a stripped-down VM rather than a hardened container, reshaped how providers think about multi-tenancy.
Where you meet it today
- AWS Lambda and Fargate. Every invocation runs in a Firecracker microVM.
- Sandboxes for untrusted code. CI runners, online IDEs and AI coding agents increasingly execute inside microVMs rather than containers.
- Kata Containers and friends. Kubernetes pods that are secretly tiny VMs.
- The “cold start” conversation. The 125 ms figure, and snapshot-restore to beat it, define what serverless latency means.
The original. Read it after this page; the explainer above is a map, not a substitute.
The open-source project, with design docs and the getting-started guide.
The launch post, with the numbers that motivated it.