# What is a microVM?

A microVM is a small virtual machine with its own kernel and only a few emulated devices, built to start in a fraction of a second.

**Every Runtime sandbox is a microVM.** Each one is a Firecracker microVM with
its own Linux kernel, on dedicated servers Runtime operates. A new sandbox ran
its first Python command 351 ms after the create request at the median,
measured on 24 September 2026 ([speed](/docs/speed)).

## How is a microVM different from a normal VM?

A general-purpose virtual machine is, in Docker's words, "an entire operating
system with its own kernel, hardware drivers, programs, and applications".

A microVM keeps the hardware boundary and drops 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
used only to stop the machine. Its 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, fenced off with namespaces and cgroups.
It shares the host's kernel. A microVM runs its own guest kernel behind the
processor's virtualization extensions (KVM on Linux), so a bug in that kernel
is contained to the guest. See
[microVM vs container](/compare/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 are Firecracker's own specification, measured on
AWS metal instances with a minimal guest. They cover the monitor, not 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, according to Runtime's provider comparisons checked
23 September 2026 ([Runtime vs E2B](/docs/e2b-alternative),
[Runtime vs Vercel Sandbox](/docs/vercel-sandbox-alternative)).

## How Runtime uses it

Each sandbox gets its own microVM, kernel and disk. Network rules, CPU, memory
and cost are enforced on the host, outside the guest, so root inside the
sandbox cannot change them ([security](/docs/security)). A paused sandbox
keeps its files, memory and running processes, and a fork copies a running
sandbox, memory included.

Related: [Firecracker](/glossary/firecracker), [gVisor](/glossary/gvisor),
[Firecracker vs gVisor](/compare/firecracker-vs-gvisor).

## Sources

Checked 25 September 2026.

- [Firecracker](https://firecracker-microvm.github.io/)
- [Firecracker README](https://github.com/firecracker-microvm/firecracker)
- [Firecracker specification](https://github.com/firecracker-microvm/firecracker/blob/main/SPECIFICATION.md)
- [Docker: what is a container?](https://docs.docker.com/get-started/docker-concepts/the-basics/what-is-a-container/)

Facts on this page were checked on 25 September 2026.