kern

kern is a daemonless, rootless container runtime and sandbox written in Rust, distributed as a single 1.52 MB static binary under the Apache-2.0 license. It starts a kernel-enforced container from an OCI image in approximately 3.5 ms — roughly two orders of magnitude faster than Docker or Podman — with zero resident memory when idle. The project is maintained by Alex (@realexhub) under the getkern GitHub organization, with v0.7.0 as the first published release.

What It Is

kern occupies an unusual position: it is simultaneously a container runtime, a sandbox, a resource slicer, and a stack runner, all in one binary with no daemon to install or manage. Its entire Rust dependency tree is a single crate (libc); JSON and OCI manifests are parsed by hand rather than through bundled libraries. The result is a tool that runs on Linux, Windows via WSL2, and ARM boards (Raspberry Pi, NVIDIA Jetson, Arduino UNO Q) from the same static binary.

Core capabilities include:

• Real OCI containers: pull, build from a Dockerfile, commit, push, save/load — a box from an image starts in ~3.5 ms
• Always-rootless sandboxing: user, PID, mount, network, UTS, and IPC namespaces; overlay or read-only root; deny-by-default seccomp allowlist; cgroup v2 limits; --security-profile untrusted bundles the full hardened set in one flag
• Resource profiles: vcpu: (CPU + memory), vdisk: (size-capped scratch disk), and vgpio: (device nodes) declared once in kern.toml and attached by name to any box or bare process
• Stack support: kern compose reads kern-compose.toml or an existing docker-compose.yml with no conversion step
• Tooling: ps, logs, exec, stats, inspect, wait, top (live TUI), doctor, plus Python and Node SDKs and an MCP server

Performance and Architecture

The project publishes benchmark numbers measured on an Intel i7-14700KF running Linux 7.0.0. According to those figures, kern's cold start for a bare box is ~2.3 ms, matching bubblewrap and sitting roughly 125× faster than runc (~18.6 ms) and ~130× faster than Podman or Docker (~293–297 ms). Spawning 200 boxes in parallel takes ~0.11 s versus ~44.8 s for Podman and ~16.2 s for Docker. A live box consumes ~0.3 MB of memory, and the process has zero resident memory when nothing is running.

The architecture deliberately avoids linking a TLS stack: pull shells out to curl and tar already present on the machine. The binary is 1.52 MB in the size-optimized release build and 1.91 MB when built from source with cargo install.

Embedding and MCP Integration

kern ships a Python package (kern-sandbox on PyPI) and a Node package (also kern-sandbox on npm) that wrap the binary for embedding in agent or LLM-generated code workflows. Each call runs in a fresh isolated box with network off, memory and PID caps, capabilities dropped, output bounded, and a caller-enforced timeout. Faults — timeouts, OOM kills, blocked syscalls — are returned as data fields rather than exceptions.

The package also ships kern-mcp, a dependency-free stdio MCP server that exposes run_code (Python/bash/Node), write_file, read_file, and list_files to any MCP client such as Claude Desktop or Cursor. Each tool call runs in a fresh network-off box; files persist across calls in a workspace on disk.

Security Model and Tradeoffs

kern's security documentation is explicit about its boundaries. The isolation boundary is the Linux kernel, not a hypervisor, so a kernel privilege-escalation bug is an escape — a condition shared with Docker and Podman. Its isolation relies on unprivileged user namespaces, which the project's SECURITY.md describes as "a fertile source of kernel LPE bugs." The project includes four adversarial pentest suites in pentest/ that assert boundaries against the kernel rather than against kern's own reporting.

Key security mechanisms: 16 dangerous capabilities dropped before exec, an always-on seccomp allowlist (moby's default filter minus 35 escape syscalls that are hard-killed), cgroup v2 limits with --require-limits enforcement, and a deny-by-default /dev. Where a boundary is cooperative rather than kernel-enforced, the documentation names the bypass explicitly.

kern is not intended for hostile code from strangers in multi-tenant environments on a shared kernel — the project states this directly. It targets workloads where the operator chooses to run untrusted or AI-generated code and owns the blast radius: agent tool-calls, CI jobs, build steps, and code cells.

Update: v0.7.0 — First Published Release

v0.7.0, published on 2026-08-24, is the first public release of kern. The project states that the core is complete and all documented features work today, validated by 848 Rust tests, 78 Python tests, and 61 Node tests on real hardware including Linux, WSL2, Raspberry Pi 5, Jetson Orin Nano, and Arduino UNO Q. The CLI and configuration surface are not frozen and may change before 1.0, with all changes called out in CHANGELOG.md. The release tag is GPG-signed and independently timestamped; commits themselves are not signed.