Cloud Parts

Firecracker

The open-source microVM monitor AWS built for Lambda: a full VM boundary that boots in under 125 ms.

What it is
MicroVMs,Hypervisors
Type
Open source
Made by
Amazon Web Services
License
Apache 2.0
Facts checked
5 October 2026
Website Source code

What it is

Firecracker is a small virtual machine monitor written in Rust. It runs on Linux and uses the kernel’s KVM to give each microVM its own guest kernel, just like a normal VM. What it leaves out is the point: there is no BIOS and no USB, and a standard microVM gets only six emulated devices (a virtio network card, disk, vsock and memory balloon, a serial console, and a minimal keyboard controller used only to stop the VM).

With so little to start, a microVM boots in under 125 ms with less than 5 MiB of memory overhead, and one host can create up to 150 microVMs per second. Each Firecracker process runs exactly one microVM and is configured through a REST API on a Unix socket. AWS built it for Lambda and Fargate. It still runs Lambda, but AWS has since said that its published details of Fargate’s data plane, including references to Firecracker, are no longer accurate. Other projects, such as Kata Containers, use it to give each workload a hardware-isolated sandbox without paying a full VM’s start-up cost.

Why teams pick it

  • VM-grade isolation (a separate kernel per workload) at near-container speed and density
  • Tiny attack surface: few devices, written in a memory-safe language, and a jailer that sandboxes the process itself
  • Snapshots let a platform restore a booted microVM instead of booting a new one
  • Battle-tested underneath AWS Lambda, which AWS says handles more than 15 trillion invocations a month

Watch out for

  • A building block, not a platform: you bring the kernel, root filesystem, networking and scheduler
  • The host must be Linux with KVM; on EC2 that means .metal instances
  • Linux guests (plus OSv) only, and no GPU passthrough in a release yet: VFIO device passthrough is still an open feature request

Alternatives

What all microvms have in common →
Kata ContainersOpen sourceA container runtime that starts each pod inside its own lightweight VM, so Kubernetes and Docker keep working but every pod gets its own kernel.smolvmOpen sourceA young, embeddable microVM runtime that boots any OCI image as a real VM on a Mac, Linux or Windows laptop, and can save, branch and pack running machines.

How it fits with other technologies

Configure and boot a microVM through its API socket · bash

firecracker --api-sock /tmp/fc.sock &

curl --unix-socket /tmp/fc.sock -X PUT http://localhost/machine-config \
  -d '{"vcpu_count": 2, "mem_size_mib": 1024}'
curl --unix-socket /tmp/fc.sock -X PUT http://localhost/boot-source \
  -d '{"kernel_image_path": "vmlinux", "boot_args": "console=ttyS0 reboot=k panic=1"}'
curl --unix-socket /tmp/fc.sock -X PUT http://localhost/drives/rootfs \
  -d '{"drive_id": "rootfs", "path_on_host": "rootfs.ext4", "is_root_device": true, "is_read_only": false}'
curl --unix-socket /tmp/fc.sock -X PUT http://localhost/actions \
  -d '{"action_type": "InstanceStart"}'

See it in a real stack

Code sandboxes for AI agents →
Live model
What you’re watchingAgents send code to run. The API checks quotas, the scheduler places each task on a host, and a fresh microVM boots (amber) to run it. Outputs go to S3 and the result returns to the agent. Idle microVMs are discarded.

Compared side by side

Kata Containers, gVisor or Firecracker?

Worth exploring

Article· October 2020Is there a way to containerized a normal AWS Lambda function?Stack Overflow question by Sivvie LimA newcomer asks how to move an SNS-triggered Lambda function into a container on EKS. The answers, from October 2020, point to the lambci/docker-lambda images (since deprecated in favour of AWS’s official Lambda base images) and to Knative; read it mainly for the question, which is a common one, rather than for current tooling.
All resources →
Where it came from2014–2026

When AWS launched Lambda in 2014 it had to pick between two ways of keeping customers apart. Containers were fast and cheap but shared one kernel; virtual machines gave a hard boundary but were slow to start and heavy. AWS chose VMs. As customers asked for faster scaling and lower latency, those VMs became the bottleneck, and the standard tool for running them, QEMU, carried about 1.4 million lines of code emulating decades of PC hardware that a function never touches.

An AWS team started instead from crosvm, the Rust virtual machine monitor Google wrote for Chrome OS, and cut it down to the few devices a serverless workload needs. AWS announced and open-sourced the result as Firecracker on November 26, 2018, saying it already powered Lambda and Fargate. AWS has since added a note that its Fargate references to Firecracker are no longer accurate. A 2020 NSDI paper by Alexandru Agache, Marc Brooker and colleagues described the design: about 50,000 lines of Rust, boot in under 125 ms, under 5 MiB of overhead per microVM.

Firecracker showed that VM-grade isolation could start almost as fast as a container. AWS now builds on its snapshots too, restoring pre-initialised Lambda functions with SnapStart, and other projects such as Kata Containers use it as a sandbox.

Why it’s built this way

Emulate almost no hardware
There is no BIOS, USB or display, only a handful of virtio devices, and until optional PCI support arrived in version 1.13 (2025) there was no PCI bus either. Every device left out is code that doesn’t run at boot and can’t be attacked, which is where the speed and small footprint come from.
Written in Rust
A hypervisor is a security boundary between strangers. AWS picked Rust because the language enforces thread safety and prevents buffer overflows, two common sources of security holes.
Fork crosvm rather than slim down QEMU
crosvm was already a small, modern VMM in a memory-safe language; AWS replaced its devices with a minimal model. Firecracker has since diverged, and shares components with crosvm through the rust-vmm project.

Timeline

  1. 2014

    Lambda launches on traditional per-customer virtual machines

  2. 2018

    Announced and open-sourced under Apache 2.0 at re:Invent, November 26

  3. 2020

    NSDI paper describes Firecracker’s design and production use

  4. 2022

    Version 1.0 in January; Lambda SnapStart restores Firecracker snapshots

  5. 2026

    AWS launches Lambda MicroVMs, stateful sandboxes built on Firecracker

Sources11 · facts checked 5 October 2026

Improve this page on GitHub