Run Linux applications in hypervisor-isolated micro-VMs with Hyperlight

Posted on November 9, 2026 by Danilo Chiarlone, Microsoft

CNCF projects highlighted in this post

More and more cloud native systems run code nobody on the team wrote: the Python an AI agent generated a second ago, or a plugin a customer just uploaded. Each of them needs a boundary between that code and everything else on the host.

Two recent attacks show what happens when that boundary is thin. In May 2026, the Mini Shai-Hulud npm worm ran in CI runners and on developer machines, read more than a thousand known credential locations, and hid in AI coding agents’ session hooks so it outlived even npm uninstall. In October 2026, PHP2Shell, a pair of memory-handling bugs in the PHP runtime itself, could let unauthenticated attackers run code on servers, with exploit attempts seen before the patch was out. Either the code or the runtime under it can be the thing that breaks, and what decides how much damage that does is how far the broken code can reach.

The usual choices trade one property for another. A process or language sandbox starts in milliseconds, but only software stands between the code and the host: one bug in the sandbox, or in the kernel it shares with the host, and the code is out. A virtual machine puts the hypervisor in the way, but it was built to boot a whole operating system, and it takes time to start. Hyperlight, a CNCF Sandbox project, can help to close that gap. This post covers how it does it, what changed as it learned to run unmodified Linux applications (the same binaries you run on Linux today, with no porting or recompiling), and the integrations that now use it, from a Kubernetes container runtime to agent frameworks and a database.

A VMM you embed

Hyperlight is a library virtual machine monitor (VMM). It does not run as a separate process the way QEMU or Firecracker do: an application links it in. The core is written in Rust, with SDKs for Python and .NET. The application asks Hyperlight for a sandbox, and Hyperlight creates it as a micro-VM with its own memory, isolated by the CPU’s virtualization extensions through the host’s hypervisor: KVM or MSHV on Linux, WHP on Windows, Hypervisor.framework on macOS.

A Hyperlight micro-VM carries no emulated devices and nothing else it does not need. The guest reaches the host only through the functions the host chooses to expose. What a sandbox can touch is capability-based: an allow-list the embedder writes, with no preset of permissions someone has to remember to take away.

You may know Hyperlight from running WebAssembly and JavaScript through hyperlight-wasm and hyperlight-js, whose guests are built for Hyperlight. This post is about the newest member of the family, hyperlight-unikraft, which runs unmodified Linux programs.

Unmodified Linux applications

hyperlight-unikraft (its CLI is hluk) runs a unikernel in the micro-VM: an operating system built for one application, with one address space and only the kernel components that application needs, such as a memory allocator, a scheduler or a file system. The kernel comes from Unikraft, a Linux Foundation project. The guest runs the same binary Linux would. There is no SDK, no special libc and no recompile.

Today hyperlight-unikraft runs Python, Node.js, .NET (JIT and Native AOT), Java, PHP, Go, Rust, C, Bash and PowerShell, on both x86_64 and arm64.

Each runtime ships as a base rootfs, and a project can extend the base rootfs with an ordinary Dockerfile, adding packages with pip, npm or the .NET SDK. hluk build turns the result into a guest image. A Python guest that has network access can also pip install on demand.

Because the guest runs ordinary Linux binaries, it can also run another sandbox, such as the Wasmtime WebAssembly runtime, and contain it when it fails. In a WasmCon 2026 talk, the Hyperlight team showed an exploit for a since-fixed Wasmtime bug (CVE-2023-26489) that lets WebAssembly code read memory outside its sandbox. Run directly on the host, the exploit read secrets from the host process. Run inside hyperlight-unikraft, it could only reach the micro-VM’s own memory, and the host’s secrets stayed out of reach. The exploit and the demo are on GitHub. The hypervisor boundary turns a sandbox escape into a crashed guest.

Often faster than native, with snapshots of a ready runtime

Startup delays in a Python, Node.js, or .NET program are rarely caused by the operating system. They come from what the language runtime does before your code runs: importing modules, JIT-compiling, loading a framework. hyperlight-unikraft does that work once, snapshots the micro-VM at that point, and restores it in milliseconds. For a runtime with heavy startup work, a hypervisor-isolated sandbox is ready sooner than the same program started natively on the host.

Each runtime image has a small driver that starts the runtime and then waits for calls from the host. When the driver is parked, the runtime is fully up and idle, and that is where hluk takes its snapshot. A project can add its own warm-up code (warm_exec = “import flask, pandas”), so the snapshot holds the libraries it uses. Later runs restore that snapshot in a few milliseconds instead of booting.

The speed-up depends on how much work the runtime does up front. These are median wall times for the same script on one machine (an 8-vCPU Azure VM running KVM under nested virtualization, hluk 0.20.1, November 2026), both sides including process start (benchmark harness on GitHub):

For a hello world the fixed costs dominate, and the micro-VM is slower. Once a runtime does real work before your code, restoring that work beats redoing it. Some runtimes have their own answers to this, such as V8 startup snapshots or Java’s CRaC. A VM snapshot is one mechanism that works the same way for every runtime, and the sandbox it restores is still isolated by the hypervisor. Because a restore is cheap, many micro-VMs can run at once from one snapshot: on the same machine, eight sharing a single Python snapshot served about 850 calls a second between them, each restoring in a few milliseconds.

Where it plugs in

You can use hyperlight-unikraft through the hluk CLI or embed it as a Rust library. A sandbox boots from a rootfs or a saved snapshot, with mounts and network rules declared up front:

let mut sandbox = SandboxBuilder::from_snapshot_dir(cached)?
    .mount(Mount::ro("./data", "/mnt/data"))
    .network(NetworkPolicy::AllowAll)
    .listen_ports(ListenPorts::from_ports([8080]))
    .boot()?;                                   // restores in ~3 ms

sandbox.run("print(open('/mnt/data/x.csv').read())")?;

Nothing is granted by default: the guest has no network and sees no host files until the embedder adds a capability for it, the way the mount and network rules above do.

Integrations across the ecosystem

Over the last few months, hyperlight-unikraft became the base for integrations in several ecosystems:

A few of these show the snapshot model doing different jobs.

Kubernetes. With urunc, a hyperlight-unikraft guest ships as an ordinary container image, so Kubernetes can run it like any other pod. The image can also carry the warm snapshot, so the container resumes instead of booting. No privileged containers are needed.

Agents. Agent frameworks generate code and run it, often step by step with state carried between steps. The smolagents executor and the MCP server keep one micro-VM per session, talk to it over its console rather than a network, and replace it with a fresh copy of the warm snapshot when asked.

Databases. In ClickHouse, any user allowed to run CREATE FUNCTION can write a Python UDF without that code running on the server itself. Each block of rows starts from the function’s snapshot, restored in a few milliseconds, so one query cannot leave anything behind in the guest for the next one to find, even if a different user runs it.

Model training. Reinforcement learning on code scores a model by running its solutions against test cases, many thousands of times. verl-hyperlight runs each case from a warm snapshot on the training node, with no network or view of the host.

In each case Hyperlight sits underneath what is already there, a container runtime, an agent framework or a database, rather than replacing it. The code inside the sandbox is the code we started with: generated by an agent or uploaded by a stranger, now behind a hypervisor boundary and starting from a warm snapshot.

Try it

On a Linux host with KVM or a Mac on Apple silicon, two commands get you a project (Windows uses install.ps1 instead):

curl -fsSL https://raw.githubusercontent.com/hyperlight-dev/hyperlight-unikraft/main/install.sh | sh
hluk init hello --template python

hluk init writes a manifest and a main.py, and pulls a 14 MB Python rootfs. The first hluk run boots the guest and saves a snapshot; the second restores it in about 3 ms. Templates cover the other runtimes too.

The interesting question is no longer whether Hyperlight can run your code. It is what you would build if VM isolation cost a few milliseconds. If you try it in a project, or hit something that does not fit, open an issue or a pull request; we would like to hear about it.

Hyperlight is a CNCF Sandbox project; issues, pull requests and integrations are welcome at github.com/hyperlight-dev.