Unikraft Fits 1,024,132 Firecracker VMs on One 48-Core Server

Running a million virtual machines on a single 48-core server is not a thought experiment — it is a live demo that Unikraft CEO Felipe Huici walked through at QCon London, showing instance 1,111,111 serving an nginx response while 1,024,132 sibling VMs sat in compressed, stateful scale-to-zero sleep. The architecture underneath that demo has direct implications for anyone building AI sandbox infrastructure, where per-tenant isolation, cold-start latency, and server economics are simultaneously in conflict.

Isolation Primitives: Why VMs Win

Huici's argument is anchored in trusted computing base (TCB) size. A hypervisor-based VM stack shares only the hypervisor across tenants — a comparatively small, auditable codebase. A container stack exposes the entire Linux host kernel, tens of millions of lines of code, as the shared layer. Nesting containers inside VMs restores the hypervisor TCB because the shared layer is again just the hypervisor; every VM retains its own kernel and runtime. Language-level isolates accumulate the host OS plus the entire language runtime as their TCB. Huici's summary: "containers don't contain, isolates don't isolate" — making VMs the cloud's standard for multi-tenant security, a position directly relevant to infrastructure governance and safe agent deployment.

The unikernel refinement strips the guest OS to only the components a specific application actually needs, merging application binary and custom kernel into a single image. Unikraft's open-source SDK, a Linux Foundation project seven years in development, automates that specialization: a CLI ingests a Dockerfile, extracts the filesystem and binary, and emits a VM image that boots via Firecracker.

The Cold-Start Chain and the Snapshot Trick

A fast image alone does not produce a fast service. An initial AWS test produced 30-second cold starts despite sub-10 ms local boot times. The latency lived in the surrounding chain — load balancer, proxy, controller, VMM — not the image itself. Unikraft rebuilt each component with shared-memory inter-process communication rather than network protocols, and switched from QEMU and Intel Cloud Hypervisor — which introduced CPU jitter at thousands-of-VM scale — to Firecracker exclusively.

Application startup is a separate problem. A JVM or a Chromium instance can take seconds or minutes to initialize. Unikraft's solution is pre-initialized snapshots: the application starts once at CI/CD release time, completes full initialization, and is then snapshotted via Firecracker's REST API at the ready-to-serve moment. Subsequent cold starts resume from that snapshot in approximately 10 milliseconds, completely masking initialization cost. Snapshots also enable stateful scale-to-zero (resuming with preserved session state), VM forking for sub-agent creation, checkpointing for state rollback, and live migration.

Density Engineering: Getting to One Million

The path from 5,000 to 1,000,000 scale-to-zero VMs on one server required fixing a cascade of Linux host-level bottlenecks:

Reaching one million instances requires approximately 12 terabytes of NVMe storage. Most servers ship with two 2-terabyte NVMe drives at minimum, with expansion possible. Cold-boot latency measured across 100,000 VMs holds at approximately 10 milliseconds and remains essentially flat as concurrency scales, with time-to-first-packet slightly higher but still consistent. This kind of architectural specificity outperforming raw hardware scaling is precisely what the density numbers illustrate.

Kubernetes Integration

Rather than replacing Kubernetes, Unikraft implements a virtual kubelet that registers as a standard node in an existing cluster. Kubernetes schedules pods against it using the normal pod scheduling API; the kubelet translates each pod request into a Firecracker microVM launch instead of a container. Kubernetes continuously receives "running" status responses, while the underlying VM oscillates between active and scale-to-zero states. If the VM can respond within the millisecond window, the control plane never observes the difference. The team evaluated KubeVirt and rejected it after profiling identified compounding latency contributions. CNI plugins are supported as an optional side attachment for customers requiring them.

For headless browser fleets — the standard workhorse for web-browsing AI agents — the economics are stark: Chromium can require 4 to 16 GB of RAM per instance and 30 seconds to a minute to cold-start, making always-on fleets the only viable option today. Unikraft's 10-millisecond resume allows headless browser instances to sleep between agent invocations rather than consuming memory continuously.

The AI sandbox market is converging on a constraint set — strong hardware-level isolation, sub-second resume, stateful persistence, and server density measured in hundreds of thousands per node — that container runtimes were never designed to satisfy simultaneously. Unikraft's approach, grounded in seven years of unikernel and microVM research, is a structural bet that systems-engineering depth rivals scaling through hardware acquisition alone. Platform engineers evaluating sandbox infrastructure for agentic workloads now have a concrete reference architecture with measured numbers attached.