Cloud Hypervisor vs Firecracker: features, boot time and fit

Both are Rust VMMs on KVM; Firecracker keeps a minimal device set for serverless, Cloud Hypervisor adds Windows, VFIO and live migration.

Runtime runs every sandbox as a Firecracker microVM and starts one in about a third of a second. A new sandbox ran its first Python command 351 ms after the create request at the median, over the public internet, on 24 September 2026 (speed). You get Firecracker's small device model without building the host, network or image layer around it.

Two monitors from the same family

The two projects share code. Cloud Hypervisor's README says it imports the Rust VMM crates and 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.

Where they part is 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 notes that neither snapshots nor migration is guaranteed across versions.
• Release 53.0, posted 12 July 2026, added an offloaded snapshot daemon, postcopy live migration over userfaultfd and nested Hyper-V for Windows guests.

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).

Why Runtime uses Firecracker

An agent sandbox is a Linux machine that runs code nobody reviewed. It needs the smallest boundary, not the widest hardware menu:

• A kernel per sandbox. Ubuntu 24.04 on its own kernel, with Python 3.12, Node.js 24, Bun, git and gcc, and sudo working (environment).
• Controls outside the guest. Network rules, CPU, memory and cost are enforced on the host, so root in the sandbox cannot change them (security).
• Whole-machine state. Pause keeps files, memory and running processes for 1 to 365 days, and a fork makes 1 to 10 running copies of a sandbox.

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()

Runtime sandboxes run on CPUs, without GPUs.

Try it on the free trial, 50 sandbox hours with no card:

Terminalnpx withruntime sandbox run --trial -- uname -r

More: what is Firecracker?, what is a microVM?, QEMU vs Firecracker, Firecracker vs gVisor.

Sources

Checked 25 September 2026.

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

Facts on this page were checked on 25 September 2026.