// the find
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.
Hyperlight is a Rust library for embedding hypervisor-backed micro VMs directly in your process, so you can run untrusted code with real VM isolation instead of just a process sandbox. It's aimed at teams building FaaS-style or plugin-execution systems who need per-call isolation with startup times in milliseconds and call overhead in microseconds, not people who need a general-purpose VM.
Backend abstraction over KVM, MSHV, and WHP means you're not locked into one hypervisor or OS. Dropping the guest kernel/OS entirely is what actually gets startup into the millisecond range and calls into microseconds — that's a real architectural choice, not a marketing number. snapshot()/restore() lets you reuse a warm VM across calls instead of paying VM creation cost every time, which matters a lot for FaaS-shaped workloads. It's a CNCF sandbox project with a real ecosystem around it (hyperlight-wasm, hyperlight-js, cargo-hyperlight, hyperlight-unikraft), so it's not a single maintainer's side project — there's investment in making it usable for more than the Rust-only case.
It's explicitly pre-1.0 with a stated API-breaking-changes-between-releases policy, so anyone adopting it now is signing up for churn, not a stable dependency. Guests have to be purpose-built no_std Rust or C binaries against the Hyperlight guest library — you can't just point it at an arbitrary existing binary or interpreter, which cuts against the 'run untrusted code' pitch unless you're willing to build guest-side tooling (hence the separate hyperlight-wasm/js/unikraft projects to paper over this). No filesystem or network access by default means every real capability the guest needs has to be hand-wired as a host function, so integration effort scales with how much the untrusted code actually needs to do. It's young, security-critical isolation infrastructure — there's fuzzing in the repo, but the hypervisor boundary and guest runtime haven't had the years of adversarial scrutiny that something like gVisor or Firecracker has, so I'd want a real security review before trusting it as the only isolation layer for hostile input.