Firecracker vs Cloud Hypervisor
Updated October 24, 2026 .md
Short answer: Both are open-source Rust virtual machine monitors built on KVM and the rust-vmm crates. Firecracker, from AWS, is deliberately minimal and built for dense, short-lived serverless microVMs. Cloud Hypervisor, a Linux Foundation project, is a general-purpose cloud VMM with PCI devices, VFIO and GPU passthrough, virtio-fs, CPU hotplug, live migration and Windows guests.
Disclosure: Sandboxer runs every sandbox as a Cloud Hypervisor microVM. Everything below comes from the two projects' own repositories and websites, read on the date above. Features on main can be ahead of the latest release.
Side by side#
| Firecracker | Cloud Hypervisor | |
|---|---|---|
| Origin and governance | Built at AWS "to accelerate the speed and efficiency of services like AWS Lambda and AWS Fargate"; AWS team holds maintainer rights | Linux Foundation project supported by Alibaba, AMD, Ampere, ARM, ByteDance, Intel, Microsoft, Tencent Cloud and others |
| License | Apache 2.0 (crosvm-derived parts BSD-3-Clause) | Apache 2.0 and BSD-3-Clause |
| Stated goal | "Secure, multi-tenant, minimal-overhead execution of container and function workloads"; "If it's not clearly required for our mission, we won't build it" | "A general purpose VMM for Cloud Workloads and not limited to container/serverless or client workloads" |
| Hypervisor | KVM | KVM, and Microsoft Hypervisor (MSHV) |
| Device transport | virtio-mmio by default; PCI optional with --enable-pci |
virtio-pci only |
| Devices | A small set: virtio-net, -block, -vsock, -balloon, serial, a minimal keyboard controller, plus entropy, pmem and memory hotplug | virtio-blk, -net, -vsock, -pmem, -rng, -console, -iommu, vhost-user-blk/-net/-fs, VFIO |
| GPU / VFIO passthrough | Not in a release (open tracking issue) | Yes, including NVIDIA GPUs |
| virtio-fs (share a host folder) | Not documented | Yes (vhost-user-fs) |
| CPU hotplug | Not documented; vCPUs set at configuration | Yes (x86) |
| Memory hotplug | Yes (virtio-mem) | Yes (ACPI or virtio-mem) |
| Snapshot and restore | Memory and device state; disks managed by you; restore on identical hardware and software | Memory and VM state; not across different versions |
| Live migration | Not documented | Yes, over TCP/TLS between hosts or a local socket |
| Guest OS | Linux and OSv | 64-bit Linux and Windows (UEFI images) |
| Host CPU | x86-64 (Intel, AMD) and aarch64 | x86-64 and aarch64; riscv64 experimental |
| Process sandboxing | seccomp by default; the jailer (cgroups, chroot, dropped privileges) is required in production |
seccomp by default; opt-in Landlock |
| API | REST over a Unix socket, OpenAPI spec | REST over a Unix socket (OpenAPI), CLI, optional D-Bus |
Numbers each project publishes#
These are each project's own figures, with the conditions they state. They aren't measured the same way, so don't compare them directly.
| Firecracker | Cloud Hypervisor | |
|---|---|---|
| Boot | <= 125 ms from the InstanceStart call to the guest's /sbin/init, with the serial console off and a minimal kernel and root filesystem |
"Boot to userspace in less than 100ms with direct kernel boot" (website; no test conditions given) |
| VMM memory overhead | <= 5 MiB for a 1 vCPU, 128 MiB microVM with a Firecracker-tuned guest kernel |
No number; "minimal memory overhead" |
| Creation rate | 5 microVMs per host core per second (180/s on 36 cores) with a minimal kernel, 1 vCPU and 128 MiB | No number |
Which one fits#
Firecracker fits when you run very many small, short-lived Linux microVMs, such as functions or per-request sandboxes, and want the smallest possible device model and attack surface. Its creation rate and memory overhead are documented for exactly that case.
Cloud Hypervisor fits when the VMs are longer-lived machines that need more of a real computer: PCI devices, GPU passthrough, shared host folders, adding CPUs or memory while running, moving between hosts, or Windows guests.
For agent sandboxes, both give each sandbox its own kernel behind hardware virtualization. That's a stronger boundary than containers sharing the host kernel; see Container vs microVM. The difference is how much machine you get inside.
What Sandboxer does with it#
Each Sandboxer sandbox is a Cloud Hypervisor microVM running Ubuntu 24.04, with root via sudo, systemd, Docker and /dev/kvm. Stopping a sandbox saves its memory and device state, and resuming brings running processes back; see Pause and resume with memory. Sandboxer doesn't offer GPUs. You don't operate the VMM yourself:
sbx new # a Cloud Hypervisor microVM, ready in seconds
sbx ssh # a shell in itWhere the projects' docs disagree with themselves#
- Firecracker's device count is "6" in the repo FAQ and "5" on its website, and the README now lists more (entropy, pmem, memory hotplug).
- Firecracker's kernel-policy doc says in one section that it doesn't support PCI, and in another (and in the changelog) that PCI works with
--enable-pci. - Cloud Hypervisor's README says live migration isn't supported across versions, while v54.0 release notes accept migrations from the two previous releases.
FAQ#
Is Cloud Hypervisor based on Firecracker?#
Partly. Cloud Hypervisor's README says "a large part of the Cloud Hypervisor code is based on either the Firecracker or the crosvm project's implementations." Firecracker itself started from crosvm. Both now build on the shared rust-vmm crates.
Which is faster to boot?#
Firecracker publishes <= 125 ms to /sbin/init under stated conditions; Cloud Hypervisor's website says under 100 ms to userspace with direct kernel boot, without stated conditions. They aren't measured the same way, so neither number proves one is faster.
Does Firecracker support GPUs?#
Not in a release as of the date above; VFIO passthrough is an open feature request. Cloud Hypervisor documents VFIO passthrough, including NVIDIA GPUs.
Can Firecracker or Cloud Hypervisor run Windows?#
Firecracker supports Linux and OSv guests. Cloud Hypervisor supports 64-bit Linux and UEFI Windows images.
Do both support snapshots?#
Yes. Both save guest memory and device state, so a restored VM continues where it was. Firecracker requires identical hardware and software to restore; Cloud Hypervisor doesn't restore across different versions.
Sources#
- Firecracker: README, FAQ, charter, design, specification, snapshots, VFIO issue #5679, website
- Cloud Hypervisor: README, device model, VFIO, hotplug, snapshot/restore, live migration, Windows, website
More guides
For running AI-written code we rank Sandboxer, Freestyle and E2B first: each gives code its own VM with an API or SDK and can pause with memory. Pick Daytona for Windows or GPUs, Modal or Northflank for GPUs at scale, E2B or Northflank to run in your own cloud, and Vercel Sandbox if your app lives on Vercel.
For coding agents we rank Sandboxer first: a full Ubuntu VM with Claude Code and Codex preinstalled, Docker, and stop-and-resume that keeps the agent's session in memory. Freestyle and Amp Orbs also keep memory across pauses. Pick E2B for prebuilt agent templates on open source, Docker Sandboxes for free local runs, and Codespaces if you live in GitHub.
The best Daytona alternatives depend on why you're switching. For a full Linux microVM on every sandbox with memory-saving stop and Docker, we rank Sandboxer first. E2B suits open source and self-hosting, Modal massive short-job fleets, Northflank bring-your-own-cloud with GPUs, and Vercel Sandbox apps on Vercel.
If you're leaving E2B for longer sessions or a fuller machine, we rank Sandboxer first, then Freestyle: both give each sandbox a full Linux VM that keeps memory across pauses, with Docker and no short session cap. Pick Daytona for Windows or GPUs, Northflank for bring-your-own-cloud, and stay on E2B if you need open source.