The State of MicroVM Isolation in 2026

Your Container Is Not a Sandbox

The microVM ecosystem was battle-tested long before agentic AI created the demand. Now it's thriving, diverse, and moving fast. This post covers every VMM, the shared Rust crate ecosystem, a dozen AI sandbox platforms and honest trade-offs.

Emir Beganović Staff SRE at Booking.com, Amsterdam March 27, 2026 · 25 min read GitHub · LinkedIn

I'm coming fresh from KubeCon EU 2026 with a lot of impressions. AI everywhere, the ecosystem is visibly maturing, and yet I counted at least five different companies on the expo floor solving remarkably similar isolation problems. It might be a sign that convergence is either about to happen (or already underway?) Anyway... one thing stuck with me more than anything else. In her security keynote, Marina Moore from Edera put it plainly:

Containers are not a security boundary. They are a mechanism to control resource usage.

I've been running Linux since I was a teenager, yet not until recently did I fully internalize what that sentence truly means.

Following my last few months spent going deep on microVMs, building infrastructure on them and learning every VMM, every isolation approach, every trade-off in this space...I wanted to write a post as the guide I wish I'd had when I started (with a dozen of references, blog posts, presentations and READMEs, I dug up so much high quality content). This covers the VMMs, the shared Rust ecosystem powering them, the AI sandbox explosion, and where I believe it's all heading.

The microVM ecosystem didn't need to be invented for AI. It needed to be discovered.

Linux containers are a packaging and resource control mechanism. Namespaces and cgroups restrict what a process can see and how much CPU and memory it can use. But every container on a host shares the same kernel. A kernel exploit, a rogue capability, a mis-mounted socket, and you're root on the host, with access to every other tenant's data. The kernel has ~40 million lines of C and exposes 450+ syscalls. That is the attack surface.

To be fair: containers are a boundary. You do need a vulnerability to escape one. There's no "just let me out" syscall. But the kernel attack surface is enormous, and escape CVEs ship regularly. An analogy that has stuck with me: NAT is not a firewall. Namespaces are not a security layer. Both restrict access as a side effect of their design, and both are commonly mistaken for security boundaries.

For a long time, this was an accepted trade-off. If you trusted the code inside the container (your own code, your own team), the convenience was worth it.

Then two things happened, but with several years apart.

First, AWS built Firecracker (2018), a tiny virtual machine monitor written in Rust, and used it to run every Lambda function in its own hardware-isolated VM. Boot time: 125ms. Memory overhead: <5 MiB. "Just spin up a VM" stopped being a punchline.

Second, AI agents started writing and executing arbitrary code. Millions of times a day. Code that nobody has reviewed, generated by models that cannot be audited, running on infrastructure where a container escape means game over.

The question stopped being "should we isolate untrusted workloads in VMs?" and became "why aren't we already?"

What Actually Happens When a Container "Escapes"

Hover over any layer below to understand what separates your code from the host in each model. The difference is not subtle.

In the container model, every layer is a software convention enforced by the shared kernel. The kernel is the security boundary, and the kernel has ~40 million lines of C. In the microVM model, the security boundary is hardware virtualization: Intel VT-x / AMD-V, enforced by the CPU itself. The VMM that orchestrates this? About 83,000 lines of Rust (Firecracker) or 106,000 (Cloud Hypervisor), as measured with cloc in March 2026.

A container escape gives you root on the host. A VM escape requires a hypervisor CVE, a class of bug so rare and valuable it commands $250K-$500K bounties on the exploit market (Google's kvmCTF offers $250K for a KVM escape alone).

This Isn't Theoretical

Container escapes are not hypothetical. From Marina Moore's KubeCon EU 2026, here are recent CVEs, all from 2024-2025:

Every one of these gave an attacker a path from inside a container to the host. In a microVM model, none of them matter as the guest kernel is isolated by hardware.

A Brief History of Trying to Isolate Processes

To understand where microVMs fit, it helps to see the arc. We've been trying to isolate processes for nearly 50 years, and containers were just one chapter:

The pattern is clear: every approach that shares a kernel eventually hits the same wall. chroot didn't isolate processes. FreeBSD jails didn't isolate networking. Namespaces and cgroups don't isolate the kernel's 450+ syscall attack surface. Each generation added more layers of software defense, and each generation produced new escape CVEs.

MicroVMs break the pattern by not sharing a kernel at all. The isolation is architectural, not incremental.

Not everyone waited for the industry to figure this out. Jessie Frazelle was making this exact argument back in 2018, in a series of blog posts that read like prophecy today: Setting the Record Straight: containers vs. Zones vs. Jails vs. VMs, Hard Multi-Tenancy in Kubernetes, and Getting Towards Real Sandbox Containers. She stated plainly that containers were never designed as a top-level security boundary and that real multi-tenant isolation requires hardware virtualization. She was right, and it looks like it took the rest of the industry years to catch up with her thinking.

The Rust VMM Revolution

In 2018, AWS open-sourced Firecracker and changed what "lightweight VM" meant. Before Firecracker, "spin up a VM" meant QEMU: 1.7 million lines of C, hundreds of emulated devices (including a floppy drive controller, because why not), and boot times measured in seconds.

Firecracker asked: what if we stripped all of that away? No BIOS, no ACPI, no PCI, no USB...A total of five emulated devices, written in Rust, so entire categories of CVEs (buffer overflows, use-after-free, double-free) are eliminated at compile time.

The result: the fastest VMM ever built, and not just in theory, but working tirelessly in practice. AWS runs trillions of Lambda invocations per month on it. Every single one in its own VM.

But Firecracker wasn't built in a vacuum. Its origin traces back to Google's crosvm, the Chrome OS VMM, also written in Rust. Amazon used crosvm as a starting point, then built Firecracker. After Firecracker came Cloud Hypervisor, libkrun, Dragonball Sandbox, and others. All of them kept reinventing the same low-level components: KVM wrappers, virtio device models, memory management.

This convergence on KVM wasn't accidental. AWS itself had launched EC2 on Xen in 2006, but starting in 2017 migrated to the Nitro system, a KVM-based hypervisor paired with custom Annapurna Labs silicon for network and storage I/O. All new EC2 instance types are Nitro-based; Xen instances are legacy. The same pattern played out across the industry: Google Cloud runs KVM, Azure moved to KVM-based Hyper-V, and even Edera, which spent years positioning Xen as the more secure choice, announced KVM support just yesterday around Kubecon because their customers demanded it. When the entire industry converges on a single hypervisor interface, building shared infrastructure on top of it becomes inevitable, and that's exactly what rust-vmm is.

The community recognized the waste. AWS, Intel, Google, Microsoft, Red Hat, Alibaba, Linaro, and others started collaborating on rust-vmm, a shared ecosystem of Rust crates that any VMM project can use. The FOSDEM 2026 presentation by Stefano Garzarella, Ruoqing He, and Patrick Roy showed just how mature this has become:

This is the part that doesn't get enough attention. rust-vmm is the real revolution, not any single VMM. It means we don't have one good VMM. We have a shared foundation that makes it possible to build many good VMMs, each optimized for different trade-offs. An improvement to vm-memory benefits Firecracker, Cloud Hypervisor, libkrun, Dragonball, and crosvm simultaneously. A new architecture (RISC-V) only needs to be implemented once in the crates, and every VMM gets it.

The consumers tell the story of breadth: Firecracker (AWS), Cloud Hypervisor (Intel/Microsoft), crosvm (Google/ChromeOS), libkrun (Red Hat), Dragonball Sandbox (Alibaba/Kata), OpenVMM (Microsoft), and virtiofsd (the reference virtio-fs daemon, itself a rust-vmm project). Even vmexec, a zero-setup CLI tool for running commands in throwaway VMs uses the ecosystem. The vhost-user device implementations alone cover can, console, gpio, gpu, i2c, input, rng, scmi, scsi, sound, spi, video, and vsock.

Firecracker vs. Cloud Hypervisor: The Fork in the Road

If you're evaluating microVMs today, you'll quickly arrive at the same fork like I did at my work: Firecracker or Cloud Hypervisor?

Firecracker is ~83K lines of Rust, Cloud Hypervisor ~106K. Both use KVM. Both share code through rust-vmm. In synthetic benchmarks, the virtualization overhead is in the low single-digit percentages (effectively negligible).

The difference is in their philosophy, and it mostly comes from the fact how Firecracker was born at AWS for one specific job.

Firecracker is a scalpel. It deliberately removes features to minimize attack surface. No GPU passthrough. No CPU hotplugging. No nested virtualization. This is perfect for AWS Lambda's threat model: short-lived functions that never need /dev/kvm or a GPU.

Cloud Hypervisor is a Swiss Army knife. It keeps the minimal spirit but adds the features that general-purpose cloud workloads need: nested KVM (--cpus nested=on added last December 2025), VFIO device passthrough (GPUs!), CPU/memory hotplugging, Windows guest support. The cost is a few dozen ms slower boot time and a slightly larger attack surface, though the core is heavily built on the same rust-vmm crates as Firecracker.

Fly.io (a public cloud that runs customer containers as Firecracker VMs on their own hardware worldwide which I admire) learned this the hard way with GPUs. They run Firecracker for standard workloads and they do it very well with superb developer experience. But they had to bring in Cloud Hypervisor for GPU Machines that need PCIe passthrough, burning months trying to get Nvidia's host drivers working, at one point hex-editing closed-source drivers to trick them into thinking Cloud Hypervisor was QEMU. They've since scaled back their GPU ambitions. If your workloads need nested KVM, Windows, or other stuff like Android device emulators, then Cloud Hypervisor is the pragmatic single-VMM choice. If you only need ephemeral compute, Firecracker's simpler model may be worth it.

Performance: Boot Time and Runtime Overhead

The most common objection to microVMs is latency. "A whole VM per request? That'll add minutes." It turns out it doesn't at all. That's why I added this fancy dry-run vanilla HTML/CSS/JS demo below (from a real Cloud Hypervisor microVM). The Firecracker NSDI'20 paper measured <125ms to boot a Linux kernel and start accepting API calls. With snapshot-restore, you can get to ~28ms. AWS Lambda uses this for SnapStart: they freeze the VM after initialization, then restore the snapshot on cold start. Colin Percival has gotten FreeBSD booting on Firecracker in under 20ms with kernel patches (the kernel boots faster than a TCP handshake!). I myself stripped a minimal Linux 6.18 kernel to ~30 MB with minimal drivers required to run Docker-in-Cloud Hypervisor correctly, and on modern hardware it boots in 200ms.
For comparison: Kubernetes pod scheduling typically takes 3-15 seconds. A traditional VM boot is 30-60 seconds. A microVM boot is not the bottleneck.

Runtime overhead is equally minimal. Guest code runs directly on the CPU via KVM with single-digit percentage overhead. Oracle's Firecracker on OCI benchmarks showed ~3% CPU overhead even with nested virtualization. In practice, dedicated-core VMs often outperform containers on shared hosts: when a container gets --cpus=4 on a 192-thread host, CFS bandwidth throttling freezes the entire cgroup once daemon threads and GC exceed the quota. A VM with dedicated cores has no quota and the CPU time is a physical property of the hardware.

The honest trade-off is operational complexity, not performance. Managing guest kernels, rootfs images, and a VMM is real work. I enjoy it because our goal was to build the fastest, safest internal CI platform possible. In that segment, and others like it, microVMs earn their place: when you're running untrusted code, when you need multi-tenant isolation, or operate at a scale where the security cost of a single container escape exceeds the engineering cost of running a VMM.

The old "VMs are too slow" argument stopped being persuasive years ago. Boot time is ~125ms. Runtime overhead is single-digit percent. The real cost is operational, not performance.

The Matryoshka Model

I couldn't think of a better metaphor than the Russian dolls (or the layers of onion) for this part. The most powerful pattern emerging in 2026 is nesting containers inside VMs: a host runs a VMM, the VMM runs a Linux kernel, the kernel runs a container runtime, the runtime runs user code. I'm personally very bullish on this model. Each layer trusts the layer below it and nothing else. It gets mentally complex quite quickly, but it all comes in place after I ran full end to end docker run hello-world equivalent running in a microVM that just booted 200ms ago ¯\_(ツ)_/¯

This is the model that Fly.io Sprites, E2B, AWS Lambda, and Kata Containers more or less converge on. The details differ: Firecracker vs. Cloud Hypervisor, ephemeral vs. persistent, containers vs. direct processes...but the architecture is the same: the VM is the security boundary, not the container.

AI Agents Made Everyone Care

In 2024, microVMs were an infrastructure niche. AWS used them. Fly.io used them. A handful of companies building hardened Kubernetes (Kata Containers, Edera) used them. Everyone else ran containers and hoped for the best.

In 2025, Claude, GPT, Gemini, and Codex started writing code and demanding to execute it. Not toy code, real code that installs packages, runs servers, modifies filesystems, and makes network requests. Millions of sessions per day.

Suddenly every AI platform needed an answer to the same question: where does the agent's code run?

The pattern is unmistakable. In the span of 18 months, nearly every major platform converged on the same answer: untrusted code needs stronger isolation than a container. Most chose microVMs. Modal chose gVisor. Cloudflare chose V8 isolates. The debate is no longer whether to isolate but how: which VMM, which boundary, and how persistent the state should be.

Beyond Sandboxes: MicroVMs in Kubernetes

The sandbox story gets the attention, but the arguably more important front is Kubernetes (especially now after I spent 3 days at KubeCon). Three projects are bringing hardware-level isolation to every pod, each with a different philosophy:

The gVisor Question

Any honest discussion of isolation in 2026 has to take gVisor seriously. It's not a microVM; it's a user-space application kernel written in Go that intercepts syscalls and re-implements them in a memory-safe process. No hypervisor, no guest kernel. But dismissing it as "weaker isolation" misses the picture.

Google runs billions of containers on gVisor across Cloud Run, App Engine, and Cloud Functions. Modal built their entire GPU inference platform on it. DigitalOcean upgraded their App Platform's gVisor deployment to the new systrap mode and saw 2x throughput on Node.js, 7x on WordPress. The systrap mode (which replaced ptrace) drastically reduced overhead, and gVisor reimplements ~274 Linux syscalls in Go, but the Sentry itself only makes 53 host syscalls without networking, 68 with, a dramatically smaller surface than the kernel's 450+.

The strongest case for gVisor over microVMs is GPU workloads. VFIO GPU passthrough into a microVM breaks the VM isolation boundary anyway, as the GPU has DMA access to host memory. gVisor's nvproxy intercepts CUDA calls in a memory-safe layer, which arguably gives you better security than a microVM with a passed-through GPU. This is exactly why Modal uses gVisor for GPU inference.

The strongest case for microVMs over gVisor is compatibility. gVisor re-implements a subset of the Linux kernel. If your workload hits an unimplemented syscall or kernel feature, it breaks; and Google Cloud Run moved to microVMs for their second-gen execution environment partly because customers kept asking for kernel features gVisor didn't support. MicroVMs run a real kernel; everything just works.

The honest take: gVisor and microVMs are complementary tools for different points on the isolation-vs-compatibility spectrum. gVisor wins on startup speed (~50ms), memory efficiency, and GPU workloads. MicroVMs win on compatibility, nested virtualization, and the simplicity of "it's just Linux." Neither has won and actually it seems that both are thriving with different customer bases.

The Ecosystem Is Thriving

What excites me most about this space in 2026 is the diversity. There isn't one microVM solution: there's an ecosystem, and it's maturing fast:

rust-vmm is consolidating into a monorepo (announced at FOSDEM 2026) and adding RISC-V support. The shared crate ecosystem means improvements to virtio, KVM bindings, or memory management benefit every VMM that uses it.

libkrun from Red Hat is a sleeper hit: a library-based VMM with sub-200ms startup, transparent socket impersonation (no TAP devices needed), and paravirtualized GPU support on macOS. It powers Microsandbox and is integrated with crun for running containers directly inside microVMs.

Ubicloud is quietly proving the model works for CI, and for building an entire open-source cloud. Their architecture is instructive: a Ruby/Postgres control plane communicates with bare-metal Linux+KVM servers via SSH, where Cloud Hypervisor runs each VM inside Linux namespaces for additional isolation. They offer GitHub Actions runners at 10x cheaper than GitHub's pricing, with each job getting a clean, ephemeral VM on bare-metal providers. Open source under AGPL.

AWS added nested virtualization on standard EC2 instances (C8i/M8i/R8i) in February 2026. Previously you needed expensive bare-metal instances to run KVM inside EC2. Now a $0.86/hr c8i.4xlarge in Frankfurt can run Cloud Hypervisor with nested VMs. This unlocks microVM-based CI/CD on AWS without the $9-20/hr bare-metal tax.

crosvm, Google's VMM for Chrome OS, remains actively maintained and powers Linux (Crostini) and Android VMs on every Chromebook. Another rust-vmm consumer, another proof point for the shared ecosystem.

Lima (CNCF Incubating, 20K+ GitHub stars) started as a way to run containerd on macOS and has evolved into something broader. At KubeCon EU 2026, the Lima team presented their expansion into AI agent sandboxing. v2.0 added GPU acceleration via krunkit and an MCP server that lets AI agents safely operate inside VMs. Lima wraps QEMU, Apple's Virtualization.framework, WSL2, or krunkit as VM backends, and powers Colima, Rancher Desktop, and AWS Finch. It's the developer-friendly on-ramp to the whole ecosystem.

The Accidental Revolution

Here's the thing I keep coming back to: none of this was built for AI agents.

Firecracker was built for AWS Lambda in 2018. Cloud Hypervisor was built for general cloud workloads in 2019. rust-vmm has been maturing since 2018. Kata Containers has been in production since 2017. Fly.io has been running Firecracker since 2020. The monorepo consolidation, RISC-V support, IOMMU, formal verification with Kani proofs, all of this was happening quietly, year after year, while most of the industry was focused on Kubernetes and containers.

The technology was ready, but what was missing was demand.

Then in 2025, agentic coding exploded. Claude Code, Codex, Copilot, Gemini CLI, you name it: millions of sessions per day where an AI writes code and needs to run it somewhere. Every platform in the world suddenly needed an answer to "where does the agent's code execute?" and needed it now.

The answer was already sitting there. Mature. Battle-tested. Running trillions of Lambda invocations and millions of Fly.io Machines. The microVM ecosystem didn't need to be invented for AI: it needed to be discovered. Nearly every platform in the sandbox grid above was built in months, not years, because the hard problems were already solved in rust-vmm crates and production VMMs.

That's the quiet infrastructure revolution. Not a single breakthrough moment, but an accumulation: eight years of Rust VMM development, a shared crate ecosystem across competing companies, production battle-testing at hyperscaler scale, and then a sudden explosion of demand that pulled it all into the spotlight.

It's a little like what happened with containers in 2013. The kernel primitives (namespaces and cgroups) had been in Linux since 2006-2008. LXC existed since 2008. But it took Docker's developer experience to create the demand that made containers mainstream.

Conclusion

The endgame, in my opinion, isn't really that "microVMs will replace containers." It's that the isolation layer becomes invisible.

You'll still write Dockerfiles. You'll still kubectl apply. You'll still think in containers, and that's nice (no new cognitive load). But under the hood, each pod boots its own kernel in ~200ms. Each AI agent session, each CI job, and so on, gets its own hardware-isolated VM. And you never notice, because the VMM is <a few MiB of Rust that boots super fast.

This is already happening. Kata Containers puts a VM behind every Kubernetes pod. Docker Sandboxes wrap each coding agent in a microVM. AWS Lambda has been doing it since 2018 for every function invocation. The nicest pattern is container-inside-VM: the container provides the packaging and developer experience, the VM provides the isolation. The developer sees a container, everything works like it does locally with Docker/Podman. The security teams see a VM. Both are happy despite the underlying complexity.

The infrastructure to make this seamless is maintained by engineers at AWS, Intel, Google, Microsoft, Red Hat, and Alibaba, all contributing to the same monorepo of Rust crates. Thank you! Eight years of quiet work, and now the demand has arrived.

Your container is not a sandbox because it was never designed to be one. But it doesn't need to be, as long as it's running inside something that is.

Disclaimer: I am a Staff SRE at Booking.com working on developer-facing CI infrastructure that runs in microVMs. All opinions are my own.