Learn Firecracker - Core Concepts & Main Architecture

#Introduction

In episode 1 we understood why Firecracker exists: hardware isolation for serverless with lightning-fast boot and minimal overhead. Now it's time to open the hood and see how that design is realized. Episode 2 dissects Firecracker's core concepts and main architecture — the process model, the comparison with QEMU, virtio devices, the rate limiter, the jailer, and the API.

Why is this episode important? Because the entire rest of this series — networking, storage, snapshot, scaling, all the way to observability — is a consequence of the architectural decisions discussed here. One process per microVM explains why density of thousands of VMs per host is possible; the virtio device family explains why devices can only be added before boot; the rate limiter explains how a single host can serve many tenants without them fighting over bandwidth.

#One Process, One MicroVM

The most important mental model for Firecracker is: one Firecracker process = one microVM. There is no central daemon managing many VMs. Every running firecracker is an independent VM, with its own memory, API socket, and lifecycle.

The analogy: think of Docker containers — one daemon manages many containers. Firecracker is the opposite — like running a single nginx process for one site. The consequences:

• Isolation at the OS level: if one VM is broken into, the attacker only gets that Firecracker process — not a daemon controlling hundreds of other VMs.
• Simple kill and recovery: kill the process, kill the VM. No global state that can become corrupted.
• High density: because every VM is a lightweight process (< 5 MiB overhead), a single host can hold thousands of processes — and the host kernel handles their scheduling.

Firecracker does support running more than one microVM per process in certain configurations (for example, with vmgenid or multiple APIs), but the canonical model and AWS production practice is one process per VM, reinforced by the jailer in episode 7.

#Rust VMM vs QEMU

Firecracker's approach differs fundamentally from QEMU:

• QEMU: a general-purpose VMM — full emulation of various architectures, many devices, hotplug, GUI, and more. Feature-rich, but big and slow, with a wide attack surface.
• Firecracker: a narrow VMM — KVM only, only curated virtio devices, no exotic device emulation. Less code, faster, safer.

One important architectural detail: Firecracker does not emulate devices in userspace for its main devices. It leverages KVM and virtio so that device data flows directly between guest and host without expensive CPU interpretation. That's why its overhead can be pushed far below QEMU's.

The Firecracker process hosts several threads: the main VMM thread, the API thread, the vCPU threads (one per vCPU), and one thread per device. This threading preserves isolation — an error in a device thread doesn't immediately take down the whole VM.

#The Virtio Device Family

All of Firecracker's microVM I/O devices use the virtio specification: the paravirtualized device standard that the guest kernel recognizes through built-in drivers. Because the drivers are already in the kernel, the guest needs no additional vendor drivers. The device family Firecracker supports:

• virtio-net — network interface. The most common device: connects the microVM to a host TAP interface.
• virtio-block — block disk. Attaches the rootfs and additional disks as image files on the host.
• virtio-vsock — host↔guest sockets without IP networking. Ideal for control-plane communication and in-guest agents.
• virtio-balloon — reclaims memory from the guest back to the host (episode 10).
• virtio-rng — guest entropy, a source of randomness for cryptography.
• virtio-vmem (in 1.16) and other devices — supporting the latest features.

Devices can only be added before the VM is started. After InstanceStart, device configuration is locked — a consequence of the boot once, then immutable design. Making a change means creating a new VM or using a snapshot (episode 9).

#Token Bucket Rate Limiter

Every virtio-net and virtio-block device can be wrapped in a token bucket-based rate limiter. The concept is simple: a bucket holds tokens; each packet or byte that passes consumes a token; the bucket is refilled at a fixed rate. Two dimensions can be limited: bandwidth (bytes/sec) and ops (ops/sec), each with the parameters size (bucket capacity), refill_time (refill interval), and one_time_burst (initial burst).

This isn't a secondary feature — it's the heart of the multi-tenant model. Without a rate limiter, one microVM could monopolize host bandwidth and ruin the experience of all its neighbors. With a rate limiter, per-VM bandwidth SLAs can be promised contractually, exactly as AWS does for Firecracker-based services. We'll practice the configuration details in episode 5.

#Main Components: firecracker, jailer, and the API

Firecracker's architecture revolves around a few key components:

• The firecracker binary — the VMM itself. Reads configuration, exposes the API, runs vCPUs, and manages devices.
• The jailer — the security wrapper. Wraps the Firecracker process in namespaces, cgroups, seccomp, a read-only rootfs, and a non-root user. Details in episode 7.
• The API endpoint — all interaction with the microVM happens through an HTTP API on a Unix socket: PUT /boot-source, PUT /machine-config, PUT /drives, PUT /network-interfaces, PUT /snapshot/create, and InstanceStart via /actions.

The API is the only way to manage a microVM — there's no firecracker start command. Orchestrators like firecracker-containerd or Flintlock are, at their core, smart API clients.

#MMDS: The Metadata Service

MicroVMs often need dynamic configuration: their own IP address, credentials, or workload metadata. For this, Firecracker provides MMDS (MicroVM Metadata Service) — a metadata server exposed to the guest at 169.254.169.254, similar to the EC2 metadata service.

The host writes JSON data to MMDS via PUT /mmds, then the guest reads it with an HTTP GET to that address. Because the IP is reserved link-local, this data never leaves to the outside network — ideal for distributing secrets or boot configuration without exposing them over the network: the data is available before applications in the guest start running. We'll use MMDS in episode 6.

#MicroVM Lifecycle

A microVM goes through a clear lifecycle:

1. Configure — the Firecracker process is launched (usually via the jailer), the API socket is created, and configuration is sent: kernel, machine config, drives, network.
2. Start — InstanceStart loads the kernel and begins execution; devices are locked.
3. Run — the guest runs; communication happens over network, vsock, or the serial console.
4. Pause/snapshot/suspend — state can be frozen and saved (episode 9).
5. Stop — the process is terminated; all resources are released.

Each stage has its own API and tooling. Understanding this lifecycle makes the following episodes — most of which are variations of these stages — far easier to follow.

#Closing

The key takeaways:

• One Firecracker process = one microVM; OS-level isolation, high density.
• Firecracker is minimalist vs QEMU's general-purpose; device emulation is kept off the data path.
• Devices can only be configured before start; settings are locked after boot.
• The token bucket rate limiter (bandwidth + ops) is the basis of multi-tenant isolation.
• Main components: firecracker, jailer, the Unix socket API, and MMDS.
• VM lifecycle: configure → start → run → pause/snapshot → stop.

In the next episode 3 we'll stop theorizing and start the engine: setup and installation — downloading the v1.16.x binaries, preparing the kernel and rootfs, verifying KVM and cgroup, running firecracker --api-sock, and understanding the difference between --no-api mode (fast boot via command line) versus API mode. Get ready for your first microVM!