Firecracker and Cloud Hypervisor are both Rust virtual machine monitors, both built on the shared rust-vmm crates, and Cloud Hypervisor's README says the quiet part out loud: "A large part of the Cloud Hypervisor code is based on either the Firecracker or the crosvm project's implementations." They are close relatives.
They are also built for different products, and the README says that too: Cloud Hypervisor "aims to be a general purpose VMM for Cloud Workloads and not limited to container/serverless or client workloads." Firecracker was built at AWS to run Lambda and Fargate. Every difference below follows from those two sentences.
This post compares them on what actually differs, with versions attached, because both projects have moved fast enough that most of what is written about them is out of date. Versions here are Firecracker v1.16.1 (2 July 2026) and Cloud Hypervisor v53.0 (12 July 2026). Disclosure: Miget runs Cloud Hypervisor, and the section explaining why is also the section where our bias lives.
The one place Firecracker is unambiguously ahead: published numbers
Firecracker's SPECIFICATION.md is unusual in this industry. It states hard numbers and then says: "These specifications are enforced by integration tests."
- Boot time:
<= 125 msfrom theInstanceStartAPI call to the guest's/sbin/init, measured with the serial console disabled and a minimal kernel and rootfs. - Memory overhead:
<= 5 MiBof VMM threads for a microVM with 1 vCPU and 128 MiB of RAM on a Firecracker-tuned guest kernel - with the honest footnote that the overhead is workload-dependent and can exceed that with, for example, multiple vsock connections. - VMM startup: within 8 CPU ms, wall-clock spanning 6 to 60 ms with typical durations around 12 ms.
Some further claims (CPU performance above 95% of bare metal, up to 25 Gbps of network throughput, 1 GiB/s of storage) are still marked "integration test pending" in the same document, which is itself a good sign about how the project treats its own claims.
Cloud Hypervisor's public figure is a marketing-page claim - "boot to userspace in less than 100ms with direct kernel boot" - not a CI-enforced specification. Both are plausible; only one is continuously verified. If you are writing a design doc that depends on boot latency, that difference matters.
Where Cloud Hypervisor is ahead: the workload stays
Cloud Hypervisor's stated design objectives include three things Firecracker either lacks or has only recently begun to add: "CPU, memory, PCI hotplug" and "machine to machine migration."
Live migration is the big one, and it is a real, documented API rather than a roadmap item. The HTTP API exposes /vm.send-migration and /vm.receive-migration, driven from the CLI:
# on the destination host
ch-remote --api-socket=/tmp/api receive-migration receiver_url=tcp:0.0.0.0:5555
# on the source host
ch-remote --api-socket=/tmp/api \
send-migration destination_url=tcp:10.0.0.9:5555,downtime_ms=200,timeout_s=3600,timeout_strategy=cancel
The tuning parameters are the interesting part. downtime_ms sets the pause you will accept during the final switchover, and timeout_strategy decides what happens when that budget cannot be met: cancel aborts and leaves the VM running on the source, ignore proceeds regardless. TLS is supported by pointing both ends at a certificate directory. Recent releases extended this meaningfully: v52.0 added multi-connection TCP migration, and v53.0 extended the protocol "so page faults can be serviced from the source," enabling postcopy migration built on userfaultfd.
Hotplug is the other one: CPUs (x86 only), PCI devices, and memory resizing, with the guest needing ACPI GED support. You boot with a maximum and grow into it:
ch-remote --api-socket=/tmp/api resize --cpus 8
Device support is broader in ways that matter for persistent workloads: virtio-fs for filesystem sharing (Firecracker has none), and VFIO device passthrough, modernized onto iommufd in v52.0. PCI is the native transport rather than an opt-in mode. Cloud Hypervisor also runs on the Microsoft Hypervisor (MSHV) as well as KVM, and supports Windows guests.
Where Firecracker has quietly caught up
This is the part most comparisons get wrong, including some in the projects' own documentation.
The stock description of Firecracker - "minimal MMIO-only device model, six devices, no hotplug" - is stale. Firecracker's own FAQ still says it, and Kata's comparison docs still list "No device hotplug" for it. The changelog disagrees:
- PCI support landed in v1.13.0 (August 2025), opt-in via
--enable-pci, and the getting-started docs now recommend it: PCI transport "yields higher throughput and lower latency for VirtIO devices" than MMIO. - Device hotplug landed in v1.16.0 (June 2026) as a Developer Preview: attach and detach virtio-block, virtio-pmem and virtio-net devices, PCI transport only. The rough edge is honest and documented - there is no guest notification, so the guest must rescan the bus itself (
echo 1 > /sys/bus/pci/rescan). - Memory hotplug via virtio-mem is documented, requiring guest kernel 5.16+ on x86_64 or 5.18+ on aarch64.
- Snapshots went generally available in v1.13.0; incremental (diff) snapshots remain a developer preview.
So the gap is narrowing from both directions. What has not changed is the philosophy: Firecracker still ships the jailer, which "applies a cgroup/namespace isolation barrier and then drops privileges," and still defaults to a deliberately small surface with features opt-in rather than on.
Side by side
| Firecracker v1.16.1 | Cloud Hypervisor v53.0 | |
|---|---|---|
| Built for | Serverless fleets (Lambda, Fargate) | General-purpose cloud workloads |
| Hypervisor backends | KVM | KVM and MSHV |
| PCI | Opt-in (--enable-pci), recommended | Native transport |
| virtio-fs | No | Yes |
| VFIO passthrough | No | Yes (iommufd since v52.0) |
| CPU hotplug | No | Yes (x86) |
| Memory hotplug | virtio-mem | Yes, with resize API |
| Device hotplug | v1.16.0, Developer Preview, PCI only | Yes |
| Snapshot / restore | GA since v1.13.0 (diff still preview) | Yes, plus an offload daemon in v53.0 |
| Live migration | No | Yes: send/receive with downtime budget, TLS, postcopy |
| Confidential computing | - | Intel TDX (experimental), AMD SEV-SNP |
| Guest OS | Linux | 64-bit Linux, Windows 10 / Server 2019 |
| Published perf spec | CI-enforced (125 ms, 5 MiB) | Marketing figure only |
| Governance | AWS-led open source | Linux Foundation (AMD, ARM, Intel, Microsoft, others) |
The operational caveats both projects document
Two that will bite you if you plan around them without reading the docs:
Neither snapshot nor live migration works across versions. Cloud Hypervisor's README states both plainly: "Snapshot/restore is not supported across different versions" and "Live migration is not supported across different versions." That single sentence shapes how you roll out an upgrade - every host in a migration domain has to move together, and a rolling upgrade of the VMM is not a rolling upgrade of your ability to move VMs.
Firecracker's snapshot restore has documented sharp edges. From its own docs: restore latency is high on cgroups v1 (they "strongly recommend" v2), "guest network connectivity is not guaranteed to be preserved after resume," arm64 snapshots cannot be restored across different GIC versions, and "resuming from a snapshot that was taken during early stages of the guest kernel boot might lead to crashes." Snapshot-restore is a genuinely powerful feature and it is not a free lunch.
There is also a homelier lesson in the changelogs: v51.2 and v52.0 of Cloud Hypervisor both fixed a use-after-free in virtio-block async I/O completion. These are young, fast-moving codebases doing an extremely security-sensitive job. Pin your versions, read the release notes, and upgrade deliberately.
How to choose
Choose Firecracker if your unit of work is short-lived and numerous: functions, ephemeral sandboxes, CI jobs, agent code execution. You want the smallest possible surface, the lowest per-VM floor, snapshot-restore to skip boot entirely, and you do not need to move a running VM anywhere - you just make a new one. The CI-enforced spec is a genuine engineering asset when you are capacity planning at fleet scale.
Choose Cloud Hypervisor if your unit of work persists: hosted applications, databases, anything a customer expects to keep running with its memory intact. Hotplug means you can grow a workload without recreating it, virtio-fs and VFIO mean richer storage and device options, and live migration means the machine underneath can be drained, patched or rebalanced without the workload noticing.
That last property is why we run it. On Miget every app, worker and database is a long-lived MicroVM, and "we need to do maintenance on the host your app is on" should be our problem rather than yours. Firecracker would be the better choice if we were building a function runtime; we are not, so it is not.
Frequently asked questions
Is Cloud Hypervisor a fork of Firecracker?
No, but they are closely related. Both are Rust VMMs built on the shared rust-vmm crates, and Cloud Hypervisor's README states that much of its code is based on Firecracker's or crosvm's implementations. They are separate projects with separate governance: Firecracker is AWS-led, Cloud Hypervisor is a Linux Foundation project backed by Alibaba, AMD, Ampere, ARM, ByteDance, Intel, Microsoft, SAP and Tencent Cloud.
Which is faster?
Firecracker is the only one with a continuously tested public specification: <= 125 ms to guest init and <= 5 MiB of VMM memory overhead at 1 vCPU / 128 MiB. Cloud Hypervisor claims sub-100 ms boot to userspace on its site but does not enforce a spec in CI. In practice both are in the same class, and the difference that matters for a real deployment is feature fit, not milliseconds.
Can Firecracker live-migrate a VM?
No. It offers snapshot and restore, which is a different capability: you serialize a VM and resume it later, possibly elsewhere, with documented constraints around kernel versions, GIC versions on arm64, and network connectivity after resume. Cloud Hypervisor implements true live migration with a configurable downtime budget.
Can I use either with Kata Containers?
Both are supported hypervisor options in Kata, along with QEMU, Dragonball and StratoVirt. Note that Kata 4.0 made the built-in Dragonball VMM its default and recommended mode, and that neither Cloud Hypervisor nor Firecracker supports GPUs or confidential computing through Kata - that path requires QEMU.
Which one should I run for my own platform?
Ask what happens to a workload when the host underneath needs maintenance. If the answer is "we recreate it somewhere else," Firecracker's model fits and its density is hard to beat. If the answer is "it has to keep running with its memory intact," you want live migration and hotplug, which means Cloud Hypervisor. Everything else in this comparison is downstream of that question.