What is a microVM? Firecracker, isolation, and why agents need it

A microVM is a virtual machine stripped down to the minimum needed to run one workload: a thin device model, a single guest kernel, and nothing else. It boots in milliseconds instead of the tens of seconds a traditional VM takes, yet it keeps the property that makes VMs safe — a real hardware-virtualization boundary between the guest and the host. PandaStack runs every sandbox, database, and hosted app inside its own microVM.

The term became mainstream with AWS Firecracker, the open-source Virtual Machine Monitor (VMM) that powers AWS Lambda and Fargate. Firecracker launched in 2018 specifically to give serverless workloads VM-grade isolation without VM-grade startup cost. That same trade-off — strong isolation, near-instant boot — is exactly what an AI agent platform needs when it runs untrusted, model-generated code.

microVM vs container: the one difference that matters

A container is a process on the host with a private view of the filesystem and network. It shares the host's Linux kernel. That sharing is what makes containers light and fast — and it's also the entire attack surface: a kernel bug or a container-escape exploit puts the host (and every other container on it) at risk. For your own code that's an acceptable risk. For code an LLM just wrote and you're about to execute, it isn't.

A microVM does not share the host kernel. Each microVM boots its own guest kernel and is confined by the CPU's hardware virtualization (KVM on Linux). An escape would have to break the hypervisor boundary — a far smaller, far more scrutinized surface than the full Linux syscall interface. Firecracker leans into this further by exposing only a handful of emulated devices (virtio-net, virtio-block, a serial console) and dropping everything else.

• Isolation boundary — container: shared host kernel (syscall surface). microVM: hardware-virtualized, separate guest kernel.
• Cold start — container: ~tens of ms to seconds (image pull, runtime). microVM: single-digit to low-hundreds of ms with snapshotting.
• Blast radius of an escape — container: the host and its neighbors. microVM: the VMM, a deliberately tiny surface.
• Density — both are high; microVMs add only a few MB of memory overhead per guest.

Why AI agents specifically need microVMs

An AI coding agent's whole value is that it runs commands you didn't write and couldn't fully predict: it installs packages, executes scripts, hits the network, edits files. Three properties make microVMs the right substrate for that:

1. Safety by default — a prompt-injected or simply buggy agent can rm -rf its own sandbox and reach for the network, but it cannot touch your host or another tenant's data.
2. Speed that disappears — if a fresh, clean environment takes 30 seconds to provision, agents batch work to avoid it and lose the ability to fan out. When it takes ~180ms, a fresh VM per task (or per turn) becomes free, and parallelism becomes natural.
3. State you can snapshot and fork — because the whole machine is a snapshot, you can freeze an agent's environment mid-task, fork it into ten parallel branches, and resume any of them exactly. That's not something a container model gives you cleanly.

How a microVM boots in milliseconds

Two techniques do most of the work. First, the VMM is minimal: Firecracker has no BIOS, no PCI, no legacy device emulation, so there's almost nothing to initialize before the guest kernel starts. Second — and this is the bigger lever — you don't cold-boot at all in steady state. You boot once, snapshot the running machine's memory and device state, then restore that snapshot on every subsequent create. Restoring a snapshot is essentially mapping memory and resuming vCPUs, which is why PandaStack's p50 create is 179ms rather than the multi-second cold boot.

We go deep on the snapshot-restore path, copy-on-write forking, and on-demand memory streaming in the engineering docs — but the headline is simple: the isolation is a real VM, and the speed comes from never paying for the boot twice.

When you don't need a microVM

Be honest about the trade. If you fully trust the code and you're optimizing pure throughput inside your own boundary, a container is simpler and the kernel-sharing risk is yours to accept. microVMs earn their keep precisely when the code is untrusted, multi-tenant, or generated on the fly — the agent, code-interpreter, CI-runner, and per-customer-sandbox cases. That's the line PandaStack is built on.