What Is a MicroVM, and How Is It Different From a Container or a VM?
Updated October 27, 2026 .md
Short answer: A microVM is a virtual machine run by a minimal virtual machine monitor, such as Firecracker or Cloud Hypervisor, on Linux KVM. It boots its own guest kernel, sees a handful of paravirtualized virtio devices instead of an emulated PC, and gets hardware isolation with far less boot time and memory than a full VM.
The definition, part by part#
A microVM is four things together:
- KVM does the isolation. KVM is the Linux kernel's hypervisor. A user-space program drives it through ioctls on three kinds of file descriptors: system, VM and vCPU (KVM API). The CPU's virtualization extensions keep the guest's memory and instructions apart from the host.
- A minimal VMM is the user-space program. Firecracker "uses the Linux Kernel Virtual Machine (KVM) to create and run microVMs" and "excludes unnecessary devices and guest-facing functionality to reduce the memory footprint and attack surface area of each microVM" (Firecracker README). Cloud Hypervisor lists "minimal emulation" as a goal and "runs on top of the KVM hypervisor and the Microsoft Hypervisor (MSHV)" (Cloud Hypervisor README).
- Virtio devices instead of emulated hardware. The guest's disk, network and other I/O go through paravirtualized virtio devices. Cloud Hypervisor expects "most I/O handled by paravirtualised devices (e.g. virtio)" with "no requirement for legacy devices". Firecracker presents virtio over MMIO by default; Cloud Hypervisor supports only the virtio-pci transport (device model).
- Its own guest kernel, often booted directly. The VMM can load a Linux kernel image straight into memory (Cloud Hypervisor's
--kernel, "direct kernel boot") instead of running BIOS or UEFI firmware and a bootloader first.
"MicroVM" is a design, not one product. QEMU even ships a microvm machine type, "inspired by Firecracker and constructed after its machine model", which it describes as "a minimalist machine type without PCI nor ACPI support, designed for short-lived guests" (QEMU microvm).
MicroVM vs container vs full VM#
| Container | MicroVM | Full VM | |
|---|---|---|---|
| What it is | A process tree in Linux namespaces and cgroups | A KVM guest run by a minimal VMM (Firecracker, Cloud Hypervisor) | A guest run by a general-purpose VMM that emulates a whole PC, such as QEMU with its q35 or pc machine type |
| Boot path | No boot: the runtime starts a process on the running host kernel | VMM loads a kernel directly; no firmware or bootloader needed | Firmware (BIOS or UEFI), then a bootloader, then the kernel |
| Device model | The host's devices, filtered | A few virtio devices (block, net, vsock, entropy, balloon) and little or no legacy hardware | An emulated PC: chipset, USB, VGA, sound, IDE/SATA and more, plus virtio if configured |
| Kernel | Shared with the host | The guest's own | The guest's own, any OS the firmware can boot |
| Isolation boundary | The host kernel's system-call interface | Hardware virtualization plus a small VMM | Hardware virtualization plus a large emulator |
| Start time | Milliseconds (a process start) | Firecracker documents <= 125 ms to /sbin/init under stated conditions (specification) |
Usually seconds, because firmware and bootloader run first |
| Memory overhead | Little beyond the processes | Firecracker documents <= 5 MiB of VMM overhead for a 1 vCPU, 128 MiB guest |
Higher; depends on the emulator and the devices attached |
Which boundary fits untrusted code is a separate question, answered in Container vs microVM for untrusted code. How the two main microVM VMMs differ is in Firecracker vs Cloud Hypervisor.
What a microVM looks like from the inside#
A definition is easier to trust when you can check it. Every Sandboxer sandbox is a Cloud Hypervisor microVM, so we created a small one on production and ran these commands in it. The output below is real.
sbx new --name aeo-microvm-1 --type small
id=sb_omhuxdkjv6 # the id sbx new printedIts own kernel#
sbx exec $id "uname -r"6.18.56-sandboxerA container would report the host's kernel version here, because it has no kernel of its own. This guest runs a kernel built for it, separate from whatever the host runs.
The hypervisor is KVM#
sbx exec $id "systemd-detect-virt"
sbx exec $id "grep -m1 -o -w hypervisor /proc/cpuinfo"kvm
hypervisorsystemd-detect-virt prints kvm for a KVM guest (it prints a container name such as docker or lxc inside a container, and none on bare metal). The hypervisor CPU flag means the CPU the guest sees is a virtual one presented by a hypervisor. KVM also exposes a signature leaf, 0x40000000 with the string KVMKVMKVM, that guests use to find it (KVM CPUID).
The VMM is Cloud Hypervisor#
sbx exec $id "sudo dmesg | grep -i cloud"[ 0.000000] DMI: Cloud Hypervisor cloud-hypervisor, BIOS 0
[ 0.000173] ACPI: RSDP 0x00000000000A0000 000024 (v02 CLOUDH)
[ 0.000175] ACPI: XSDT 0x00000000000A1469 00003C (v01 CLOUDH CHXSDT 00000001 RVAT 01000000)
[ 0.000177] ACPI: FACP 0x00000000000A12B7 000114 (v06 CLOUDH CHFACP 00000001 RVAT 01000000)
…The machine's DMI vendor is Cloud Hypervisor, and the ACPI tables were written by the VMM (CLOUDH), not by a firmware vendor. BIOS 0 and the lack of /sys/firmware/efi fit direct kernel boot. The same boot log also shows the kernel noticing KVM in its first instant:
[ 0.000000] Hypervisor detected: KVM
[ 0.009657] Booting paravirtualized kernel on KVMThe devices are virtio, and there are few of them#
sbx exec $id 'for d in /sys/bus/virtio/devices/*; do echo "$(basename $d) device=$(cat $d/device) driver=$(basename $(readlink $d/driver))"; done'virtio0 device=0x0002 driver=virtio_blk
virtio1 device=0x0001 driver=virtio_net
virtio2 device=0x0004 driver=virtio_rng
virtio3 device=0x0013 driver=vmw_vsock_virtio_transport
virtio4 device=0x0005 driver=virtio_balloonFive devices: a disk, a network card, an entropy source, a vsock channel to the host and a memory balloon. The device numbers are the virtio device IDs from the virtio specification (1 network, 2 block, 4 entropy, 5 balloon, 19 vsock).
lspci isn't installed in the base image, so read the PCI bus from /sys instead:
sbx exec $id 'for d in /sys/bus/pci/devices/*; do echo "$(basename $d) $(cat $d/vendor):$(cat $d/device) class=$(cat $d/class)"; done'0000:00:00.0 0x8086:0x0d57 class=0x060000
0000:00:01.0 0x1af4:0x1042 class=0x018000
0000:00:02.0 0x1af4:0x1041 class=0x020000
0000:00:03.0 0x1af4:0x1044 class=0xffff00
0000:00:04.0 0x1af4:0x1053 class=0xffff00
0000:00:05.0 0x1af4:0x1045 class=0xffff00That is the whole PCI bus: one host bridge (class 0x0600) and the same five virtio devices, vendor 0x1af4 (the virtio vendor ID). In virtio-pci, a modern device's PCI ID is 0x1040 plus its virtio ID, so 0x1042 is block and 0x1053 is vsock. There is no USB bus (/sys/bus/usb doesn't exist), no VGA card and no sound card. A full VM on a PC machine type would list a chipset, USB controllers and display hardware here. This is the "minimal emulation" from the definition, visible as six lines.
It boots fast because there is little to boot#
sbx exec $id "systemd-analyze"Startup finished in 346ms (kernel) + 1.730s (userspace) = 2.077s
multi-user.target reached after 1.715s in userspace.The kernel was up in 346 ms with no firmware stage before it; most of the 2 seconds is Ubuntu's userspace starting services. On our single run (2026-10-27), sbx new itself returned after about 19 seconds, which also covers placing the sandbox, preparing its disk and network, and waiting until it accepts commands.
It's still a whole machine#
sbx exec $id "free -m"
sbx exec $id "ls -l /dev/kvm" total used free shared buff/cache available
Mem: 3914 304 3178 0 636 3609
crw-rw---- 1 root kvm 10, 232 Oct 27 02:44 /dev/kvmThe guest sees its own 4 GB of memory (the small size) and uses about 300 MB after boot. "Micro" describes the VMM and device model, not what you can run: the guest has systemd, root via sudo, Docker and its own /dev/kvm for nested VMs. See Docker and nested KVM inside an agent sandbox.
Delete the sandbox when you're done:
sbx delete $id --yesFAQ#
Is a microVM the same as a container?#
No. A container is a group of processes on the host's kernel, isolated by namespaces and cgroups. A microVM is a real virtual machine with its own kernel, isolated by hardware virtualization through KVM. Kata Containers runs containers inside lightweight VMs to combine the two.
Is KVM a type 1 or type 2 hypervisor?#
KVM is part of the Linux kernel and runs guests directly on the CPU's virtualization extensions, which is why it is often called type 1; because the same kernel also runs ordinary programs, some people call it a hybrid. The VMM, such as Firecracker or Cloud Hypervisor, is an ordinary user-space process that asks KVM to create the VM and its vCPUs.
What makes a microVM "micro"?#
The VMM and the virtual hardware, not the guest. A microVM VMM emulates very few devices, uses virtio for I/O and usually skips firmware. The guest can still be large: a Sandboxer sandbox runs full Ubuntu 24.04.
Does AWS Lambda use microVMs?#
Yes. Firecracker's README says it was built at AWS to "accelerate the speed and efficiency of services like AWS Lambda and AWS Fargate".
Can I run a microVM on Windows or macOS?#
Firecracker and Cloud Hypervisor need a Linux host with KVM, and Cloud Hypervisor can also use the Microsoft Hypervisor on Linux. On a Windows or Mac laptop, you'd run them inside a Linux VM, or use a hosted microVM such as a Sandboxer sandbox.
Related#
More guides
For running AI-written code we rank Sandboxer, Freestyle and E2B first: each gives code its own VM with an API or SDK and can pause with memory. Pick Daytona for Windows or GPUs, Modal or Northflank for GPUs at scale, E2B or Northflank to run in your own cloud, and Vercel Sandbox if your app lives on Vercel.
For coding agents we rank Sandboxer first: a full Ubuntu VM with Claude Code and Codex preinstalled, Docker, and stop-and-resume that keeps the agent's session in memory. Freestyle and Amp Orbs also keep memory across pauses. Pick E2B for prebuilt agent templates on open source, Docker Sandboxes for free local runs, and Codespaces if you live in GitHub.
The best Daytona alternatives depend on why you're switching. For a full Linux microVM on every sandbox with memory-saving stop and Docker, we rank Sandboxer first. E2B suits open source and self-hosting, Modal massive short-job fleets, Northflank bring-your-own-cloud with GPUs, and Vercel Sandbox apps on Vercel.
If you're leaving E2B for longer sessions or a fuller machine, we rank Sandboxer first, then Freestyle: both give each sandbox a full Linux VM that keeps memory across pauses, with Docker and no short session cap. Pick Daytona for Windows or GPUs, Northflank for bring-your-own-cloud, and stay on E2B if you need open source.