At QCon London 2026, Unikraft CEO and co-founder Felipe Huici argued that the AI infrastructure “scale problem” can be tackled by combining strong isolation with extreme density, fast cold boots and scale-to-zero behavior. His pitch was blunt: if workloads can be resumed in milliseconds and kept stateful, a single server can host vastly more sandboxes than conventional setups.
Why Unikraft is aiming at AI sandboxes
Huici’s talk, titled Fixing the AI Infra Scale Problem by Stuffing 1M Sandboxes in a Single Server, focused on the infrastructure behind modern AI agents and other bursty workloads. He said the industry now uses “sandboxes” for much more than their older container-era meaning, with the term increasingly tied to AI systems that need to run code, browse the web, and interact with tools while remaining isolated.
The central claim was that AI infrastructure does not have to choose between speed, security and scale. Instead, Huici said, the goal is to engineer a platform that can start quickly, preserve state when idle, and shut down unused workloads without users noticing the interruption.
From isolation soup to a cloud platform
Huici opened with a tour of the different isolation primitives people often lump together: containers, virtual machines, microVMs, unikernels and runtime-level isolates. He described the cloud stack as “isolation soup,” with many systems mixing layers to get a practical balance of performance and security.
He contrasted the main models this way:
- Virtual machines run with a hypervisor and separate guest OS instances.
- MicroVMs are still VMs, but launched by lightweight VMMs such as Firecracker.
- Unikernels keep the VM model but combine the application with a custom operating system built for that workload.
- Containers share the host OS kernel and rely on a container runtime for isolation.
- Runtime isolates use a language runtime such as Node or the JVM to separate applications at the process level.
Huici’s argument was that VMs remain the “golden standard” for cloud isolation because they keep the trusted computing base smaller than approaches that rely on the host kernel or language runtime for separation.
Security, performance and the trusted computing base
A major theme in the presentation was the trusted computing base, which Huici described as the stack of code that all workloads depend on for security. In his framing, VMs concentrate that shared base in the hypervisor, while containers and runtime-based models inherit the host OS or runtime as part of the common layer.
He also noted that layering isolation on top of isolation can become wasteful if it only adds overhead. That is why, in his view, the challenge is not whether VMs are secure, but whether they can be made efficient enough to support modern, dense, on-demand systems.
Millisecond boot times and stateful scale-to-zero
Huici traced the technical roots of Unikraft back to earlier work on ClickOS and lightweight virtualization for network functions. Those systems demonstrated that custom VM images could boot in a few milliseconds and run at high throughput, and later work extended the idea into a broader open source project under the Linux Foundation.
The current platform, he said, is designed around four requirements:
- strong isolation for all workloads
- very fast startup times
- stateful resume from where a workload left off
- high server density
Huici said the team first tried a Dockerfile-based flow on AWS and saw startup times closer to 30 seconds than the 10 milliseconds they had achieved locally. That mismatch pushed the company to optimize not just the VM image, but the surrounding system: load balancer, proxy, controller, VMM and snapshot pipeline.
Snapshots as the key to hiding startup cost
One of the most important tools in the system is snapshotting. Huici explained that a snapshot captures a running VM’s memory state, allowing the platform to preserve an initialized workload and resume it later from that point.
That approach enables several behaviors at once: stateful scale-to-zero, fast wake-up, forking, checkpointing and live migration. It also lets the platform mask application startup costs, so a workload that might take seconds or minutes to initialize can be resumed in around 10 milliseconds from a prebuilt snapshot.
To support this, Unikraft also uses compressed and differential snapshots, along with storage and memory-management techniques intended to keep the approach practical at very large scale.
What “1 million sandboxes” actually means
The headline number in Huici’s talk was the ability to place roughly 1 million scale-to-zero VMs on a single server. He said the system can keep idle workloads parked with negligible CPU use, while maintaining metadata for sleeping VMs in the controller and storing snapshots on fast NVMe-based storage.
Huici said the team hit several scaling bottlenecks while pushing the system upward, including Linux TAP-device limits, kernel lock contention, NTP and SSH issues, bridge port limits and IPv6 lock contention. Those were addressed with a series of engineering changes, including shared-memory communication between components instead of network protocols.
His slides and demo suggested that the platform can keep cold boots around 10 milliseconds even as the number of sleeping VMs grows to 100,000 and beyond, with CPU usage near zero for idle instances and storage costs rising linearly with snapshot count.
Use cases: from Chromium to AI agents
Huici said the most obvious applications are workloads that are frequently idle but need to wake quickly. He highlighted headless browsers such as Chromium, which can take 30 seconds or more to start and are expensive to keep resident in memory.
He also pointed to functions, build and test environments, and AI sandboxes. In those scenarios, fast cold starts and stateful resume matter because the workload is often intermittent, but the user still expects continuity when it wakes back up.
During the demo, he showed nginx instances scaling to zero and then resuming on demand. He also demonstrated OpenClaw sandboxes, with each sandbox running in its own VM and being activated briefly for a task before returning to standby.
Working with Kubernetes instead of against it
Rather than replace Kubernetes, Unikraft is designed to integrate with it. Huici said the team built a virtual kubelet that lets Kubernetes schedule pods as usual, while the platform maps those pods to microVMs underneath. Kubernetes is told the pod is running, even if the workload is actually being parked and resumed in milliseconds.
That lets teams keep familiar tooling and operational patterns while still gaining the startup and density properties of the Unikraft stack.
What the talk says about the next phase of AI infra
Huici’s broader message was that cloud infrastructure no longer has to force a trade-off between speed, scale and strong isolation. With enough attention to the full stack, he argued, teams can keep security high, resume workloads quickly and pack far more of them onto one machine.
For AI systems in particular, that matters because agents and browser-based tools are increasingly expected to behave like short-lived services that retain memory, not disposable processes that start from scratch every time. Huici’s answer is a platform built around virtual machines, snapshots and scale-to-zero semantics rather than a container-only model.
Source: Original report
Was this helpful?
Explore more: DevOps Services More Cloud & DevOps Tech News
Last Modified: September 9, 2026 at 10:33 pm
0 views
