Cloud Hypervisor vs Firecracker features, boot time and fit

Which should you use, Cloud Hypervisor or Firecracker?

It depends on how long your guests live and what hardware they must reach. If you want Firecracker for agent sandboxes without building the host, Runtime runs every sandbox on it. If you build your own, pick Firecracker for many short-lived, untrusted Linux guests on one host. Pick Cloud Hypervisor for longer-lived VMs that need Windows, VFIO passthrough, resizing while running or moving between hosts.

Two monitors from the same family

The two projects share code. Cloud Hypervisor's README says it imports the Rust VMM crates. It also says that "a large part of the Cloud Hypervisor code is based on either the Firecracker or the crosvm project's implementations." Firecracker's FAQ says it "started from Chromium OS's Virtual Machine Monitor, crosvm". Both are virtual machine monitors: a user-space process that asks the host's KVM for a virtual machine and gives the guest a small set of virtual devices.

The two differ in scope. Firecracker calls itself "purpose-built for running serverless functions and containers safely and efficiently, and nothing more." Cloud Hypervisor states the opposite aim: "a general purpose VMM for Cloud Workloads and not limited to container/serverless or client workloads."

What Firecracker gives a guest

Firecracker's site counts "only 5 emulated devices": virtio-net, virtio-block, virtio-vsock, a serial console and a minimal keyboard controller used only to stop the microVM. Its FAQ lists six, adding virtio-balloon. The API also adds pmem and entropy devices, memory hotplug and, as a developer preview, hotplug of virtio PCI devices. Guests are Linux or OSv, on the same CPU architecture as the host.

The monitor runs under a jailer that sets up cgroups and a chroot, drops privileges and then starts Firecracker as an unprivileged process, with per-thread seccomp filters. The design document assumes "all vCPU threads are considered to be running malicious code as soon as they have been started."

What Cloud Hypervisor adds

Cloud Hypervisor keeps "minimal emulation" and "small attack surface" among its objectives, then goes further on features:

• It runs on KVM or the Microsoft Hypervisor (MSHV).
• It boots 64-bit Linux, Windows 10 and Windows Server 2019.
• It hotplugs CPUs, memory, VFIO passthrough devices and virtio-net, block, pmem, fs and vsock devices.
• It supports VFIO device passthrough, snapshot and restore, and live migration between hosts. The README says snapshot and restore is not supported across versions.
• Release 54.0, posted 14 October 2026, accepts live migrations from the two previous releases, live migrates VMs with migratable VFIO devices and can cancel a migration in progress. Release 53.0, from 12 July 2026, added an offloaded snapshot daemon and postcopy live migration over userfaultfd.

Side by side

Is Cloud Hypervisor faster than Firecracker?

Neither project publishes a head-to-head measurement. Firecracker's figure comes from its specification, measured on AWS M5D.metal and M6G.metal hosts, from the API call to the guest's /sbin/init. Cloud Hypervisor's figure is a claim on its home page, to userspace with direct kernel boot, with no stated hardware or guest. The two numbers were measured differently, so they cannot be ranked against each other. For a sandbox product, the monitor is a small part of start time anyway. The guest image, the disk and the control plane decide most of what a caller waits for.

Which has the smaller attack surface?

Firecracker, by design. Every device a monitor offers is code a hostile guest can talk to, and Firecracker offers the fewest. Cloud Hypervisor chose wider hardware support, including passthrough of physical devices and Windows guests, while still avoiding legacy devices and keeping the code in Rust. The right trade depends on what the guest must reach.

When each fits

• Pick Firecracker for many short-lived Linux guests from one host: functions, agent sandboxes, per-user environments, CI jobs. It suits the case where every guest is untrusted and nothing needs a physical device.
• Pick Cloud Hypervisor for longer-lived cloud VMs: Windows guests, VFIO passthrough of network cards or accelerators, CPU and memory resizing on a running machine, and moving a VM between hosts without stopping it.
• Both run under Kata Containers if the unit you schedule is a Kubernetes pod (Kata Containers vs Firecracker).

TypeScriptimport { Sandbox } from "withruntime";await using base = await Sandbox.create();await base.exec("echo ready > /workspace/state.txt");const [a, b] = await base.fork({ count: 2 }); // running copies, memory includedconsole.log((await a!.exec("cat /workspace/state.txt")).stdout);await Promise.all([a!.stop(), b!.stop()]);

Pythonfrom withruntime import Sandboxwith Sandbox.create() as base:    base.exec("echo ready > /workspace/state.txt")    forks = base.fork(count=2)  # running copies, memory included    print(forks[0].exec("cat /workspace/state.txt").stdout)    for fork in forks:        fork.stop()

Terminalnpx withruntime sandboxes run -- uname -r

Sources

Checked 26 October 2026.

• Cloud Hypervisor, README
• Firecracker, README, FAQ, specification, design, snapshots
• Kata Containers hypervisors

Facts on this page were checked on 26 October 2026.