← Back to research
·10 min read·opensource

libkrun

libkrun is a Red Hat-backed, Rust dynamic library that lets any process embed a KVM (Linux) or Hypervisor.framework (macOS) microVM — powering podman machine's GPU-enabled macOS provider (krunkit), crun's krun handler, and the YC-backed Microsandbox AI sandbox with sub-200ms boots.

https://github.com/libkrun/libkrun ↗
container-vm-runtimesopen-sourcerust

Key takeaways

  • Library, not VMM product — libkrun is a dynamic library with a C API that any process links to spawn a microVM, the inverse of Firecracker's standalone-binary model; it powers krunkit (podman machine on macOS), crun's krun handler, muvm, and Microsandbox
  • Only container-VM runtime with a production GPU path on macOS — its virtio-gpu/Venus (Vulkan) device delivered an overall 40x GPU compute improvement for containers on Apple Silicon
  • TEE variants built in — libkrun-sev (AMD SEV memory encryption + remote attestation) and libkrun-tdx (Intel TDX) make it one of the few microVM stacks with confidential-computing flavors

FAQ

What is libkrun?

libkrun is an open-source dynamic library that lets a program run processes in a partially isolated environment using KVM virtualization on Linux or Hypervisor.framework on macOS/ARM64, embedding a minimal Rust VMM behind a simple C API.

How much does libkrun cost?

Nothing — libkrun is free, open-source software under the Apache 2.0 license. There is no commercial tier; Red Hat funds development as part of the containers ecosystem.

What uses libkrun in production?

crun (the krun handler runs containers inside microVMs), krunkit (the GPU-enabled libkrun provider for podman machine on macOS), muvm (GPU-accelerated microVMs), RamaLama AI-model isolation, and Microsandbox, a YC-backed self-hosted AI sandbox server.

How is libkrun different from Firecracker?

Firecracker is a standalone VMM binary you orchestrate over an API socket; libkrun is a library your own process links against, bundling the kernel (via libkrunfw) so callers never manage kernel images — and it runs on macOS, which Firecracker does not.

Executive Summary

libkrun is a dynamic library that gives any process the ability to run workloads in a partially isolated microVM — using KVM on Linux or Hypervisor.framework (HVF) on macOS/ARM64 — by embedding a minimal virtual machine monitor behind a simple C API.[1] Written in Rust (with thin C bindings) and created in August 2020, the project recently moved from the containers GitHub organization to its own libkrun org (old URLs redirect), and stands at 2,312 stars and 204 forks as of June 2026, with pushes as recent as June 10, 2026.[1]

Where Firecracker and Cloud Hypervisor are standalone VMM binaries, libkrun inverts the model: isolation becomes a capability your program links in, not a process you orchestrate. That design made it the foundation of a quiet ecosystem — crun's krun handler wraps containers in microVMs, krunkit serves as the GPU-enabled libkrun provider for podman machine on macOS, muvm runs GPU-accelerated microVMs, Red Hat's RamaLama uses it to isolate AI models, and Microsandbox (YC-backed) builds a self-hosted AI sandbox server on it claiming average boots under 100ms.[1][2][3][4] Development is led by Red Hat engineer Sergio López, who authored its macOS GPU path.[5]

AttributeValue
CreatorSergio López and contributors; Red Hat / containers-ecosystem backed[5][3]
FoundedAugust 2020 (repo creation)[1]
FundingN/A — open source; development sponsored by Red Hat engineering[3]
GitHub Stars2,312 (June 2026)[1]
LicenseApache 2.0[1]

Product Overview

libkrun's pitch is "process isolation as a library": instead of shipping a VMM and an orchestration layer, you link libkrun.so (or dylib), call a handful of C API functions to configure root filesystem, vCPUs, memory, and ports, and your process becomes a microVM host.[1] The companion libkrunfw library bundles a pre-built guest kernel, so callers never manage kernel images or boot configuration.[1]

The project ships purpose-specific variants from the same codebase: generic libkrun, libkrun-sev (AMD SEV memory encryption with remote attestation), libkrun-tdx (Intel TDX), and libkrun-efi (the flavor krunkit links on macOS).[1][2]

Key Capabilities

CapabilityDescription
Embeddable microVMsC API to launch KVM/HVF VMs from any process; public API stable since v1.0.0[1]
Bundled kernellibkrunfw packages the guest kernel — no kernel/rootfs management[1]
GPU passthroughvirtio-gpu with Venus (Vulkan) and native-context transports[1]
TSI networkingTransparent Socket Impersonation proxies guest sockets through the host with zero network setup[1]
Conventional networkingvirtio-net with passt or gvproxy when full networking is needed[1]
Confidential computinglibkrun-sev (AMD SEV + attestation) and libkrun-tdx (Intel TDX) variants[1]

Product Surfaces

SurfaceDescriptionAvailability
libkrun / libkrun-efiThe dynamic library itself (Linux KVM, macOS HVF)[1]GA
crun krun handlerRun OCI containers inside microVMs via podman --runtime krun[3]GA
krunkitDrop-in vfkit replacement; GPU-enabled podman machine provider on macOS[2]GA
libkrun-sev / libkrun-tdxTEE variants for confidential workloads[1]GA (SEV), in tree (TDX)

Technical Architecture

libkrun integrates a minimal, Rust-based VMM (originating from the rust-vmm ecosystem) directly into the calling process, exposing virtio-console, block, fs, gpu, net, vsock, balloon, and RNG devices to the guest.[1] On Linux it drives KVM; on macOS/ARM64 it links directly against Hypervisor.framework.[1] Its signature networking trick, Transparent Socket Impersonation (TSI), impersonates guest sockets over virtio-vsock so workloads get host-mediated network access with no bridges, TAP devices, or slirp — at the cost of supporting only TCP and UDP.[1][6]

The GPU path is libkrun's standout: its virtio-gpu device with the Venus (Vulkan) transport lets Linux containers on Apple Silicon reach the host GPU, and combined with llama.cpp/Vulkan improvements delivered an overall 40x improvement in macOS container GPU compute performance.[5][7]

Key Technical Details

AspectDetail
DeploymentDynamic library linked into a host process (Linux x86_64/ARM64 via KVM; macOS/ARM64 via HVF)[1]
Guest kernelBundled via libkrunfw[1]
Integrationscrun/podman (krun), krunkit/podman machine, muvm, RamaLama, Microsandbox[1][3][4]
Open SourceYes (Apache 2.0)[1]

Strengths

  • Embeddable by design — the only major microVM stack consumed as a library; downstream tools (krunkit, crun, Microsandbox) get VM isolation without writing a VMM or managing kernels[1]
  • The macOS GPU story — virtio-gpu/Venus gives containers real GPU access on Apple Silicon, with a measured 40x overall GPU compute improvement; no competing container-VM runtime matches this on macOS[7][5]
  • Fast boots in practice — Microsandbox, built on libkrun, reports average boot times under 100ms while keeping hardware-level isolation[4]
  • Zero-config networking — TSI removes the bridge/TAP/slirp setup tax that HN commenters singled out as the project's most interesting idea[6]
  • Confidential-computing variants — libkrun-sev ships AMD SEV memory encryption with remote attestation; libkrun-tdx adds Intel TDX[1]
  • Credible institutional backing — maintained by Red Hat engineers and woven into the podman/crun/RamaLama ecosystem, with active pushes as of June 10, 2026[3][1]
  • Real AI-sandbox traction — chosen by YC-backed Microsandbox (6.5K+ stars) as its core isolation engine for untrusted AI agent workloads[4]

Cautions

  • Softer security boundary than a classic VMM — the maintainers state the guest and the VMM share the same security context: the VMM acts as a proxy for the guest, so host resources reachable by the VMM are potentially reachable by the guest; you must treat guest and VMM as a single entity, a weaker model than Firecracker's jailer-separated design[8]
  • TSI never upstreamed — HN commenters (127 points, 21 comments) flagged that TSI's kernel side missed its planned upstreaming, and that TSI supports only TCP/UDP — raw sockets do not work[6]
  • Library, not product — there is no daemon, REST API, scheduler, or fleet tooling; you (or a downstream like Microsandbox) must build the product layer yourself[1]
  • Deliberately limited scope — the README lists "be compatible with all kinds of workloads" as a non-goal; it is not a generic VMM[1]
  • Platform ceiling — Linux (KVM) and macOS/ARM64 (HVF) only; no Windows, and no Intel Mac support[1]
  • Small community for critical infrastructure — 2,312 stars and 204 forks is modest for a security boundary, and development is concentrated in a small Red Hat-affiliated maintainer group[1][5]

Pricing & Licensing

TierPriceIncludes
libkrunFreeLibrary, all variants (sev/tdx/efi), libkrunfw kernel bundle (Apache 2.0)[1]

Licensing model: Free and open source (Apache 2.0); no commercial edition exists — Red Hat monetizes indirectly through the products that embed it (podman, RHEL AI tooling).[1][3]

Hidden costs: Engineering time — as a library with a C API, integration, lifecycle management, and the product layer above it are entirely on you.[1]

Competitive Positioning

Direct Competitors

CompetitorDifferentiation
FirecrackerStandalone VMM binary with jailer process separation, Linux/KVM only; libkrun is an embeddable library that also runs on macOS but shares security context between guest and VMM[8]
Apple ContainerizationApple's first-party Swift framework on Virtualization.framework, macOS-only; libkrun is cross-platform (Linux + macOS), older, and adds the GPU/Venus path Apple's stack lacks[7]
Cloud HypervisorFull-featured rust-vmm VMM for cloud workloads with hotplug and live migration; libkrun strips the VMM to a minimal embedded core for single-workload isolation[1]
gVisor / Kata ContainersKata orchestrates full VMMs per container; gVisor intercepts syscalls in userspace; libkrun sits between — true hardware virtualization at library weight

When to Choose libkrun Over Alternatives

  • Choose libkrun when: you are building a runtime, sandbox server, or dev tool that needs VM isolation embedded in-process — especially if macOS support or GPU access inside guests matters
  • Choose Firecracker when: you run multi-tenant Linux infrastructure at scale and want the hardest, most battle-tested isolation boundary with jailer separation
  • Choose Apple Containerization when: you are macOS-only and want Apple's first-party, Swift-native stack
  • Choose Cloud Hypervisor when: you need full VMM features — device hotplug, live migration, large guests — rather than minimal per-process isolation

Ideal Customer Profile

Best fit:

  • Teams building AI agent sandboxes or code-execution platforms who want hardware isolation without operating a VMM fleet (the Microsandbox pattern)[4]
  • Developer-tool authors targeting macOS who need Linux microVMs with GPU access (the krunkit/podman machine pattern)[2]
  • Container-ecosystem users wanting per-container VM isolation via podman --runtime krun[3]
  • Confidential-computing workloads needing SEV/TDX with attestation in a minimal stack[1]

Poor fit:

  • Teams wanting a turnkey sandbox product — libkrun is a building block, not a service
  • Multi-tenant hosting where the threat model requires strict VMM/guest separation[8]
  • Workloads needing raw sockets or exotic networking under TSI[6]
  • Windows hosts or Intel Macs[1]

Viability Assessment

FactorAssessment
Financial HealthStable — no venture dependency; sustained by Red Hat engineering investment[3]
Market PositionNiche but entrenched — the default embeddable microVM library, and the only one with a macOS GPU path[7]
Innovation PaceActive — pushes as of June 10, 2026; GPU native-context, TDX, and EFI variants landed in tree[1]
Community/EcosystemModest direct (2,312 stars) but leveraged — podman machine, crun, muvm, RamaLama, and Microsandbox (6.5K+ stars) all build on it[1][4]
Long-term OutlookPositive — Red Hat's AI-isolation strategy (RamaLama, Podman AI Lab) runs through libkrun, anchoring continued investment[3]

libkrun's star count understates its position: it is infrastructure beneath better-known projects rather than a destination repo. The dependency of podman machine's macOS GPU story and a YC-backed AI sandbox on the same small library is simultaneously its validation and its concentration risk — much of the ecosystem's macOS container-VM capability traces to one Red Hat-maintained codebase.[2][4]

Bottom Line

libkrun is the embeddable option in the container-to-VM space: where Firecracker and Cloud Hypervisor are processes you operate, libkrun is a capability you link. For AI sandbox builders and macOS developer tooling, its combination of sub-200ms-class boots (Microsandbox reports under 100ms average), the only credible container GPU path on Apple Silicon, and bundled-kernel simplicity is unmatched.[4][7] The trade-offs are real: a security model that treats guest and VMM as one entity, TCP/UDP-only TSI networking, and a deliberately narrow workload scope.[8][6]

Recommended for: Builders of sandboxes, runtimes, and dev tools who want VM isolation as a library — particularly anything that must run Linux workloads (with GPU) on macOS.

Not recommended for: Hostile multi-tenant hosting requiring maximum VMM/guest separation, teams wanting a finished sandbox product, or Windows/Intel-Mac environments.

Outlook: Red Hat's AI-isolation roadmap and the rise of agent sandboxes pull in libkrun's favor; expect the GPU and TEE paths to deepen. Watch whether the security model hardens (or is more loudly documented) as AI-sandbox adoption raises the stakes, and whether TSI's kernel work ever lands upstream.

Research by Ry Walker Research • methodology

Sources

Share on XShare on LinkedIn