# 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](/docs/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 | | QEMU | Firecracker | | ---------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------- | | What it is | A machine emulator and virtualizer | A virtual machine monitor for microVMs on KVM | | Language | C | Rust | | Accelerators | KVM, Xen, Hypervisor.Framework, or TCG software emulation | KVM only | | Guest architectures | Any QEMU supports, including a CPU unlike the host's | The host's own; x86_64 or aarch64 | | Guests | Almost any operating system | Linux and OSv | | Device model | Broad: PCI, ACPI, legacy devices, GPUs | A few virtio devices, a serial console, a minimal keyboard control | | GPUs, confidential VMs | Yes: Kata calls it best supported for NVIDIA GPUs, TDX, SEV-SNP | No GPU, TDX or SEV-SNP, per Kata's hypervisor table | | Published start time | No single figure; depends on machine type and firmware | Up to 125 ms from InstanceStart to guest init, in its specification | | Published memory | No single figure | Up to 5 MiB for the VMM threads, in its specification | | Confinement of the VMM | Recommended: unprivileged user, `--sandbox` seccomp, SELinux etc. | Built-in jailer and per-thread seccomp filters | | Control | Command line and a monitor console | A RESTful API per process | ## 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](/docs/sandbox-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](/docs/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. ```ts check import { Sandbox } from "withruntime"; const sbx = await Sandbox.create({ timeoutSeconds: 600 }); await sbx.spawn("python3 -m http.server 3000"); // a process to keep await sbx.pause(); // memory, files and processes are kept const run = await sbx.exec("pgrep -f http.server"); // wakes the sandbox console.log(run.stdout); await sbx.stop(); ``` ```python check from withruntime import Sandbox sbx = Sandbox.create(timeout_seconds=600) sbx.spawn("python3 -m http.server 3000") # a process to keep sbx.pause() # memory, files and processes are kept run = sbx.exec("pgrep -f http.server") # wakes the sandbox print(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: ```bash no-run npx withruntime sandbox run --trial -- uname -m ``` More: [Cloud Hypervisor vs Firecracker](/compare/cloud-hypervisor-vs-firecracker), [Kata Containers vs Firecracker](/compare/kata-containers-vs-firecracker), [what is Firecracker?](/glossary/firecracker), [pause and resume a sandbox](/how-to/pause-and-resume-a-sandbox). ## Sources Checked 25 September 2026. - [QEMU](https://www.qemu.org/), [about QEMU](https://www.qemu.org/docs/master/about/index.html), [security](https://www.qemu.org/docs/master/system/security.html), [microvm machine type](https://www.qemu.org/docs/master/system/i386/microvm.html) - [Firecracker FAQ](https://github.com/firecracker-microvm/firecracker/blob/main/FAQ.md), [README](https://github.com/firecracker-microvm/firecracker), [specification](https://github.com/firecracker-microvm/firecracker/blob/main/SPECIFICATION.md), [design](https://github.com/firecracker-microvm/firecracker/blob/main/docs/design.md) - [Kata Containers hypervisors](https://github.com/kata-containers/kata-containers/blob/main/docs/hypervisors.md) - [Unikraft performance](https://unikraft.org/docs/features/performance) Facts on this page were checked on 25 September 2026.