What it is
A microVM is a minimal virtual machine: it has its own operating system kernel, its own memory space, and a hardware-enforced boundary separating it from the host machine — but it is stripped of the extra devices, firmware, and boot machinery that make conventional VMs slow to start. Amazon Web Services built the best-known implementation, an open-source virtual machine monitor called Firecracker, specifically to run untrusted, multi-tenant workloads at scale. Firecracker microVMs start in well under 125 milliseconds, carry a memory overhead of less than 5 MiB, and can be created at a rate of roughly 150 per second on a single host, according to the project’s own documentation.
The appeal is that microVMs occupy a middle ground between two weaker options. Containers are fast and lightweight but share the host’s kernel, so a flaw in the container runtime or a privilege-escalation bug can, in principle, expose the whole machine. Traditional virtual machines isolate more thoroughly — each gets a dedicated kernel — but are heavy: slow to boot, resource-hungry, and poorly suited to workloads that spin up and tear down thousands of times a day. MicroVMs aim to keep the VM-level isolation (a separate kernel, a hypervisor boundary that a guest cannot easily see past) while cutting startup time and overhead down toward container-like levels, largely by discarding legacy hardware emulation and BIOS/UEFI boot steps.
Firecracker itself is built on Linux’s KVM hypervisor and descends from Chromium OS’s crosvm project. AWS uses it to isolate individual AWS Lambda function invocations and Fargate tasks from one another on shared physical hardware — the company has said Firecracker has powered more than 15 trillion monthly Lambda invocations. Firecracker also ships a companion tool, “jailer,” intended as a second line of defense if the virtualization boundary itself is ever compromised, and it deliberately emulates only a handful of devices to shrink the attack surface.
Why it matters for AI governance and narratives
MicroVM isolation has become a load-bearing piece of infrastructure in the argument that autonomous AI agents can be run safely. Coding agents and other “agentic” tools are increasingly given the ability to execute arbitrary commands, install packages, and modify files — capabilities that are useful precisely because they are dangerous if the agent misbehaves, is manipulated by malicious input, or simply makes a mistake. Vendors selling sandboxing infrastructure — Docker’s Docker Sandboxes product, described in an April 2026 company blog post, and code-execution platforms like E2B — market microVM isolation as the technical answer to that risk: even if the agent inside is compromised or goes rogue, the argument goes, it cannot reach the host system or other tenants because it is walled off by a hardware-level hypervisor boundary rather than a shared-kernel container.
This is worth reading skeptically as well as technically. The companies making these claims are the same ones selling the isolation product, and “strong isolation” is a marketing term as much as an engineering one — Firecracker and its peers reduce attack surface, they do not eliminate it, and hypervisor escape vulnerabilities, while rare, are not unheard of in the broader virtualization literature. The narrative that agent autonomy is being safely “contained” by infrastructure is doing real work in the current debate over how much operational latitude to give AI agents; it deserves the same scrutiny as any other safety claim made by a vendor with a product to sell.
Key facts and dates
AWS announced and open-sourced Firecracker at re:Invent in November 2018, positioning it as infrastructure for Lambda and Fargate. Since then it has been adopted well beyond Amazon: Fly.io and Kata Containers both use Firecracker to isolate customer workloads, and it underpins a wider ecosystem of “serverless sandbox” providers. Docker’s entry into this space is recent — the company published its own from-scratch hypervisor rationale in April 2026, arguing that Firecracker’s Linux/KVM-only design left it without native macOS or Windows support, which matters for a product aimed at local developer machines running coding agents rather than cloud-only infrastructure. Docker’s implementation uses KVM on Linux, Apple’s Hypervisor.framework on macOS, and the Windows Hypervisor Platform on Windows, giving each agent session its own microVM, its own kernel, and its own isolated Docker daemon.
Where to learn more
- Firecracker project overview — the technology’s own documentation on design, security model, and performance figures
- AWS: Introducing Firecracker (November 2018) — the original announcement
- Docker: Why MicroVMs — The Architecture Behind Docker Sandboxes (April 2026) — vendor rationale for using microVMs to sandbox coding agents
- Firecracker on GitHub — source code and technical specifications