Firecracker

Firecracker is an open-source virtualization technology purpose-built for serverless and container workloads. It runs workloads inside lightweight virtual machines called microVMs, combining the strong security isolation of hardware virtualization with the speed and resource efficiency of containers. It was developed at Amazon Web Services and is the technology powering AWS Lambda and AWS Fargate under the hood.

Features

• Sub-second boot times — microVMs boot in under 125ms, making cold starts viable for serverless functions
• Minimal memory footprint — each microVM has an overhead of less than 5MB of memory, enabling extremely high density on a single host
• Strong isolation — hardware virtualization (KVM) provides a much stronger security boundary than container namespaces alone; each workload is fully isolated
• Minimalist design — deliberately excludes unnecessary virtual devices and guest functionality to reduce the attack surface; no BIOS, no USB, no GPU passthrough
• Rate limiting — built-in rate limiters for network and disk I/O on a per-microVM basis
• Snapshot and restore — pause a running microVM, snapshot its full state to disk, and restore it later — useful for fast cloning and warm pools
• REST API — Firecracker exposes a local REST API (over a Unix socket) for configuring and managing microVMs programmatically
• Jailer — a companion process that drops privileges and applies cgroup/namespace isolation before launching Firecracker, hardening production deployments
• Written in Rust — the entire VMM is implemented in Rust, minimising memory safety bugs in the security-critical virtualization layer

How it works

Firecracker is a Virtual Machine Monitor (VMM) that uses Linux KVM to create and manage microVMs. Unlike a full hypervisor (QEMU, VirtualBox), Firecracker:

• Emulates only the minimum set of devices needed (virtio-net, virtio-block, serial console, keyboard for reboot/shutdown)
• Does not include a BIOS or legacy hardware emulation
• Communicates with the host exclusively through a local REST API over a Unix socket
• Runs as an unprivileged process (when used with the Jailer)

Each microVM runs a real Linux kernel and a minimal root filesystem. From the guest's perspective it is a normal virtual machine; from the host's perspective it is an extremely lightweight, fast, and isolated process.

Installation

Download a pre-built binary from the releases page:

# Download the latest release (x86_64)
ARCH=$(uname -m)
release_url="https://github.com/firecracker-microvm/firecracker/releases/latest/download"
curl -L "${release_url}/firecracker-v1.15.0-${ARCH}.tgz" | tar -xz

# Make executable
mv release-v1.15.0-${ARCH}/firecracker-v1.15.0-${ARCH} /usr/local/bin/firecracker
chmod +x /usr/local/bin/firecracker

# Debian / Fedora
# No apt/dnf package available. Pre-built binaries for both x86_64 and aarch64
# Linux are provided on the releases page. The download commands above detect
# your architecture automatically via $(uname -m) and work on Debian and Fedora.

Or build from source (requires Docker for the dev container):

git clone https://github.com/firecracker-microvm/firecracker
cd firecracker
tools/devtool build

Requirements: Firecracker requires a Linux host with KVM support. Check that /dev/kvm exists and is accessible:

ls -la /dev/kvm
# You may need to add your user to the kvm group:
sudo usermod -aG kvm $USER

Launching a microVM

Firecracker is configured entirely through its REST API. A typical startup flow:

1. Start the Firecracker process

# Firecracker listens on a Unix socket
rm -f /tmp/firecracker.socket
firecracker --api-sock /tmp/firecracker.socket

2. Configure the microVM via API

In a separate terminal, send REST requests to configure and boot the VM:

API="curl -s -X PUT --unix-socket /tmp/firecracker.socket http://localhost"

# Set the guest kernel
$API/boot-source \
  -H "Content-Type: application/json" \
  -d '{
    "kernel_image_path": "/path/to/vmlinux",
    "boot_args": "console=ttyS0 reboot=k panic=1 pci=off"
  }'

# Set the root filesystem
$API/drives/rootfs \
  -H "Content-Type: application/json" \
  -d '{
    "drive_id": "rootfs",
    "path_on_host": "/path/to/rootfs.ext4",
    "is_root_device": true,
    "is_read_only": false
  }'

# Configure machine resources
$API/machine-config \
  -H "Content-Type: application/json" \
  -d '{
    "vcpu_count": 2,
    "mem_size_mib": 1024
  }'

# Add a network interface
$API/network-interfaces/eth0 \
  -H "Content-Type: application/json" \
  -d '{
    "iface_id": "eth0",
    "guest_mac": "AA:FC:00:00:00:01",
    "host_dev_name": "tap0"
  }'

# Boot the microVM
curl -s -X PUT \
  --unix-socket /tmp/firecracker.socket \
  http://localhost/actions \
  -H "Content-Type: application/json" \
  -d '{"action_type": "InstanceStart"}'

Snapshots

Firecracker supports full VM snapshots — pausing execution, saving memory and device state to disk, and resuming later:

# Create a snapshot
curl -X PUT --unix-socket /tmp/firecracker.socket \
  http://localhost/snapshot/create \
  -H "Content-Type: application/json" \
  -d '{
    "snapshot_type": "Full",
    "snapshot_path": "/tmp/snapshot_file",
    "mem_file_path": "/tmp/mem_file"
  }'

# Resume from snapshot (start a new Firecracker process, then load)
curl -X PUT --unix-socket /tmp/firecracker.socket \
  http://localhost/snapshot/load \
  -H "Content-Type: application/json" \
  -d '{
    "snapshot_path": "/tmp/snapshot_file",
    "mem_backend": {
      "backend_path": "/tmp/mem_file",
      "backend_type": "File"
    },
    "enable_diff_snapshots": false,
    "resume_vm": true
  }'

Snapshots are how AWS Lambda achieves fast cold starts for popular runtimes — the runtime is snapshotted after initialisation and restored for each new execution environment.

Production use with the Jailer

The Jailer wraps Firecracker with additional isolation for production deployments:

jailer --id my-vm-1 \
  --exec-file /usr/local/bin/firecracker \
  --uid 1000 \
  --gid 1000 \
  --chroot-base-dir /srv/jailer \
  -- \
  --api-sock /api.socket

The Jailer applies a cgroup hierarchy, a filesystem chroot, and drops all unnecessary Linux capabilities before exec-ing Firecracker, significantly hardening the isolation boundary.

Use cases

• Serverless platforms — power function-as-a-service workloads where each invocation runs in its own isolated microVM (AWS Lambda's approach)
• CI/CD — run each CI job in a fresh, isolated microVM rather than a shared container for stronger security guarantees
• Multi-tenant containers — provide VM-level isolation between container workloads from different tenants on shared hardware
• Edge computing — the minimal overhead and fast startup make Firecracker viable on resource-constrained edge nodes