← Back to research
·11 min read·opensource

Firecracker

Firecracker is AWS's open-source, Rust-based virtual machine monitor that boots secure KVM microVMs in as little as 125ms with under 5 MiB overhead — the isolation substrate behind AWS Lambda, Fargate, Fly.io, and AI sandbox platforms like E2B.

https://firecracker-microvm.github.io ↗
container-vm-runtimesopen-sourceawsrust

Key takeaways

  • The microVM archetype — purpose-built at AWS for Lambda and Fargate, where it hosts millions of production workloads serving trillions of requests per month, per the NSDI 2020 paper
  • Container-like speed with VM-grade isolation: 125ms boot, under 5 MiB memory overhead per microVM, and creation rates up to 150 microVMs per second per host
  • Deliberately minimal by design — no GPU passthrough and a tiny device model; teams needing PCIe devices or multi-resume snapshots look to Cloud Hypervisor or QEMU instead

FAQ

What is Firecracker?

Firecracker is an open-source virtual machine monitor (VMM) from AWS that uses Linux KVM to run lightweight "microVMs," combining the hardware isolation of virtual machines with the speed and density of containers.

How much does Firecracker cost?

Firecracker is free and open source under the Apache 2.0 license. Costs come from the infrastructure you run it on and the engineering effort to build a platform around it.

Who uses Firecracker in production?

AWS built Firecracker for Lambda and Fargate, where it serves trillions of requests per month. Outside AWS, it powers Fly.io, Koyeb, Kata Containers integrations, and AI agent sandbox platforms such as E2B.

How is Firecracker different from Kata Containers?

Firecracker is a low-level VMM — a building block, not a runtime; Kata Containers is an OCI-compatible container runtime that can use Firecracker (or QEMU/Cloud Hypervisor) as its hypervisor underneath.

Executive Summary

Firecracker is an open-source virtualization technology purpose-built for creating and managing secure, multi-tenant container and function-based services. It is a minimal virtual machine monitor (VMM) that uses Linux KVM to launch lightweight "microVMs" — booting user-space code in as little as 125ms, with less than 5 MiB of memory overhead per microVM and creation rates up to 150 microVMs per second per host.[1] Developed at AWS (repository created October 2017) and written in Rust, it carries 34,800+ GitHub stars and 2,400+ forks as of June 2026.[2]

Firecracker is the archetype of the microVM category: the NSDI 2020 paper from its AWS authors documents it hosting millions of production workloads and trillions of requests per month across AWS Lambda and Fargate.[3] That production pedigree has made it the default isolation substrate for platforms running untrusted code — Fly.io, Koyeb, and Kata Containers integrations build on it,[1] and AI agent sandbox vendors such as E2B chose it specifically for hardware-level isolation of AI-generated code.[4] Its discipline is also its constraint: Firecracker deliberately excludes non-essential devices — including GPU/PCIe passthrough — to minimize attack surface.[5]

AttributeValue
CreatorAmazon Web Services[1]
FoundedRepo created October 2017; built for AWS Lambda and Fargate[2]
FundingAWS-backed open source (no separate entity)
GitHub Stars34,800+ (June 2026)[2]
LicenseApache 2.0[1]

Product Overview

Firecracker is not a container runtime you docker run — it is the layer underneath. You (or a platform you use) launch the firecracker process with a guest kernel and root filesystem, configure it over a RESTful API, and get a microVM with its own kernel behind a KVM hardware boundary.[1] For the "Container-to-VM Runtimes" category, Firecracker matters as the substrate: Kata Containers can use it as a hypervisor, the firecracker-containerd project adapts it to container workflows, and serverless platforms wrap it in their own orchestration.[1]

The design goal, per the NSDI 2020 paper, was to resolve the perceived trade-off between the speed of containers and the security of VMs — running workloads from multiple customers on shared hardware with minimal overhead while preserving strong isolation.[3]

Key Capabilities

CapabilityDescription
Fast bootUser-space code initiated in as little as 125ms[1]
High densityUnder 5 MiB memory overhead per microVM; thousands per server[1]
Rapid creationUp to 150 microVMs per second per host[1]
Minimal device modelOnly five emulated devices; non-essential functionality excluded[1]
Snapshot/restoreFull microVM snapshots (memory + device state) for fast resume and cloning[6]
JailerCompanion process adding Linux user-space isolation barriers around the VMM[1]
Built-in rate limitersPer-microVM network and storage throttling via API[1]

Integration Surfaces

SurfaceDescriptionAvailability
firecracker binary + REST APIDirect VMM control for platform builders[1]GA
Kata ContainersOCI-compatible runtime that can use Firecracker as its hypervisor[1]GA
firecracker-containerdcontainerd integration from the Firecracker org[1]Open source
Diff snapshotsSparse incremental snapshotsDeveloper preview[6]

Technical Architecture

Firecracker is written in Rust and leverages Linux KVM: each microVM gets its own guest kernel, while the VMM exposes a minimal device model and a metadata service for host-guest communication.[1] Security is layered — KVM hardware virtualization as the primary boundary, a deliberately tiny attack surface (five emulated devices, no BIOS, no PCI emulation), and the jailer wrapping the VMM process in additional Linux isolation (namespaces, cgroups, seccomp).[1]

Snapshot/restore serializes a running microVM's full state — guest memory and emulated hardware — to disk; restores load memory on demand rather than in bulk, enabling rapid provisioning of cloned VMs. Full snapshots are supported; diff snapshots remain in developer preview, and the docs warn that resuming the same snapshot more than once is insecure without uniqueness guarantees (duplicated random state, identifiers, and expected network/vsock packet loss).[6]

Key Technical Details

AspectDetail
DeploymentSelf-hosted on Linux hosts with KVM (bare metal or nested-virt instances)[1]
LanguageRust[2]
Control planeRESTful API per microVM process[1]
IntegrationsKata Containers, firecracker-containerd, Fly.io, Koyeb, and other platforms[1]
Open SourceYes (Apache 2.0)[1]

Release cadence is steady: v1.16.0 shipped June 4, 2026, following v1.15.x and v1.14.x patch releases in March–April 2026, with multiple maintained release branches.[2]

Strengths

  • Proven at extreme scale — Hosts millions of production workloads and trillions of requests per month inside AWS Lambda and Fargate; few isolation technologies have comparable battle-testing[3]
  • Container speed, VM isolation — 125ms boot and under-5 MiB overhead deliver near-container economics with a real hardware virtualization boundary[1]
  • Minimal attack surface — Five emulated devices and a Rust implementation; the jailer adds defense-in-depth around the VMM process[1]
  • De facto standard for AI sandboxes — E2B and peers build agent code-execution platforms on Firecracker precisely for its isolation-per-cost profile[4]
  • Active, AWS-funded maintenance — Regular releases (v1.16.0 in June 2026) with backported patch branches; no startup-runway risk[2]
  • Snapshot-based cloning — Full snapshot/restore with on-demand memory loading enables warm-start fleets[6]

Cautions

  • No GPU passthrough — PCIe/GPU support is deliberately excluded; the maintainers note passthrough would compromise memory oversubscription and expand attack surface, and community work on it stalled[5] — ML and GPU inference workloads need Cloud Hypervisor, crosvm, or QEMU
  • A building block, not a product — Raw Firecracker means managing kernel images, rootfs drives, TAP networking, and jailer setup yourself; HN users describe it as "very hard to set up, let alone run anything securely"[7]
  • Snapshot limitations — Diff snapshots are still developer preview; restoring one snapshot into multiple VMs is documented as insecure without mitigation, and snapshots require matching host hardware/software[6]
  • Feature minimalism cuts both ways — CodeSandbox publicly migrated from Firecracker to QEMU to get memory snapshotting, live VM cloning, memory ballooning, and io_uring I/O that Firecracker's scope excludes[7]
  • Linux/KVM only — Requires KVM access (bare metal or nested virtualization), which constrains where platforms built on it can run[1]
  • Roadmap serves AWS first — Purpose-built for Lambda-style workloads; features outside that profile (PCIe, GPUs) have waited years in discussion threads[5]

Pricing & Licensing

TierPriceIncludes
FirecrackerFreeFull VMM, jailer, snapshot support, REST API (Apache 2.0)[1]

Licensing model: Free and open source under Apache 2.0, permitting unrestricted use and modification; maintained by AWS with community contribution.[1]

Hidden costs: The real cost is platform engineering — networking, image management, orchestration, and security hardening around the VMM — plus bare-metal or nested-virt capable hosts. Teams that underestimate this often end up buying a managed layer (E2B, Fly.io) built on it instead.[7]

Competitive Positioning

Direct Competitors

CompetitorDifferentiation
gVisorGoogle's user-space kernel intercepts syscalls without a VM — lighter integration, but a software boundary rather than Firecracker's hardware virtualization
Kata ContainersOCI-compatible runtime, not a VMM — drop-in for Kubernetes; can run Firecracker underneath as its hypervisor[1]
Cloud HypervisorShares rust-vmm lineage but targets general cloud workloads — supports PCIe/GPU passthrough that Firecracker excludes[5]
QEMUFull-featured hypervisor with memory ballooning, live cloning, and broad device support; far larger attack surface — CodeSandbox chose it over Firecracker for those features[7]

Downstream, E2B is the most visible platform productizing Firecracker for AI agent sandboxes — evidence that the VMM's natural buyers are platform builders, not application teams.[4]

When to Choose Firecracker Over Alternatives

  • Choose Firecracker when: You are building a multi-tenant platform (serverless, CI, AI agent sandboxes) and need maximum density with a hardware isolation boundary, on CPU-only workloads
  • Choose gVisor when: You want stronger-than-container isolation without managing VMs, kernels, or KVM hosts
  • Choose Kata Containers when: You want VM isolation behind a standard OCI/Kubernetes interface instead of building on a raw VMM
  • Choose Cloud Hypervisor when: You need PCIe/GPU passthrough or general-purpose VM features with a similar Rust/rust-vmm security posture
  • Choose QEMU when: You need mature memory ballooning, live migration/cloning, or broad device support and can accept the larger attack surface[7]

Ideal Customer Profile

Best fit:

  • Platform teams building serverless runtimes, CI systems, or AI agent sandboxes that run untrusted code at high density
  • Organizations with bare-metal or nested-virt infrastructure and the engineering capacity to own networking, images, and orchestration
  • Security-sensitive multi-tenant services that want a minimal, auditable, memory-safe VMM[1]
  • Teams standardizing on Kata Containers who want a smaller hypervisor under Kubernetes

Poor fit:

  • GPU/ML workloads — no PCIe or GPU passthrough exists[5]
  • Application teams wanting a "docker run" experience; raw Firecracker requires substantial platform work[7]
  • Use cases needing live migration, multi-resume snapshots, or rich device emulation[6]

Viability Assessment

FactorAssessment
Financial HealthStrong — Maintained by AWS as the substrate of Lambda and Fargate; effectively no abandonment risk[3]
Market PositionCategory-defining — The reference microVM implementation; 34,800+ stars, adopted by Fly.io, Koyeb, Kata, E2B[2]
Innovation PaceSteady but scoped — v1.16.0 in June 2026 with regular patch branches; big-ticket asks like GPU support have stalled[2]
Community/EcosystemStrong — 2,400+ forks and a downstream ecosystem of platforms and runtimes built on it[2]
Long-term OutlookPositive — AWS's own production dependence guarantees maintenance; scope will keep tracking AWS's needs first

Firecracker's viability is about as close to guaranteed as open-source infrastructure gets: its maintainer runs trillions of requests per month through it.[3] The strategic question for adopters is scope, not survival — features AWS doesn't need (GPU passthrough chief among them) may never arrive, and the rise of AI workloads makes that gap more visible each year.[5]

Bottom Line

Firecracker is the microVM archetype and the safest possible bet for CPU-bound, multi-tenant isolation: hardware virtualization at near-container cost, proven by trillions of requests per month at AWS and adopted across the sandbox-platform ecosystem.[3] It is a substrate, though — most teams should consume it through Kata Containers, Fly.io, or E2B rather than operating the raw VMM.

The honest counterweight is its minimalism: no GPUs, developer-preview diff snapshots, single-resume snapshot semantics, and a real platform-engineering tax — enough that CodeSandbox publicly traded it for QEMU.[7]

Recommended for: Platform builders running untrusted CPU workloads at high density — serverless, CI, and AI agent sandboxes — with the engineering capacity to build around a minimal VMM.

Not recommended for: GPU/ML workloads, teams wanting a turnkey container-like experience, or use cases requiring live migration and rich device support.

Outlook: Firecracker will remain the default isolation layer of the AI sandbox era for CPU workloads, while GPU-hungry platforms route around it via Cloud Hypervisor and QEMU. Watch whether the stalled PCIe/GPU effort restarts — it is the single decision that most shapes the category's next phase.[5]

Research by Ry Walker Research • methodology

Sources

Share on XShare on LinkedIn