kern: A fast, rootless sandbox and virtual resource runtime for any workload, including untrusted and AI-generated code. A real, kernel-enforced container in ~3.5 ms, out of one 1.52 MB binary with no daemon. 0 RAM at rest · no daemon, no socket, nothing to start · one static binary, libc its only Rust dependency
# install the release binary (static, 1.52 MB, checksum-verified by the script) curl -fsSL https://raw.githubusercontent.com/getkern/kern/main/install.sh | sh # a throwaway shell in a real OCI image: rootless, kernel-enforced, a few ms kern box dev --image alpine -it -- sh
No native Windows: use WSL2. Install.
What kern is
One binary that manages resources, of which isolation is the first. That is why there is no single row for kern in a comparison table: it is a container runtime, a sandbox, a resource slicer and a stack runner at once, in 1.52 MB with no daemon.
A real container. Real OCI images: pull , build from a Dockerfile, commit , push , save / load . A box from an image starts in ~3.5 ms.
Real OCI images: , from a Dockerfile, , , / . A box from an image starts in ~3.5 ms. A sandbox, always rootless. User, PID, mount, network, UTS and IPC namespaces, an overlay or read-only root pivoted in, a deny-by-default seccomp allowlist and cgroup v2 limits. One flag, --security-profile untrusted , is the whole hardened bundle.
User, PID, mount, network, UTS and IPC namespaces, an overlay or read-only root pivoted in, a deny-by-default seccomp allowlist and cgroup v2 limits. One flag, , is the whole hardened bundle. Resource profiles, not just isolation. CPU ( vcpu: ), memory, disk ( vdisk: ) and devices ( vgpio: ), declared once in a kern.toml and attached by name. kern run applies the same caps to a process on the host, with no sandbox at all. docs/RESOURCES.md
CPU ( ), memory, disk ( ) and devices ( ), declared once in a and attached by name. applies the same caps to a process on the host, with no sandbox at all. docs/RESOURCES.md Stacks, in kern's own format or in Docker's. kern compose <file> up takes a kern-compose.toml ( [box.NAME] tables, with the resource profiles above) or the docker-compose.yml you already have, read as written. One stack to one pod, services reaching each other by name.
takes a ( tables, with the resource profiles above) or the you already have, read as written. One stack to one pod, services reaching each other by name. The tools around them. ps , logs , exec , stats , inspect , wait , top (a live TUI), doctor , plus a Python and Node SDK and an MCP server for agents.
... continue reading