Kern delivers OCI-compatible container runtime in 1.5 MB static binary without daemon

Kern collapses the traditional container stack into one 1.5 MB binary. The entire runtime, sandbox, resource slicer, and stack runner, is statically linked with libc as its only Rust dependency. This eliminates the need for a daemon, reducing both memory footprint and attack surface. Engineers can pull, build, and run OCI images directly, with startup times measured in milliseconds. The trade-off is a narrower feature set compared to Docker or Podman, but the simplicity may appeal to CI pipelines, build steps, or agent tool-calls where speed and minimalism are priorities.

Isolation is enforced through Linux namespaces, seccomp allowlists, and cgroup v2 limits, all running rootlessly by default. The --security-profile untrusted flag bundles these into a hardened configuration for untrusted or AI-generated code. However, the reliance on unprivileged user namespaces introduces a known attack surface for kernel privilege-escalation bugs. The project acknowledges this upfront in its security documentation, framing it as a trade-off for the rootless model. Engineers must weigh this risk against the benefits of a smaller, daemonless runtime.

Resource management is declarative: CPU, memory, disk, and device profiles are defined in a kern.toml file and attached by name. This allows consistent resource limits to be applied to both sandboxed and unsandboxed processes. Kern also supports Docker Compose files and its own stack format, enabling migration of existing workloads. However, it does not reimplement Docker’s API, so features like overlay networks or plugins are absent. The lack of CRI support means it cannot replace containerd or CRI-O in Kubernetes environments, limiting its use to standalone or agent-based deployments.

The project’s minimalism extends to its dependencies: JSON and OCI manifests are parsed manually, and image pulls use the host’s curl and tar rather than linking a TLS stack. This keeps the binary size small but may introduce variability in behavior across different host environments. Installation is streamlined via a checksum-verified script or a straightforward cargo install, though the latter increases the binary size slightly. Native Windows support is not available, but WSL2 is supported, including a pre-baked rootfs. Engineers targeting ARM boards or edge devices may find the static binary and low overhead appealing, though GPU slicing is not yet implemented.