What Is a MicroVM? MicroVMs vs Containers Explained

A microVM is a small virtual machine that boots its own Linux kernel behind a hardware virtualization boundary, but strips the machine down to a handful of devices so it starts fast and uses little memory. You get the isolation of a VM at a cost close to a container's, which is why serverless platforms and AI agent sandboxes run untrusted code in them.

How a microVM works

A microVM is built from three layers: the host kernel's virtualization support (KVM on Linux), a virtual machine monitor (VMM) that creates and manages the guest, and a guest Linux kernel that runs your code. The guest never shares a kernel with the host or with other guests. Everything it can touch goes through the VMM and the CPU's virtualization extensions.

What makes it "micro" is what the VMM leaves out. A traditional VM emulates a whole PC: BIOS, PCI bus, USB, graphics, sound. A microVM VMM emulates only what a server workload needs, usually a virtio network device, a virtio block device and a serial console. Firecracker, the best-known example, emulates five devices in total.

The result:

• Each guest has its own kernel. A kernel bug exploited inside the guest compromises that guest, not the host.
• The attack surface is small. Fewer emulated devices means less VMM code an attacker can reach from inside.
• Boot is fast. With no firmware or device probing, the guest kernel starts almost immediately. Firecracker documents startup under 125 ms and memory overhead under 5 MiB per microVM.
• Density is high. Firecracker documents creating up to 150 microVMs per second on one host.

If you want the container half of this story in more depth, what a container really is walks through namespaces, cgroups and images from the ground up.

MicroVM vs container vs traditional VM

A container is a process on the host with a restricted view of it, a traditional VM is a full emulated computer, and a microVM sits between them: a real VM with its own kernel, cut down to start and pack like a container. The main question is where the isolation boundary sits.

The trade-off is the kernel. Containers are cheap because every container calls into the same host kernel, and that is also their weak point: one kernel exploit reaches the host and every neighbor on it. A microVM pays a small boot and memory cost to put a separate kernel in the way.

MicroVM vs gVisor vs bubblewrap

gVisor and bubblewrap are often compared with microVMs, but neither one is a VM. Both keep your code on the host kernel and limit what it can reach, which makes them cheaper and weaker than a hardware boundary.

• gVisor is an application kernel written in Go that runs in user space. Its runtime, runsc, plugs into Docker and Kubernetes. Your process makes Linux system calls to gVisor's Sentry instead of the host kernel, which shrinks the host surface it can reach. The gVisor docs are direct about the cost: lower application compatibility and higher per-system-call overhead, so syscall-heavy workloads can run slowly.
• bubblewrap is a low-level, unprivileged sandboxing tool used by Flatpak. It builds a sandbox out of Linux namespaces, always starting with a new mount namespace, and doesn't need root. It is a good fit for confining a desktop app or a local CLI tool, not for hostile multi-tenant code.
• A microVM gives the code its own kernel, so a syscall bug inside the guest hits the guest kernel. It needs hardware virtualization on the host, which gVisor and bubblewrap don't.

A rough order from weakest to strongest boundary: plain container, bubblewrap, gVisor, microVM. Many platforms mix them. Beam's open-source runtime, beta9, ships runc, gVisor and microVM runtimes, and its default worker configuration uses gVisor.

Common microVM implementations

Most microVMs come from one of four open-source projects. Three are VMMs, and Kata Containers wraps them so they run under container tooling.

Firecracker

Firecracker is an open-source VMM written in Rust, built for secure, multi-tenant container and function services. It powers AWS Lambda. Fly.io runs application code in Firecracker microVMs, and E2B's infrastructure runs one Firecracker microVM per sandbox.

Cloud Hypervisor

Cloud Hypervisor is an open-source VMM implemented in Rust, aimed at modern cloud workloads with only lightweight hardware emulation. It supports x86-64 and aarch64.

QEMU microvm

QEMU ships a microvm machine type inspired by Firecracker: a minimalist machine without PCI or ACPI support, designed for short-lived guests. It suits teams that already run QEMU and want a lighter guest.

Kata Containers

Kata Containers is an open-source container runtime that builds lightweight VMs which feel and perform like containers. It speaks the OCI format and the Kubernetes CRI, and it can use QEMU, Cloud Hypervisor or Firecracker underneath. If you run your own Kubernetes cluster, Kata is usually the shortest path to microVM isolation; the guide to self-hosting a code execution sandbox covers that route.

When to use a microVM instead of a container

Use a microVM when the code you run isn't yours, or when it needs a whole operating system. Stick with containers when you trust the code and want the cheapest, fastest start.

A microVM is the right call for:

• Untrusted or AI-generated code. Anything a model or an end user wrote should run behind a kernel boundary.
• Multi-tenant platforms. If customers share hosts, one customer's kernel exploit must not reach another's workload.
• Workloads that need root, systemd or Docker. A guest kernel lets the code act like it owns a machine without owning yours.
• Pause and resume. A VM's memory can be checkpointed as a unit, which makes suspending a long session simpler.

A container is enough for your own services, CI jobs on trusted repos, and batch work you wrote and reviewed. gVisor is a reasonable middle step when the host can't run KVM.

Why AI agents need a kernel boundary

An AI agent writes code and then runs it, often as root, often after reading text from the open web. That makes every agent a source of untrusted code, even when the agent itself is yours. A prompt injection that gets an agent to run a kernel exploit in a shared-kernel container has reached the host.

Long-lived agents raise the stakes. A coding agent that works for hours installs packages, starts databases, runs Docker and leaves daemons behind. That needs a real init system and a real kernel, so it fits a microVM far better than a container. It also needs state that outlives a single run: a disk that persists, and a way to pause the whole machine and pick it up later.

Short tasks are different. An agent that runs one snippet and exits needs isolation more than persistence, so a disposable sandbox is the better fit. For a vendor-by-vendor view of which platforms keep state between runs, see the roundup of stateful sandboxes and microVM providers.

Running agent code in a microVM sandbox or a persistent VM

Beam offers both shapes. A Beam sandbox is a disposable environment that runs on a container runtime by default, and use_vm=True moves it into a microVM. A Beam VM is a persistent CPU microVM with its own kernel, systemd, a durable root filesystem and stable service URLs.

For a short task, create a sandbox with the microVM runtime, run the code and throw it away:

use_vm=True changes only the isolation. It does not turn the sandbox into a persistent, named VM.

For an agent that needs a machine of its own, create a VM. It keeps its root disk across stop and start, and pause keeps its memory too:

From the CLI, beam vm new devbox followed by beam vm ssh devbox gives you a shell in the guest.

VMs bill per second while running, with no compute charges while stopped or paused. Prepared VM images include Docker, Compose and Buildx, with the daemon off until you enable it, plus the Claude Code and Codex CLIs. The Beam virtual machines page covers sizes and pricing, and the sandbox page covers GPU sandboxes. If you are weighing Docker's own sandboxing against a VM, Docker sandbox alternatives compares the options.

FAQ

Does a microVM have its own kernel?

Yes. Every microVM boots its own guest Linux kernel, and that is the main difference from a container, which shares the host kernel. The kernel runs behind hardware virtualization, so a kernel exploit inside the guest stays inside the guest.

What is the difference between a microVM and a VM?

A microVM is a VM. It uses the same hardware virtualization, but its VMM emulates only a few devices instead of a full PC, so it boots in milliseconds rather than seconds and uses a few MiB of overhead instead of hundreds.

Is Firecracker a microVM?

Firecracker is the VMM that creates microVMs, not the microVM itself. People say "a Firecracker microVM" to mean a guest that Firecracker runs. AWS Lambda and Fly.io both run workloads in Firecracker microVMs.

Is gVisor a microVM?

No. gVisor is a user-space application kernel that intercepts system calls on the host kernel. It gives stronger isolation than a plain container without hardware virtualization, but there is no guest kernel and no VM boundary.

Do microVMs need KVM?

On Linux, yes. Firecracker and Cloud Hypervisor rely on hardware virtualization, which means bare-metal hosts or cloud instances with nested virtualization enabled. beta9's microVM runtime also needs /dev/kvm on the worker.

Can you run Docker inside a microVM?

Yes, because the guest is a full Linux system with its own kernel. On a Beam VM, prepared images ship Docker, Compose and Buildx, and you start the daemon with --docker-enabled. Its data persists on the root disk across stop and start.

Is a microVM slower than a container?

It starts slower, because it boots a kernel, but a minimal VMM keeps the gap small: Firecracker documents startup under 125 ms. It also carries a few MiB of memory overhead per guest. Containers stay the cheapest option for trusted code.

Run agent code behind a kernel boundary

Beam runs short tasks in sandboxes you can move into a microVM with one argument, and gives long-running agents a persistent microVM with Docker, systemd and a stable URL. Create a Beam account and start one from the Python or TypeScript SDK.