Firecracker microVMs in plain language: a real VM that boots in a fraction of a second

If you've read anything about running AI-generated code safely, you've seen the word microVM, usually next to Firecracker. It tends to be explained either as "a lightweight VM" (true, unhelpful) or with a diagram of kernel internals. Here is the version in between.

Two older options, and why neither fits

Start with the two things a microVM sits between.

A container is a group of ordinary processes on your machine that the kernel has agreed to lie to. Namespaces show them their own filesystem, process list and network; cgroups cap how much CPU and memory they may use. It starts in milliseconds because nothing new is booted. But every container on a host talks to the same kernel. A kernel bug reachable from inside one container is a way out of all of them.

A virtual machine brings its own kernel. The host's CPU, through hardware virtualisation (KVM on Linux), runs the guest as if it had its own computer. The boundary is the hypervisor, which exposes far less than a kernel's hundreds of system calls. The cost is weight. A classic VM emulates a whole PC: firmware, a PCI bus, USB controllers, a graphics card, sometimes a sound card. It boots through all of that, takes seconds to minutes, and each instance carries tens or hundreds of megabytes of overhead.

An analogy that holds up reasonably well: containers are flats in one building, sharing foundations, pipes and wiring. VMs are separate houses. Houses are safer neighbours, but you don't build one for a visit that lasts 20 seconds.

What Firecracker removes

Firecracker is a virtual machine monitor (the program that sets up and runs a VM on top of KVM) written in Rust and open-sourced in 2018. It was built for one job: running huge numbers of short-lived, mutually untrusting workloads on shared hardware. It gets there mostly by deleting things:

• No firmware, no hardware discovery. The kernel is loaded straight into memory and started. Nothing probes for devices that aren't there.
• A tiny device model. A network card, a block device, a serial console and a few more, all virtio (devices designed for virtual machines rather than imitations of physical ones). No USB, no graphics, no PCI.
• A small, memory-safe codebase. Less code emulating devices means fewer places for a bug that lets the guest reach the host.
• A jail around the VMM itself. Each Firecracker process runs inside a chroot, with seccomp filters restricting its own system calls and cgroups limiting its resources. If something did break out of the guest, it would land in a cage, not on the host.

The project's own published numbers are user space in as little as 125 ms and under 5 MiB of memory overhead per microVM. Those are best-case lab figures; a real sandbox also needs its disk and network set up and an agent inside ready to accept commands, which is why ours is ready in about a second. That's still close enough to container speed that you can create one per task and throw it away afterwards.

Container vs microVM, in practice

The row that matters is the second. With a container, the question "can this code escape?" becomes "is there a reachable bug anywhere in the host kernel?" With a microVM, it becomes "is there a bug in the hypervisor or a handful of virtual devices?" The second surface is much smaller, and it's the one cloud platforms already defend for their own multi-tenant hosting.

What you give up

A microVM isn't a free upgrade.

• No GPUs and no displays. It's for running code, not for desktops or graphics workloads.
• Fewer devices, less flexibility. Anything that expects real hardware, or a long list of kernel modules, won't feel at home.
• Boundaries still need policy. A microVM with open egress can still send traffic you don't want; one with your API keys inside can still leak them. Isolation protects the host from the guest, not your secrets from code you handed them to.

How our sandboxes use it

Each EQVPS sandbox is one Firecracker microVM with its own kernel, from 0.25 vCPU and 512 MB up to 8 vCPU and 16 GB. It comes with Python 3.12, Node.js 22, bash, git and curl, has outbound internet and no inbound ports. Ephemeral sandboxes are deleted when you're done; persistent ones keep their disk, and pausing one writes a snapshot of the microVM to disk so it costs nothing until it resumes. Paused snapshots are kept for 14 days. After that the sandbox is deleted and its id returns 410 sandbox_deleted.

We picked microVMs over containers for one reason: the code that runs in a sandbox is, by design, code nobody has reviewed. An AI agent's output, a stranger's pull request, a benchmark of a thousand model-written programs. For that, a kernel of its own is the boundary worth paying for. The details of what we put around it — tariffs, quotas, the 55-second synchronous limit — are in the sandbox docs.

If you want to compare this boundary with the other options in more depth, isolation levels for untrusted code puts processes, containers, microVMs and full VMs side by side. And if the per-second price is what caught your eye, how per-second billing actually works shows the arithmetic.