Firecracker vs Cloud Hypervisor: Picking a VMM

If you're shopping for a Virtual Machine Monitor to run microVMs, two names dominate the shortlist: Firecracker and Cloud Hypervisor. They look almost like siblings — both are written in Rust, both are minimal by design, both came out of the same rust-vmm community and literally share code. And yet they're tuned for different jobs. Firecracker is laser-focused on serverless density; Cloud Hypervisor aims at general-purpose cloud workloads. Choosing between them is mostly a question of how much you value a tiny attack surface versus how many guest features you need. This is the honest head-to-head.

Same lineage: the rust-vmm story

Before the differences, the thing people miss: these two are family. rust-vmm is a community project that publishes reusable, well-audited Rust crates for building hypervisors — KVM bindings, virtio device implementations, guest memory management, and more. Both Firecracker and Cloud Hypervisor are built on those shared building blocks. Firecracker (started at AWS) actually predates and helped seed rust-vmm; Cloud Hypervisor (started at Intel) leaned into it heavily. So when you compare them, you're not comparing two unrelated codebases — you're comparing two products of the same engineering philosophy that made different scope decisions on top of a common foundation.

That shared DNA is why both are small and memory-safe relative to a full-fat VMM like QEMU. QEMU emulates a sprawling zoo of legacy hardware in C; these Rust VMMs implement a deliberately narrow device set and lean on the Linux KVM hypervisor for the actual virtualization. The split between them is about where they drew the line on "narrow."

The core trade-off: minimalism vs features

Firecracker's feature list is short on purpose — every device you don't emulate is a CVE you don't ship. It deliberately omits things to keep the host-facing surface as small as it can be: a tiny device model (virtio-net, virtio-block, virtio-vsock, a serial console, and a minimal reboot/keyboard controller), no PCI bus, no GPU, no BIOS/legacy device emulation, and historically no device hot-plug. The goal is to run thousands of short-lived, untrusted guests per host with a boundary that's as small and auditable as possible — exactly the AWS Lambda / Fargate use case it was built for.

Cloud Hypervisor made the opposite bet within the same minimalist spirit: still lean, still Rust, still no giant legacy-hardware zoo — but it adds the features general-purpose cloud guests tend to need. That includes a PCI bus, device hot-plug (CPU, memory, and devices added to a running guest), ACPI, VFIO device passthrough (so a guest can be handed a real physical device like a NIC or accelerator), support for larger and more complex guests, and live migration of running VMs between hosts. Each of those is genuinely useful — and each one is also more code in the host-facing path. That's the trade in one sentence: Cloud Hypervisor buys capability with surface area; Firecracker buys a smaller surface by saying no.

Side by side

• Origin — Firecracker: started at AWS, helped seed the rust-vmm community. Cloud Hypervisor: started at Intel, built heavily on rust-vmm crates. Both are Rust and share lineage.
• Design goal — Firecracker: minimal VMM for dense, short-lived, untrusted serverless guests. Cloud Hypervisor: minimal-but-capable VMM for general-purpose cloud workloads.
• Device model — Firecracker: tiny (virtio-net/block/vsock + serial); no PCI bus, no GPU, no legacy device emulation. Cloud Hypervisor: virtio plus a PCI bus and a broader device set.
• Hot-plug — Firecracker: deliberately limited (no general device hot-plug originally; verify current support in their docs). Cloud Hypervisor: CPU, memory, and device hot-plug to running guests.
• Passthrough — Firecracker: no VFIO device passthrough. Cloud Hypervisor: VFIO passthrough of real physical devices.
• Live migration — Firecracker: not a built-in goal (snapshot/restore is its persistence story). Cloud Hypervisor: supports live migration between hosts.
• Guest size/complexity — Firecracker: optimized for many small guests. Cloud Hypervisor: handles larger, more feature-rich guests.
• Best fit — Firecracker: serverless, code interpreters, AI-agent sandboxes, multi-tenant density. Cloud Hypervisor: cloud VMs needing PCI, passthrough, hot-plug, or migration.

Boot speed, density, and snapshots

Both VMMs boot fast by VM standards — that's the whole point of stripping the device model down to virtio and skipping legacy firmware. Qualitatively, both can cold-boot a guest in a small number of milliseconds of VMM work plus the guest kernel's own boot, and both keep per-guest memory overhead low enough to pack many VMs onto a host. Which one boots a given workload faster, and how dense you can go, depends heavily on your kernel, your device config, and your host — so benchmark your own workload rather than trusting a number from a blog (including this one). We're deliberately not inventing head-to-head latency figures here.

Both also support snapshot and restore — capture a booted guest's memory and device state, then restore it later instead of cold-booting. This is the feature that makes the VM rung practically free per request: you boot once, snapshot, and restore on demand. It's also where the two diverge in emphasis. Firecracker's snapshot/restore is the headline persistence and fast-start story (and the foundation platforms build on for sub-second creates), while Cloud Hypervisor pairs snapshot/restore with live migration for moving running guests around. If your scaling story is "spin up thousands of near-identical guests instantly," Firecracker's snapshot model is squarely aimed at you.

What driving the VMM looks like

Both expose an HTTP API over a local Unix socket rather than a sprawling command line, which keeps automation clean. Here's the shape of a Firecracker boot: you PUT a machine config, a boot source, and a root drive to the API socket, then issue an InstanceStart action. The minimalism shows up right in the API — there's no PCI topology, no firmware, no device tree to wrangle, just the handful of knobs that matter.

# Firecracker is driven over a Unix-socket HTTP API. The whole device
# model is so small the entire boot is a few PUTs and one action.
SOCK=/tmp/firecracker.sock

# 1. Machine config: vCPUs + RAM. That's it — no PCI, no firmware.
curl --unix-socket "$SOCK" -X PUT 'http://localhost/machine-config' \
  -H 'Content-Type: application/json' \
  -d '{ "vcpu_count": 2, "mem_size_mib": 1024 }'

# 2. Boot source: a kernel image + kernel cmdline.
curl --unix-socket "$SOCK" -X PUT 'http://localhost/boot-source' \
  -H 'Content-Type: application/json' \
  -d '{ "kernel_image_path": "./vmlinux", "boot_args": "console=ttyS0 reboot=k panic=1 pci=off" }'

# 3. Root filesystem: an ext4 image as a virtio-block device.
curl --unix-socket "$SOCK" -X PUT 'http://localhost/drives/rootfs' \
  -H 'Content-Type: application/json' \
  -d '{ "drive_id": "rootfs", "path_on_host": "./rootfs.ext4", "is_root_device": true, "is_read_only": false }'

# 4. Start the microVM.
curl --unix-socket "$SOCK" -X PUT 'http://localhost/actions' \
  -H 'Content-Type: application/json' \
  -d '{ "action_type": "InstanceStart" }'

Cloud Hypervisor exposes a conceptually similar REST-over-socket API, but the surface is larger because the feature set is — you'll find endpoints for PCI device add/remove, CPU and memory resize, and migration that simply have no analog in Firecracker. That's the trade-off made concrete: more verbs in the API mirror more capability in the guest and more code in the host path. Confirm exact endpoint names and request shapes against the respective project docs, since both APIs evolve.

Who uses each, and how to choose

Firecracker is the isolation primitive behind AWS Lambda and Fargate, and it's what serverless and sandboxing platforms — E2B, Vercel, and PandaStack among them — build on when they need to run untrusted, multi-tenant code at density. Cloud Hypervisor shows up where the workload looks more like a general-purpose cloud VM: projects and platforms that need PCI devices, hardware passthrough, hot-plug, or live migration reach for it, and it's a building block in cloud and Kubernetes-adjacent virtualization stacks. Both are production-proven; they've just been proven in different shapes of problem.

So the decision is refreshingly concrete. Pick Firecracker when you're running many short-lived, untrusted, or AI-generated guests and you want the smallest possible host-facing surface — serverless functions, code interpreters, per-user playgrounds, AI-agent sandboxes, ephemeral CI. Pick Cloud Hypervisor when a guest needs the things Firecracker deliberately omits: a PCI bus, a passed-through GPU or NIC, CPU/memory hot-plug on a long-running VM, or live migration between hosts. If your honest answer is "I need none of those, I just need a lot of tiny isolated boxes fast," the minimalism is a feature, not a limitation — and Firecracker is built for exactly that.

That's the line PandaStack sits on. It's an Apache-2.0 open-source platform built on Firecracker: every sandbox, database, and app is its own microVM created via snapshot-restore at a p50 of about 179ms (roughly 203ms p99; the restore step itself is around 49ms), with only the very first cold boot of a template taking around 3s. We chose Firecracker precisely because the workload is dense, untrusted, model-generated code — the case where a microscopic device model is the whole point. If your workload looks like ours, the minimal VMM wins; if it looks like a general-purpose cloud VM, Cloud Hypervisor's extra surface is buying you something real.