Cloud Parts

MicroVMs

A stripped-down virtual machine that boots as fast as a container, with its own kernel.

5 technologies on this page ↓
Live model
What you’re watchingThree customers send untrusted code to run. Each job gets its own microVM, with its own kernel, on one shared host; amber marks a 125 ms boot. Idle microVMs are thrown away, so the next job always starts clean.

How it works

A microVM uses the same hardware virtualization as a normal VM, so each one gets its own kernel and a hard boundary from its neighbors. The monitor that runs it emulates only a few devices (a network card, a disk, a serial console) and no BIOS or USB, so there is far less to boot and far less to attack. Firecracker, the best-known one, starts a microVM in about 125 ms with under 5 MiB of overhead, so one host can run thousands. Many platforms also snapshot a booted VM and restore copies of it, which is faster than booting.

Think of it as

A row of locked hotel rooms instead of bunks in a shared dorm. Containers are the dorm: quick to fill, but everyone shares one building. MicroVMs give each guest their own room with its own lock, and housekeeping can still turn a room around in seconds.

Reach for it when

  • Running code you didn’t write: AI agent sandboxes, online code playgrounds, customer plugins
  • Building a multi-tenant platform where one customer must never reach another
  • Giving each CI job or user session a fresh machine that is thrown away afterwards

Think twice when

  • Your own trusted services, where plain containers are simpler and have better tooling
  • Workloads that need GPUs or unusual devices; Firecracker emulates very few, and GPU passthrough isn’t in a release yet
  • Hosts without KVM access, e.g. most cloud VMs unless they’re bare metal or allow nested virtualization

A real example

AWS Lambda isolates its function execution environments with Firecracker microVMs, so code from thousands of customers shares the same physical servers without sharing a kernel. When a burst arrives, new microVMs start in a fraction of a second, which is a large part of a cold start.

Technologies

Specific products, and what each does differently.

Also used for microvms

Products of other kinds that are often used this way, grouped by what they are.

What each provider calls it

AWS
Firecracker (under Lambda), Lambda MicroVMs
Google Cloud
Cloud Run second-generation execution environment; GKE Sandbox microVMs (Kata Containers)
Azure
Container Instances, Container Apps dynamic sessions (Hyper-V isolation); AKS Pod Sandboxing (Kata Containers)
Open source & others
Firecracker, Cloud Hypervisor, Kata Containers, QEMU microvm, Fly.io Machines, E2B, smolvm

See it in a real stack

Architectures that use microvms

Code sandboxes for AI agentsAn agent’s code runs in a fresh Firecracker microVM per task, isolated by its own kernel, with outputs saved to S3.FirecrackerAmazon S3

In code · bash

# Firecracker is configured over a REST API on a Unix socket
fc() { curl -s --unix-socket /tmp/firecracker.socket -X PUT "http://localhost/$1" -d "$2"; }

fc boot-source    '{"kernel_image_path": "vmlinux", "boot_args": "console=ttyS0 reboot=k panic=1"}'
fc drives/rootfs  '{"drive_id": "rootfs", "path_on_host": "rootfs.ext4", "is_root_device": true, "is_read_only": false}'
fc machine-config '{"vcpu_count": 2, "mem_size_mib": 1024}'
fc actions        '{"action_type": "InstanceStart"}'

Worth exploring

ArticleKubernetes in a microVMsmol machines docsThe vendor’s own guide to two ways of combining Kubernetes with microVMs: a containerd shim and RuntimeClass that start each pod as its own VM (marked experimental, with its known blockers listed), or a whole k3s cluster, through k3d, inside one VM. Useful for the concrete details, such as per-pod overhead, the /dev/kmsg device the kubelet needs and why Docker’s storage must sit on ext4, but written to sell smolvm.
All resources →

Often confused with

Virtual machinesContainersServerless functions (FaaS)HypervisorsVM, container, microVM or function?
Where it came from2017–2026

By the mid-2010s, anyone running other people’s code had two imperfect options. A virtual machine gave each tenant its own kernel and a hardware boundary, but general-purpose monitors like QEMU emulate a whole PC (BIOS, PCI bus, dozens of devices), which makes them large and slow to boot. Containers started in about a second but shared the host’s kernel, so isolation rested on one kernel shared with every neighbour. Serverless platforms, which start and stop thousands of short-lived sandboxes for strangers, needed the safety of the first with the speed of the second.

Two answers arrived within a year. In late 2017 Kata Containers merged Intel’s Clear Containers and Hyper’s runV to run each container inside its own lightweight VM. In November 2018 AWS open-sourced Firecracker, the monitor behind Lambda, and called its guests microVMs: a few virtio devices, no BIOS or PCI, under 125 ms to boot and under 5 MiB of overhead. The idea spread quickly. Cloud Hypervisor began in 2019 as a Rust monitor for general cloud workloads, and QEMU 4.2 added a microvm machine type “inspired by Firecracker” that December.

MicroVMs now sit under many serverless and sandbox platforms, and some restore them from snapshots instead of booting them at all.

Why it’s built this way

Keep hardware virtualization, drop the PC
The CPU’s virtualization features give the hard boundary; almost everything else a normal VM emulates is legacy hardware a cloud workload never touches. Removing it cuts boot time, memory and attack surface together.
Paravirtual devices only
Instead of imitating real network cards and disks, microVMs offer virtio devices that cooperate with the guest kernel, which is simpler and faster to emulate.
Monitors written in Rust
The monitor is the wall between tenants, so memory-safety bugs matter. Firecracker, crosvm and Cloud Hypervisor are all Rust and share components through the rust-vmm project.
Restore from a snapshot instead of booting
The VM boots fast, but starting a runtime and app inside it can take seconds. Snapshotting the VM after initialisation and restoring copies skips both; AWS says SnapStart can cut cold starts “from several seconds (or higher) to as low as sub-second”.

Timeline

  1. 2017

    Kata Containers launches, merging Clear Containers and runV

  2. 2018

    AWS open-sources Firecracker, already running Lambda

  3. 2019

    Cloud Hypervisor starts; QEMU 4.2 adds a Firecracker-style microvm machine type

  4. 2022

    Lambda SnapStart restores functions from Firecracker snapshots

  5. 2026

    AWS launches Lambda MicroVMs, stateful sandboxes built on Firecracker

Sources19

Improve this page on GitHub