Container-to-VM Runtimes

Executive Summary

Containers revolutionized deployment but they share a fatal flaw: the host kernel is a shared attack surface. One container escape compromises everything. As workloads get more adversarial — especially AI agents executing untrusted code — the industry needs VM-level isolation with container-level developer experience.

This comparison covers nine tools solving that problem. Since the March edition, the category gained three significant entrants — Apple's Containerization framework, Red Hat's libkrun, and Edera — and its demand driver became explicit: Google reports 16x sandbox growth on GKE in under five months and shipped a gVisor-based Agent Sandbox for exactly this workload.^[1]

Key finding: The market is splitting by use case. Firecracker dominates serverless and AI sandbox platforms. Kata owns multi-tenant Kubernetes. gVisor is the substrate for Google's agent push. Apple just made VM-isolated containers the default mental model on the Mac — and the developer-experience gap that Hypeman targets is closing from every direction.

---

The Problem: Shared Kernel = Shared Risk

Standard containers (Docker, containerd) use Linux namespaces and cgroups for isolation. This is process-level isolation, not machine-level. Every container on a host shares the same kernel, and the Linux kernel has ~30 million lines of code with a large syscall surface.

What goes wrong:

• Kernel exploits (CVE-2024-1086, CVE-2022-0185) can escape containers entirely
• Privileged containers or misconfigurations weaken isolation further
• seccomp and AppArmor reduce attack surface but don't eliminate it

Why it matters now: AI agents running LLM-generated code are the new threat model. You cannot trust code written by a model — it might install packages, open network connections, or exploit kernel bugs. VM boundaries provide hardware-enforced isolation that containers cannot.^[2]

---

Architectural Approaches

MicroVMs (Firecracker, Cloud Hypervisor)

MicroVMs strip traditional VMs down to the essentials. Firecracker provides a minimal device model, boots in ~125ms, and uses about 5MB of memory overhead per VM — proven at AWS scale across Lambda and Fargate.^[3][2] Cloud Hypervisor shares the rust-vmm lineage but adds what Firecracker deliberately won't: PCI/GPU passthrough, device hotplug, and Microsoft Hypervisor support.^[4]

Tradeoffs: Full Linux compatibility inside the VM, hardware-enforced isolation. But you build your own orchestration — these are VMMs, not platforms.

Embeddable MicroVMs (libkrun)

libkrun packages the microVM as a dynamic library: any process can embed a KVM (Linux) or Hypervisor.framework (macOS) VM with a function call.^[5] It powers podman machine's GPU-enabled macOS provider (krunkit), crun's krun handler, and YC-backed Microsandbox.

Tradeoffs: The cleanest way to put VM isolation inside your own tool; not a standalone product.

VM per Container on the Desktop (Apple Containerization)

Apple's Swift framework and container CLI run each OCI Linux container in its own lightweight VM via Virtualization.framework — sub-second starts, v1.0.0 shipped June 9, 2026, macOS 26 only.^[6] It mainstreams the one-VM-per-container model for millions of Mac developers.

Tradeoffs: Apple silicon + macOS 26 only; young ecosystem next to Docker Desktop.

Userspace Kernel (gVisor)

gVisor intercepts application syscalls and re-implements them in a userspace kernel called Sentry.^[7] No VM boots; the application kernel limits access to the host kernel. It runs millions of instances daily at Google and underpins the new GKE Agent Sandbox.^[1]

Tradeoffs: Lower overhead than full VMs, easy OCI deployment, GPU support via nvproxy. Syscall compatibility and I/O-heavy performance remain its costs, and it is not a hardware boundary.

Kubernetes-Native VMs (Kata Containers)

Kata runs each pod in its own lightweight VM behind a standard OCI/CRI interface with four hypervisor backends (QEMU, Cloud Hypervisor, Firecracker, Dragonball).^[8] It anchors confidential containers (AMD SEV, Intel TDX) and full GPU passthrough.

Tradeoffs: The drop-in K8s answer; boot and memory overhead exceed raw microVMs.

Type-1 Hypervisor Zones (Edera)

Edera rewrote the Xen control plane in Rust and isolates every Kubernetes pod in its own "zone" with a dedicated kernel; KVM support arrived in 2026 and Protect AI sells hardware-isolated GPU sharing.^[9] $20M raised, led by Microsoft's M12.

Tradeoffs: Strong isolation story including GPUs; commercial core with small open-source components.

Unikernels (Unikraft)

Unikraft compiles only the OS components an application needs into a single bootable image — cold boots in under 10ms and minimal attack surface, with a commercial serverless cloud on top.^[10]

Tradeoffs: Smallest footprint, fastest boot; specialized build tooling and reduced general-purpose compatibility.

Multi-Hypervisor Orchestration (Hypeman)

Hypeman sits above Firecracker, Cloud Hypervisor, QEMU, and Apple Virtualization.framework with a Docker-like CLI; v0.1.0 (June 2026) added fast restores, VM forking, and an egress MITM proxy.^[11][12]

Tradeoffs: Highest developer experience; early (164 stars), and effectively a single-vendor (Kernel, $22M raised) project.

---

Detailed Comparison

Performance

Security Model

Developer Experience

---

The AI Agent Angle

AI agent sandboxing is the fastest-growing use case for container-to-VM runtimes, and since March it stopped being a prediction:

• Google shipped Agent Sandbox on GKE (gVisor-based, 300 sandboxes/sec, Kubernetes SIG Apps subproject) and reports 16x sandbox growth on GKE in under five months^[1]
• Docker shipped Sandboxes — per-agent microVM isolation in Docker Desktop
• AWS rolled out nested virtualization on standard EC2 instances, removing the bare-metal tax on running microVMs in cloud
• Firecracker powers E2B's sandbox platform; Hypeman powers Kernel's agent browser isolation; libkrun powers Microsandbox's self-hosted sandboxes^[3][11][5]

What agents need: fast boot, full Linux compatibility, network egress control, and snapshot/fork for checkpointing. The GPU is the fault line — agents increasingly need accelerators, and the approaches diverge sharply: gVisor's nvproxy intercepts CUDA in a memory-safe layer, Kata passes whole GPUs through, Edera sells isolated GPU sharing, and naive VFIO passthrough re-opens the boundary via GPU DMA.

The pattern holds: higher-level platforms build on these runtimes and expose developer-friendly APIs. The VMM layer is becoming infrastructure — the value moves up the stack.

---

Choosing the Right Tool

Maximum density at scale → Firecracker. Battle-tested at AWS scale (AWS Lambda, Fargate).^[2]

Kubernetes-native VM isolation → Kata Containers. Drop-in OCI runtime for Kubernetes; confidential computing included.^[8]

Defense-in-depth without full VMs, or GPU sandboxing → gVisor. What Google runs; nvproxy is the most mature GPU sandbox path.^[7]

Containers on a Mac with real isolation → Apple Containerization. v1.0, sub-second starts, free.^[6]

Embedding VM isolation in your own tool → libkrun. A library, not a platform — by design.^[5]

Enterprise K8s isolation with GPUs → Edera. Funded, commercial, hardware-isolated GPU sharing.^[9]

Docker-like simplicity with VM isolation → Hypeman. Highest DX, multi-hypervisor, early-stage.^[11]

Minimal attack surface → Unikraft. Smallest images, fastest boot, specialized tooling.^[10]

A modern VMM to build on → Cloud Hypervisor. Clean Rust codebase, GitHub-governed under the Linux Foundation, GPU passthrough.^[4]

---

See Also

• AI Agent Sandboxes Compared — higher-level sandbox platforms (E2B and friends) built on these runtimes
• Watchlist: Kuasar (CNCF multi-sandbox runtime), StratoVirt (openEuler), Microsandbox (self-hosted, libkrun-based — covered with the sandbox platforms)

---

Research by Ry Walker Research · methodology