# Hyperlight: a VMM you embed to run untrusted code in micro VMs

> Hyperlight is a Rust library that creates hypervisor-isolated micro VMs with no guest kernel, so you can call guest functions across the VM boundary like local ones. It is pre-1.0, and the README says upgrades will sometimes require code changes.

**hyperlight-dev/hyperlight** — Hyperlight is a lightweight Virtual Machine Manager (VMM) designed to be embedded within applications. It enables safe execution of untrusted code within micro virtual machines with very low latency and minimal overhead.

- Repository: https://github.com/hyperlight-dev/hyperlight
- Website: https://hyperlight.org
- Stars: 4,699 · Forks: 215
- Language: Rust
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/hyperlight-dev-hyperlight

## What Hyperlight actually solves for a Rust host

Most sandboxing choices force a trade. A container shares the host kernel, so a kernel bug is a host bug. A general-purpose VM gives you hypervisor isolation but wants a guest kernel, a boot sequence and hundreds of milliseconds before your code runs. Hyperlight takes the third position: the isolation boundary is the hypervisor, and there is no guest kernel or OS at all. The README states that micro VMs spin up in milliseconds and that guest function calls complete in microseconds.

The intended user is a Rust application author who has to execute code they do not trust, and who wants that execution to look like a function call rather than a process launch. The README lists functions-as-a-service with hypervisor-level isolation, embedding sandboxed execution directly in an application, and reusing sandboxes through snapshot and restore. It also names the cases it is not built for: general-purpose virtualization, and full Linux guest workloads that need syscalls, networking or filesystem access.

## No kernel in the VM: how the host and guest talk

The mechanism follows from the missing kernel. Guests are regular ELF binaries written in no_std Rust or C, built against a Hyperlight guest library rather than a libc-and-syscall model. The repository splits that library in two: src/hyperlight_guest holds the minimal building blocks for guest-host interaction, while src/hyperlight_guest_bin adds the entry point, panic handler, heap, logging and exceptions. src/hyperlight_libc provides a C standard library for guests built from picolibc, and src/hyperlight_guest_capi wraps the extended guest library for FFI callers.

The communication path is typed function calls in both directions. On the guest side, macros from src/hyperlight_guest_macro register functions; on the host side, the host library in src/hyperlight_host creates and manages the micro VM. A FlatBuffer schema under src/schema defines the wire format. Sandboxing is the default rather than an opt-in: guests have no access to the host filesystem or network unless the host registers a function that provides it.

Two design details matter for how you structure an application. Guest state persists across calls, so a sandbox is not stateless by default. The README points to snapshot() and restore() for saving and resetting VM memory, which lets you avoid recreating the VM while still starting each call from a clean state. That is the intended pattern for reuse, and it is the part of the API most likely to shape your architecture.

## Installing Hyperlight and making a first guest call

The README does not give a cargo add line; it points to docs/getting-started.md for detailed prerequisites and platform-specific setup, split into running Hyperlight and building guests. It also offers a GitHub Codespaces link for skipping local setup. What the repository does pin down is the toolchain: the workspace Cargo.toml sets edition 2024 and rust-version 1.89, and the workspace version is 0.17.0.

The host side builds a sandbox from a guest binary and registers a host function the guest can call. The README gives this example, and notes that by default guests can only print to the host:

```rust
let mut sandbox = SandboxBuilder::from_file(guest_path)
    .host_function("GetWeekday", || Ok("Monday".to_string()))
    .build()?;

let greeting: String = sandbox.call("SayHello", "World".to_string())?;
println!("{greeting}"); // "Hello, World! Today is Monday."
```

The guest side declares the host function it depends on and exposes the function the host will call. Both are registered by attribute macro:

```rust
#[host_function("GetWeekday")]
fn get_weekday() -> Result<String>;

#[guest_function("SayHello")]
fn say_hello(name: String) -> Result<String> {
    let weekday = get_weekday()?;
    Ok(format!("Hello, {name}! Today is {weekday}."))
}
```

The names in the two attribute macros are the contract between the two binaries, so a typo on either side is a runtime failure rather than a compile error. For building the guest itself, the README points to docs/how-to-build-a-hyperlight-guest-binary.md, and the separate cargo-hyperlight subcommand is listed as a Cargo subcommand for building and scaffolding guests. Note that the workspace excludes src/tests/rust_guests because guests have custom linker flags and live in their own nested workspace; a guest is not simply another crate in your host workspace.

## Where Hyperlight is the wrong tool

The README is unusually direct about the boundary. If your guest needs syscalls, networking or filesystem access, Hyperlight is not the answer, because there is no kernel to service them. The escape hatch is a host function: anything the guest needs from the outside world has to be a typed call you write and register. That is a real cost. A workload that reads files, opens sockets and spawns threads is not a Hyperlight guest, and no amount of configuration makes it one.

The second limitation is API stability. The README carries an explicit status note: Hyperlight is pre-1.0, the API may change between releases, and upgrading will sometimes require code changes. The release history is consistent with that, with v0.17.0 following v0.16.0 and a dev-latest prerelease published from main. Treat the version in your Cargo.toml as something you will revisit, not something you set once.

The third is platform coupling. Hypervisor support is KVM, MSHV and Windows Hypervisor Platform. That is a narrower set than a container runtime, and the getting-started guide is where the per-platform prerequisites live. If your deployment target is not one of those three, the material offers no path.

## Hyperlight compared with running WebAssembly in a runtime

The obvious alternative for executing untrusted code inside an application is a WebAssembly runtime with a capability-based host interface. The difference is the isolation boundary. A Wasm runtime isolates at the language and memory level and relies on the correctness of its own compiler and validator; Hyperlight isolates with the hypervisor, so a bug in the guest's compiled code still has to escape a VM boundary. Hyperlight also gives the guest real machine-level execution rather than a Wasm instruction set, which matters when the code you are running was compiled for your architecture and not for a portable bytecode.

That said, the project does not treat the two as mutually exclusive. hyperlight-wasm is listed as a related project for running WebAssembly modules inside Hyperlight micro VMs, and hyperlight-js does the same for JavaScript. If you want Wasm's portability and tooling but a stronger boundary underneath, that layering is the intended combination rather than a contradiction. The other related projects point at the same idea from different angles: hyperlight-sandbox is a multi-backend sandboxing framework with Python, .NET and Rust SDKs, and hyperlight-unikraft runs Linux applications such as Python, Node.js, Go, Rust and C/C++ on Hyperlight micro VMs using Unikraft as the guest kernel. That last one is the direct answer for anyone who needs a real kernel in the guest.

## Maintenance, versioning and the licence

The repository is not archived, and the last push was on 2026-09-22, so the codebase is being worked on now. That says nothing about API stability, which the README handles separately with its pre-1.0 note. The practical upgrade cost is the one the README names: code changes on some upgrades. Pin the version, read CHANGELOG.md before moving, and expect the guest and host crates to move together, since the workspace sets every hyperlight-* dependency to the same 0.17.0 version and the attribute macro names form a contract between the two sides.

Licensing is Apache-2.0, declared in the workspace Cargo.toml and shipped as LICENSE.txt, with NOTICE.txt alongside it. Apache-2.0 includes an express patent grant and requires that notices be preserved. The repository also carries a SECURITY.md, a GOVERNANCE.md, a MAINTAINERS.md and a SUPPORT.md, and the README identifies Hyperlight as a Cloud Native Computing Foundation sandbox project with a CNCF Code of Conduct. For a sandbox-stage CNCF project, the governance files are worth reading before you depend on the project's direction. None of this is legal advice; check the licence text against how you intend to distribute.

## Conclusion

Adopt Hyperlight if you are writing a Rust host that must execute third-party or user-supplied code with hypervisor isolation and cannot pay the cost of a general-purpose VM. Do not adopt it if your workload needs syscalls, a network stack or a filesystem inside the guest, or if you need a stable API today: the README states the API may change between releases and that upgrading will sometimes require code changes. Before committing, verify that your target platform is covered by the KVM, MSHV or Windows Hypervisor Platform backends, and read docs/getting-started.md for the prerequisites of both running Hyperlight and building guests.

## FAQ

### What is Hyperlight?

Hyperlight is a lightweight Virtual Machine Manager designed to be embedded within applications, built to run untrusted code inside hypervisor-isolated micro VMs with no guest kernel or OS. You embed it as a library in a Rust application, hand it a guest binary, and call functions across the VM boundary.

### How do I install Hyperlight?

The README does not give a package install line. It points to docs/getting-started.md for detailed prerequisites and platform-specific setup for running Hyperlight and for building guests, and offers a GitHub Codespaces link for skipping local setup.

### Does Hyperlight run a Linux guest?

Not by itself. There is no guest kernel or OS, and guests are no_std Rust or C ELF binaries built against the Hyperlight guest library. The README lists full Linux guest workloads that need syscalls, networking or filesystem access as a case Hyperlight is not designed for; the separate hyperlight-unikraft project uses Unikraft as a guest kernel for that.

### Which hypervisors does Hyperlight support?

The README lists KVM, MSHV and Windows Hypervisor Platform. Platform-specific prerequisites are covered in docs/getting-started.md.

### Is the Hyperlight API stable?

No. The README states that Hyperlight is pre-1.0, that the API may change between releases, and that upgrading will sometimes require code changes.

### What licence is Hyperlight under?

Apache-2.0, declared in the workspace Cargo.toml and shipped as LICENSE.txt with a NOTICE.txt. The README also identifies the project as a Cloud Native Computing Foundation sandbox project.

## Sources

- [hyperlight-dev/hyperlight on GitHub](https://github.com/hyperlight-dev/hyperlight)
- [License: Apache-2.0](https://github.com/hyperlight-dev/hyperlight/blob/main/LICENSE)
- [Project website](https://hyperlight.org)
- [README](https://github.com/hyperlight-dev/hyperlight/blob/main/README.md)
- [Releases](https://github.com/hyperlight-dev/hyperlight/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hyperlight-dev-hyperlight