kern is a real container,
in ~3.5 ms.

One machine, one workload, rounded up from the measurement: an Intel i7-14700KF on Linux 7.0.0, with the release binary and python3 examples/benchmark.py. The table below has the numbers without an image, and yours will differ with your CPU, kernel and filesystem.

What kern does

kern box dev --image alpine -it -- sh

$ pip install kern-sandbox     # or: npm install kern-sandbox

from kern_sandbox import run_code
r = run_code("print(sum(range(100)))")
print(r.stdout, r.fault)   # a timeout or OOM is data, not an exception

kern box job --image python:3.12-slim --security-profile untrusted \
  --memory 256m -v ./job:/w -- python3 /w/x.py

kern box train --image alpine vcpu:heavy vdisk:scratch
kern run --memory 256M --cpus 0.5 -- ./crunch

kern compose compose.yaml up

How a box is built

No daemon means there is nothing to ask and nothing to wait for. The work happens in the process you started, in a fixed order, and kern box --plan prints that order without running any of it.

1. Namespaces first. User, PID, mount, network, UTS and IPC are unshared up front. Your uid maps to root inside the box and only there, so no privilege is gained on the host.
2. A root to pivot into. The image is assembled as an overlay, or mounted read-only, then entered with pivot_root. That sequence is a typestate in the source: code that pivots into a root it has not yet remounted read-only does not compile, so the bug is unrepresentable rather than untested.
3. Capabilities dropped. Sixteen dangerous capabilities go before exec. --security-profile untrusted drops the lot and adds a read-only root.
4. Seccomp, on by default. The filter is an allowlist, not a blocklist: the default moby set minus the 35 syscalls kern treats as escape vectors, which stay hard-killed. A syscall outside the vetted set gets ENOSYS back instead of a kill, which is what lets ordinary images keep working under it.
5. cgroup v2 limits. Memory, CPU and pids are written to the box's own cgroup, and --require-limits refuses to start at all if they would not bind, rather than reporting a cap that quietly does nothing.

Then exec. What is left running is one short-lived process, and kern ps reads its state from the kernel rather than from a database that could disagree with it.

Where it fits

kern is built for code you chose to run and whose blast radius you own.

• Agent tool-calls. A fresh box per call from Python or Node, network off and caps on, or through the bundled MCP server so Claude Desktop and Cursor get a local code interpreter with no cloud account.
• CI jobs and build steps. Nothing to install on the runner and nothing left running after: one static binary, no daemon to start first.
• Notebook-style cells. A warm interpreter across calls when you want speed, a throwaway box per call when you want isolation. Timeouts and OOM kills come back as data on the result.
• Edge and ARM boards. One binary you copy onto a Raspberry Pi, a Jetson or an Arduino UNO Q and run, where a container engine is too heavy to install.
• The local dev stack. Your existing compose file, brought up with no Docker Desktop and no background VM.

Cold start: kern vs Docker, Podman, runc and bubblewrap

kern is faster than bubblewrap, by about 9%, and it takes care to show it: timed one runtime after the other both read 2.5 ms, because the gap is smaller than the drift between two batches minutes apart. With alternating batches on an idle machine, against the binary attached to the release rather than a local build, they separate: 2.4 ms against 2.6, kern ahead in 238 of 240 batches. Over 35 replicas the direction has never flipped. bubblewrap is a launcher with no images, caps or lifecycle, and the gap that means something is the one to the engines, two orders of magnitude above. Method, board numbers and every caveat: BENCHMARKS.md.

What kern is not

• Not a hypervisor. The boundary is the Linux kernel, so a kernel privilege-escalation bug is an escape. Docker and Podman share that condition, which is why gVisor and Firecracker exist.
• Not free of the userns trade. Its isolation is built on an unprivileged user namespace, a fertile source of kernel LPE bugs.
• Not a wall around what you mount in. A bind mount is a trust decision you make, not a boundary kern enforces. --net host and --privileged are opt-outs by name.
• Not shipping GPU slices. No GPU limit ships, so there is nothing here to attack. What ships is the verdict: kern doctor reads sysfs and reports what a VRAM cap on each device would be worth, and on consumer hardware that is a cooperative quota, NOT a boundary against malicious code. Nothing intercepts a driver call and nothing caps a GPU.
• Not a Docker Engine reimplementation, and not a Kubernetes runtime. It speaks Docker's formats, not its API: no overlay networks, no plugins, no Swarm, no CRI.

Where a boundary is cooperative rather than kernel-enforced, SECURITY.md says so and names the bypass. Five adversarial suites in pentest/ assert those boundaries against the kernel rather than against kern's own reporting.

When to use what

• Your own or semi-trusted code, fast, on your machine. That is kern: milliseconds per box, nothing running between boxes, the same binary on a laptop and on a board.
• Production orchestration. Overlay networks, plugins, Swarm or Kubernetes: use Docker, containerd or CRI-O. kern speaks Docker's formats but not its API, and it has no CRI.
• Hostile code from strangers, on a kernel you serve other tenants from. Use a microVM such as Firecracker, or gVisor. kern's boundary is the Linux kernel, and that is the honest end of what it gives you.

Questions