Process and machine architecture
The API thread exposes a Unix-domain HTTP API. The VMM thread builds the machine and handles device emulation. One vCPU thread runs each configured guest CPU through KVM.
Firecracker exposes VirtIO block, network, and vsock devices, a metadata service, and rate limiters. Removing legacy devices reduces code paths and guest-visible surface.
Firecracker is a purpose-built machine contract, not a smaller implementation of every QEMU feature.
Boot flow
Jailer, cgroups, and seccomp
The project recommends the jailer for production. It creates cgroups, establishes namespaces, prepares a private mount tree, enters a chroot-like jail, exposes required devices, applies resource limits, and drops privileges before running Firecracker. Firecracker then applies thread-specific seccomp-BPF filters. The project advises against disabling seccomp or weakening filters in production. These controls are defense in depth around KVM. They do not eliminate the need for current host and guest kernels, microcode, secure orchestration, and explicit CPU and memory limits. The jailer constrains the VMM process; KVM remains the guest virtualization boundary.Snapshot creation and restore
Firecracker can pause a microVM and create full or differential snapshots. Snapshot output separates serialized microVM state from guest memory. Disks, TAP interfaces, and vsock endpoints remain external. A new Firecracker process loads the snapshot before boot. Memory can be demand-paged from a mapped file with copy-on-write behavior. Differential snapshots require dirty-page tracking and add accounting overhead. Restore requires compatible snapshot format, CPU architecture and features, device configuration, host behavior, and external resources. Intel-to-AMD restore is unsupported. A Firecracker snapshot is operational VM state, not a portable machine image like an AMI.Lambda, Fargate, and the public boundary
AWS publicly states that Firecracker was developed for services including Lambda and Fargate. This establishes the technology relationship, but not each service’s current host topology, orchestration, snapshot strategy, or complete security configuration. A self-managed Firecracker host does not reproduce Lambda or Fargate. Those services add fleet management, networking, storage, identity, scaling, metering, and operations.Operational limits
Firecracker requires a Linux host with hardware virtualization and KVM access. Its minimalism means firmware boot, arbitrary PCI hardware, desktop devices, and broad VM tooling cannot be presumed. The local API socket is not a tenant authentication system. The orchestrator must protect it, stage trusted artifacts, allocate networking, enforce cgroups, collect metrics, and clean resources.Frequently asked questions
Is a Firecracker microVM a container?
Is a Firecracker microVM a container?
No. A microVM runs its own guest Linux kernel across a KVM hardware-virtualization boundary. Containers normally share the host kernel. Firecracker can host containerized workloads, but its isolation unit remains the virtual machine.
Does the jailer replace KVM isolation?
Does the jailer replace KVM isolation?
No. KVM and hardware virtualization form the primary guest boundary. The jailer, seccomp, namespaces, cgroups, filesystem isolation, resource limits, and dropped privileges constrain the Firecracker host process as defense in depth.
Can a snapshot resume on any host?
Can a snapshot resume on any host?
No. Restore requires compatible format, CPU architecture and features, suitable host behavior, matching devices, and expected block, network, and vsock resources. A snapshot is tied to a controlled environment rather than being a portable AMI.