Kern ships rootless kernel-enforced containers in a 1.5 MB daemonless binary

A 1.5 MB runtime with no daemon

Kern, an open-source project whose release reached Hacker News's front page, compresses a container runtime, a sandbox and a resource limiter into one static binary of roughly 1.5 MB — and there is no daemon behind it. According to the project's GitHub repository, the binary starts a kernel-enforced, rootless container from a standard OCI image in about 3.5 ms, and consumes no memory at rest because nothing keeps running between invocations.

The project pitches itself at workloads you choose to run despite limited trust: agent tool calls, CI jobs, build steps and code cells, including AI-generated code.

How the isolation works

Every container — kern calls them boxes — is rootless by default rather than as an opt-in. Isolation combines user, PID, mount, network, UTS and IPC namespaces with an overlay or read-only root filesystem, a deny-by-default seccomp allowlist and cgroup v2 limits. A single flag, --security-profile untrusted, switches on the hardened bundle: the seccomp allowlist, dropping all Linux capabilities and a read-only filesystem, with no network unless explicitly requested. A companion flag, --require-limits, refuses to start a box at all unless its memory and process caps are genuinely enforced.

The documentation is unusually blunt about what this does not buy. The boundary is the Linux kernel, not a hypervisor, so a kernel privilege-escalation bug means escape — a condition kern shares with Docker and Podman, and the reason gVisor and Firecracker take heavier approaches. The README's security notes also acknowledge that unprivileged user namespaces, the mechanism the isolation rests on, have historically been a fruitful source of kernel bugs. Mounts are treated as trust decisions rather than enforced boundaries: bind-mounting your home directory hands it over, while --net host and --privileged are explicit opt-outs by name. The project states plainly that the design is not intended for hostile, multi-tenant code from strangers on a kernel serving other tenants.

The size is a design choice

The entire Rust dependency tree is libc. JSON and OCI manifests are parsed by hand, and image pulls shell out to the curl and tar already installed on the machine rather than linking a TLS stack. The size-optimized release build is 1.52 MB; a plain build from source comes to 1.91 MB, and the README reports a 36-second build on a desktop with an i7-14700KF processor.

Resources and stacks, not just boxes

Resource profiles declare CPU, memory, disk and devices once in a kern.toml and attach to boxes by name, and the same caps can be applied to an ordinary host process with no sandbox at all through kern run. Stacks run either in kern's own compose format or from an existing docker-compose.yml read as written, with services in one stack reaching each other by name. In the README's demo, a postgres-plus-adminer stack with warm caches has its web tier serving in about 0.3 s and occupies about 66 MB — with no background VM on top, unlike Docker Desktop's pre-container overhead.

Around the core sit ps, logs, exec, stats, inspect, wait, a live TUI called top and a doctor command, plus Python and Node SDKs and an MCP server for agents. Every read command can emit JSON instead of a table, so nothing has to parse terminal output.

Deliberate boundaries

Kern speaks Docker's file formats but not its API: no overlay networks, no plugins, no Swarm. It is not a Kubernetes runtime — there is no CRI support; containerd or CRI-O fill that role. GPU slicing is on the roadmap with no code shipped yet. The binary needs a Linux kernel with unprivileged user namespaces and cgroup v2, runs on Linux, WSL2 and ARM boards such as the Raspberry Pi and Jetson, and has no native Windows build. Releases include x86_64 and aarch64 binaries, a Windows shim and a pre-baked WSL rootfs, each with a SHA256 checksum; the install script refuses a download that fails verification, and the release tag is GPG-signed and independently timestamped.

Why it matters

Most container tooling assumes a resident daemon — and on desktop platforms a background VM — before the first container starts. Kern's bet is that a single, auditable, libc-only binary with zero footprint at rest makes sandboxed execution cheap enough to reach for more often, whether for CI steps, agent tool calls or throwaway shells on an ARM board. Compose compatibility lowers the switching cost, and the documentation states its threat model's limits before making claims. The trade-offs are real — kernel-level isolation, a user-namespace attack surface, no hypervisor-grade boundary — but they are stated up front, which is more than many runtimes offer.