Hyperlight sandboxes your Python in a micro-VM that restores in 3 ms, no recompile

Restoring a micro-VM with Python already warmed up takes about 3 ms with hyperlight-unikraft, the newest piece of Hyperlight, the virtual machine monitor that is a CNCF Sandbox project. Until now, Hyperlight only accepted guests built specifically for it. It now runs the same Python, Node.js, .NET, Java or Go binary you run on Linux, with no SDK and no recompiling. The team presented it on the CNCF blog on November 9, 2026.

This matters because more and more of the code we run was written by nobody on the team: Python generated by an agent, a customer's plugin, a UDF uploaded by a user. A process sandbox starts fast, but a bug in the runtime or the shared kernel hands the attacker the host. A VM puts a hypervisor in the way, but booting one takes hundreds of milliseconds. hyperlight-unikraft aims for VM isolation at process latency.

01What's inside

Hyperlight is a Rust library (with Python and .NET SDKs) that your application links in, not a separate VMM process. It uses KVM or MSHV on Linux, WHP on Windows and Hypervisor.framework on Apple silicon Macs. The micro-VM emulates no devices: the guest can only reach the host through functions the host chooses to expose.

hyperlight-unikraft adds a Unikraft kernel as the guest OS: a unikernel with a single address space and only the components the application needs. On top sits a rootfs with the runtime (about 14 MB for Python) and a small per-language driver that gets the interpreter ready and waits.

The trick is the snapshot. The first run boots the guest, initializes the runtime and saves its state; every later run restores it instead of booting. With warm_exec you can bake expensive imports into the snapshot (import flask, pandas) so you stop paying for them on every call.

The team's numbers (median, process start included, hluk 0.20.1, on an 8-vCPU Azure VM with nested KVM):

On hello world the micro-VM is slower than a native process, as you'd expect. The win shows up when the runtime is slow to start: the snapshot skips work the native process redoes on every run. On the same machine, eight micro-VMs sharing one Python snapshot served about 850 calls per second between them.

02Security: nothing by default

The guest sees no host files and has no network until you grant them: --mount opens a directory, --net turns on networking (with --net-allow and --net-block lists) and --port lets it listen. In a WasmCon 2026 talk the team ran an exploit for a since-fixed Wasmtime bug (CVE-2023-26489): run directly on the host, it read the process's secrets; inside hyperlight-unikraft it could only reach the micro-VM's own memory.

03Trying it out

The README suggests an install script. It's a curl | sh, so read it first or use the Rust route:

# Linux (KVM) or Apple silicon macOS
curl -fsSL https://raw.githubusercontent.com/hyperlight-dev/hyperlight-unikraft/main/install.sh | sh
# or, with a Rust toolchain
cargo install hyperlight-unikraft

hluk init hello --template python   # writes hluk.toml and main.py, pulls the rootfs
cd hello
hluk run   # boots the guest and saves the snapshot
hluk run   # restores the snapshot: milliseconds

hluk templates lists the rest: Node.js, Bash, C#, Java, PHP, PowerShell, compiled Go, Rust or C programs, HTTP servers on a rootfs extended through a Dockerfile, and an agent image with numpy, pandas, scipy and scikit-learn preloaded.

The fastest way to feel the difference is through the integrations already on PyPI:

• mcp-server-hyperlight: an MCP server whose run_python tool keeps state between calls. In Claude Code: claude mcp add hyperlight -- uvx mcp-server-hyperlight.
• smolagents-hyperlight and openai-agents-hyperlight: run an agent's code or shell commands in a micro-VM with no network unless you allow it.
• clickhouse-hyperlight: Python UDFs for ClickHouse that restore one micro-VM per block of rows in about 1.5 ms.

For Kubernetes, urunc runs the guests as OCI containers under containerd with a RuntimeClass, no privileged containers required.

04Versus Firecracker

The reference point for micro-VMs is Firecracker, the VMM that container runtimes such as Kata Containers build on. The two attack the same problem from different ends:

The 3 ms and the 125 ms measure different things: one restores saved state, the other boots from scratch. The real difference is the model. Firecracker gives you a full Linux VM with virtio networking and disks, a good fit for long-running, multi-tenant workloads. hyperlight-unikraft gives you an isolated function you call from your own code thousands of times, a good fit for running snippets you don't control.

05The caveat that matters

The guest is not Linux: it's a unikernel that mimics Linux's interface. The manifest docs are explicit that binaries must be position-independent and must not call fork(). Any program or library that forks will fail where it would work in a container. Before you put this in front of an agent in production, test your real workloads on the image you'll ship, not a hello world. And the performance figures come from a single machine running nested virtualization.

If you already run agent-generated code in plain containers, mcp-server-hyperlight is the cheapest way to try hypervisor isolation without touching your architecture.

06Sources

• Run Linux applications in hypervisor-isolated micro-VMs with Hyperlight, CNCF, November 9, 2026.
• hyperlight-dev/hyperlight-unikraft, README.
• Projects and the manifest, hyperlight-unikraft docs.
• firecracker-microvm/firecracker, README.
• Firecracker, project site.