Every Runtime sandbox is a microVM. Each one is a Firecracker microVM with its own Linux kernel. Runtime runs these microVMs on dedicated servers that it operates.
How is a microVM different from a normal VM?
Docker describes a general-purpose virtual machine as "an entire operating system with its own kernel, hardware drivers, programs, and applications".
A microVM keeps the hardware boundary and removes most of the hardware. Firecracker's site lists "only 5 emulated devices": a network card, a block device, a vsock socket, a serial console, and a minimal keyboard controller. The keyboard controller is used only to stop the machine. Firecracker's README says it "excludes unnecessary devices and guest-facing functionality to reduce the memory footprint and attack surface area of each microVM."
How is it different from a container?
A container is a process on the host. Namespaces and cgroups isolate it. It shares the host's kernel. A microVM runs its own guest kernel behind the processor's virtualization extensions (KVM on Linux). A bug in that kernel stays inside the guest. See microVM vs container.
Facts
| Property | MicroVM (Firecracker's published figures) |
|---|---|
| Kernel | Its own guest Linux kernel |
| Boundary | Hardware virtualization through KVM |
| Emulated devices | 5, in Firecracker's own count |
| Start time | Up to 125 ms from the start call to the guest's init process |
| Memory overhead | Up to 5 MiB for the VMM, on a 1 vCPU, 128 MiB guest |
| Examples | Firecracker; Kata Containers can run containers in Firecracker |
The start and memory figures come from Firecracker's own specification. They were measured on AWS metal instances with a minimal guest. They cover the monitor only. They do not cover a full sandbox with a toolchain and network.
Who uses microVMs?
AWS built Firecracker for Lambda and Fargate. Among agent sandbox providers, E2B, Vercel Sandbox, the CodeSandbox SDK, Fly.io and Runtime run Firecracker microVMs. This is based on Runtime's provider comparisons, checked 25 October 2026 (Runtime vs E2B, Runtime vs Vercel Sandbox).
How Runtime uses it
Each sandbox gets its own microVM, kernel and disk. Runtime enforces network rules, CPU, memory and cost on the host, outside the guest. Root inside the sandbox cannot change them (security). A paused sandbox keeps its files, memory and running processes. A fork copies a running sandbox, including its memory.
Related: Firecracker, gVisor, Firecracker vs gVisor.
Sources
Checked 25 October 2026.
Facts on this page were checked on 25 October 2026.