QEMU vs Firecracker: what is the difference?

QEMU emulates or virtualizes almost any machine; Firecracker is a small KVM monitor built only for minimal microVMs.

Runtime runs each sandbox in Firecracker, the monitor AWS built as a smaller alternative to QEMU, 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).

Firecracker's own answer

Firecracker's FAQ answers this exact question. It calls Firecracker "an alternative to QEMU that is purpose-built for running serverless functions and containers safely and efficiently, and nothing more." It is written in Rust, exposes a handful of devices (the FAQ lists virtio-net, virtio-balloon, virtio-block, virtio-vsock, a serial console and a minimal keyboard controller), and with a streamlined kernel load claims "a < 125 ms startup time and a < 5 MiB memory footprint."

QEMU describes itself as "a generic and open source machine emulator and virtualizer." It works in three ways:

• Full-system emulation: "Run operating systems for any machine, on any supported architecture." The CPU can be emulated in software, which QEMU's security guide calls TCG-based emulation.
• User-mode emulation: run a Linux or BSD program built for one CPU on another.
• Virtualization: "Run KVM and Xen virtual machines with near native performance," where the guest's code runs directly on the host processor.

So QEMU is a toolbox for any machine, and Firecracker is one tool for one job.

Side by side

Is QEMU secure enough for untrusted code?

With a hardware accelerator, yes, and QEMU treats bugs there as security issues. Its security guide covers the "virtualization use case", which relies "on hardware virtualization extensions to execute guest code safely," for listed machine types such as pc, q35 and microvm on x86 and virt on Arm, and it requires "a virtualization accelerator like KVM or HVF."

Without one, no. The same guide says bugs in pure emulation "are not considered security bugs at this time. Users with non-virtualization use cases must not rely on QEMU to provide guest isolation or any security guarantees." That matters on nested or cloud VMs without KVM: there, QEMU emulation is no security boundary at all.

QEMU also leaves hardening to the operator: it asks that QEMU processes "must run as unprivileged users", recommends SELinux, AppArmor or namespaces around them, and offers seccomp through --sandbox. Firecracker ships that layer itself: a jailer sets up cgroups and a chroot, drops privileges and then starts the monitor with per-thread seccomp filters.

What about QEMU's microvm machine type?

QEMU borrowed the idea back. Its documentation says "microvm is a machine type inspired by Firecracker and constructed after its machine model": no PCI and no ACPI, up to eight virtio-mmio devices, "designed for short-lived guests" and optimized for boot time and footprint. It gives up PCI-only devices, hotplug of any kind and live migration across QEMU versions. It keeps the rest of QEMU's C code base behind it.

How much the monitor itself adds was measured by the Unikraft project, which booted the same tiny unikernel on several monitors. In its published results, total boot was dominated by the monitor: about 3 ms on Firecracker, about 10 ms on QEMU microvm and about 40 ms on standard QEMU. Those are Unikraft's figures for a minimal guest, not a Linux sandbox.

When each fits

• Pick QEMU for anything outside one Linux architecture: Windows or other guests, emulating ARM or RISC-V on x86, GPUs and other passthrough devices, confidential computing with TDX or SEV-SNP, desktop virtualization, and long lived VMs with live migration.
• Pick Firecracker for many small, short-lived Linux guests whose code you do not trust: functions, CI jobs, per-user environments and agent sandboxes.
• Pick QEMU microvm if you are already built on QEMU and want a faster, smaller machine without adopting a second monitor.

Why Runtime uses Firecracker

An agent sandbox needs a real Linux machine that boots fast and exposes as little as possible to code a model wrote. Runtime runs one Firecracker microVM per sandbox on dedicated servers it operates:

• A real kernel, a normal distribution. Ubuntu 24.04 with Python 3.12, Node.js 24, Bun, git and gcc; apt-get, pip and npm work as usual (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).
• Pause and resume a whole machine. A paused sandbox keeps its memory and running processes for 1 to 365 days and wakes when a request needs it.

TypeScriptimport { Sandbox } from "withruntime";const sbx = await Sandbox.create({ timeoutSeconds: 600 });await sbx.spawn("python3 -m http.server 3000"); // a process to keepawait sbx.pause(); // memory, files and processes are keptconst run = await sbx.exec("pgrep -f http.server"); // wakes the sandboxconsole.log(run.stdout);await sbx.stop();

Pythonfrom withruntime import Sandboxsbx = Sandbox.create(timeout_seconds=600)sbx.spawn("python3 -m http.server 3000")  # a process to keepsbx.pause()  # memory, files and processes are keptrun = sbx.exec("pgrep -f http.server")  # wakes the sandboxprint(run.stdout)sbx.stop()

Runtime sandboxes are x86_64 Linux machines on CPUs; a GPU or another guest operating system calls for QEMU.

New accounts get 50 free sandbox hours, no card:

Terminalnpx withruntime sandbox run --trial -- uname -m

More: Cloud Hypervisor vs Firecracker, Kata Containers vs Firecracker, what is Firecracker?, pause and resume a sandbox.

Sources

Checked 25 September 2026.

• QEMU, about QEMU, security, microvm machine type
• Firecracker FAQ, README, specification, design
• Kata Containers hypervisors
• Unikraft performance

Facts on this page were checked on 25 September 2026.