AI
The Isolation Gap Containers Cannot Close
Containers are fast and easy to use, but fall short for multi-tenancy and AI sandboxing where strong isolation matters. VM-level isolation closes that gap but costs performance. Urunc targets both problems at once. It is a CRI-compatible runtime, so it plugs into existing Kubernetes deployments without changes to the surrounding tooling. Its focus is single-application workloads packaged as unikernels or single-application kernels, where the application ships alongside its own kernel.
How Urunc Handles Trusted and Untrusted Containers Differently
Inside a Kubernetes pod, urunc separates sidecar containers from user containers. Sidecars run as normal containers. User containers, the ones the platform cannot vouch for, land inside a secure sandbox. That sandbox is either a software-based option like gVisor or a full virtual machine. The application runs as the init process inside the VM. No agent sits inside the sandbox, which keeps the guest footprint minimal and removes a class of privilege-escalation surface.
Boot Overhead: 20% vs 2x
Cold-boot benchmarks use runc as the baseline. Other sandbox container runtimes measured roughly 2x overhead on startup. Urunc came in at 20% to 28% overhead, depending on which guest and monitor combination was used. That gap matters for workloads that spin up frequently, such as serverless functions or CI jobs. The result holds across the unikernel configurations Mainas tested, making urunc competitive with plain containers on latency-sensitive paths while still providing VM-grade isolation.
Density on a Raspberry Pi
A density test on a Raspberry Pi with 8 GB of RAM pushed each runtime to its pod limit. Runc reached 467 pods. Urunc hit 430, all sandboxed. Kata stopped at 302. gVisor capped at 170. One urunc configuration landed at 130 pods because of QEMU and Linux overhead in that specific monitor and guest pairing. For resource-constrained environments, urunc’s numbers show that sandboxed execution does not have to mean a steep pod-count penalty.
Target Workloads and Community
Urunc fits scenarios that combine fast spawn times with isolation requirements: microservices, serverless, AI agent sandboxing, CI/CD test environments, and resource-constrained deployments. It also supports BSD workloads. The project holds community meetings on the last Wednesday of each month. The project pavilion kiosk at KubeCon is 24B, open Wednesday between 10:00 and 13:30. The GitHub repository, documentation site, and CNCF Slack channel carry further details for contributors and users.
Notable Quotes
we have an overhead of around 20% or 28% uh depending on which kind of guest and monitor we’re going to use. Charalampos Mainas · ▶ 02:56
with URNC uh we were able to run as many as 430. Charalampos Mainas · ▶ 03:25
ur doesn’t have any requirement inside the sandbox for any agent or anything like that. Charalampos Mainas · ▶ 02:28
Key Takeaways
- Urunc adds 20-28% cold-boot overhead versus runc, compared to 2x for other sandbox runtimes.
- A Raspberry Pi density test showed 430 sandboxed urunc pods against Kata’s 302 and gVisor’s 170.
- No in-guest agent is required; the application runs as the VM init process.
About the Speaker(s)
Charalampos Mainas is a systems software engineer focused on virtualization technologies and operating systems. He is one of the creators and maintainers of urunc, a sandboxed container runtime for unikernels and single-application kernels.