Kern v0.7.0: Daemonless, Rootless Container Runtime in a 1.5 MB Binary

Kern v0.7.0 is a daemonless, rootless sandbox and virtual resource runtime designed for high-performance isolation of workloads, including untrusted and AI-generated code. It provides kernel-enforced containers from OCI images with a cold start time of approximately 3.5 ms, all contained within a single 1.52 MB static binary.

High-Performance Container Isolation

Kern's primary value proposition is extreme efficiency in startup latency and resource footprint. By eliminating the daemon, it removes the background overhead associated with traditional container engines.

Startup Latency: Kern starts a real OCI image in ~3.5 ms, compared to ~297 ms for docker run.
Resource Footprint: The runtime is a single 1.52 MB static binary with zero RAM usage at rest. Its only Rust dependency is libc.
OCI Compatibility: It supports standard OCI images, including the ability to pull, build from a Dockerfile, commit, push, and save/load.

Sandbox and Security Model

Kern is a rootless sandbox that leverages Linux kernel namespaces (User, PID, Mount, Network, UTS, and IPC) and cgroup v2 for resource limits.

Security Profiles

One of Kern's key features is the --security-profile untrusted flag, which applies a hardened bundle of security settings:

Seccomp Allowlist: A deny-by-default seccomp filter (based on Moby's default, minus 35 escape syscalls).
Capability Drop: All dangerous capabilities are dropped (--cap-drop ALL).
Read-Only Root: The root filesystem is read-only by default.
Network Isolation: Network access is disabled unless explicitly requested.

Threat Model

Kern is not a hypervisor; the boundary is the Linux kernel. Consequently, a kernel privilege-escalation bug is a potential escape. It is designed for workloads where the user owns the blast radius (e.g., agent tool-calls, CI jobs), not for multi-tenant environments where hostile code from strangers is run on a shared kernel.

Resource Management and Profiles

Kern introduces the concept of resource profiles, allowing users to define reusable slices of CPU, memory, disk, and devices in a kern.toml configuration file.

vcpu: Defines CPU and memory limits (e.g., a "heavy" profile with 1.5 cores and 512 MiB RAM).
vdisk: Provides size-capped scratch disks (RAM-backed tmpfs for rootless mode, ext4-on-loop for privileged mode).
vgpio: Provides chip-granular access to device nodes (e.g., /dev/i2c-1).

These profiles can be attached to sandboxed boxes or bare processes using kern run to apply resource caps without isolation.

Developer Experience and Integration

Kern provides several tools for integrating containerization into development workflows:

Docker Compose Compatibility: Kern can read docker-compose.yml files directly. kern compose up runs stacks without a daemon or Docker Desktop, starting a web tier in ~0.3 s (warm).
SDKs for AI Agents: The kern-sandbox library provides Python and Node.js bindings. It allows programs to run code in fresh, isolated boxes with timeouts and OOM-kill detection handled as data rather than exceptions.
MCP Server: A dependency-free stdio server (kern-mcp) allows AI clients like Claude Desktop or Cursor to use Kern as a local code interpreter.

Technical Comparison: Kern vs. Docker vs. Podman

Feature	Kern	Docker	Podman
Daemon	No	Yes	No
Rootless	Always	Opt-in	Yes
Cold Start (Bare Box)	~2.3 ms	~297 ms	~293 ms
Cold Start (OCI Image)	~3.5 ms	~297 ms	~293 ms
Resident Memory (Idle)	0	154-160 MB	0
Footprint	1.52 MB Binary	Daemon Stack	Multi-binary Install
OCI Images	Yes	Yes	Yes
Docker Compose	Yes	Partial	Partial
Overlay Networks/CRI	No	Yes	Partial
GPU Support	Roadmap	Yes	Yes

Installation and Platform Support

Kern runs on Linux, WSL2, and ARM boards (Raspberry Pi, Jetson, Arduino UNO Q). It requires a Linux kernel with unprivileged user namespaces and cgroup v2.

Installation is available via a static release binary or from source via Cargo. The release binary is checksum-verified by the installation script.

Community Feedback

While the project has been well-received for its performance, some users in the Hacker News community noted that it is not a CRI (Container Runtime Interface) implementation, meaning it is not a drop-in replacement for Kubernetes runtimes like containerd or CRI-O.

"the submission title was a little misleading as it says 'container ... runtime' right there, and I guess it is, but it is not a CRI implementation."