kern
A fast, rootless sandbox and virtual resource runtime for any workload, including untrusted and AI-generated code. Daemonless: a real, kernel-enforced container in ~3.5 ms from an OCI image, no daemon, one 1.52 MB static binary.
What is it?
What it is
kern is a fast, rootless sandbox and virtual resource runtime for any workload, including untrusted and AI-generated code. It is a single 1.52 MB static binary with no daemon that provides real OCI containers, sandboxing, resource profiling, and stack management.
Why it exists
To enable safe execution of untrusted and AI-generated code by providing kernel-enforced isolation, resource constraints, and strict security boundaries without requiring a full container runtime daemon. It addresses the need for secure, isolated computation environments while maintaining compatibility with standard container formats.
Who should use it
Developers, ML/AI researchers, security professionals, and DevOps engineers who need secure, isolated execution environments for untrusted or AI-generated code.
Who should avoid it
Users who require protection against malicious code from strangers (hostile inputs), multi-tenant scenarios where kernel isolation alone is insufficient, and systems requiring full kernel access beyond sandboxing.
Stars over time
+21 stars in the last 1 day
How it works
A quick walkthrough in plain English
How kern works
Step 1 of 3
You interact with it
Open kern, send a request, or connect it to your stack.
Features
Advantages
- No daemon, no socket, nothing to start at rest
- 0 RAM at rest versus Docker's 154-160 MB
- Cold start ~3.5 ms from OCI image vs Docker's ~297 ms
- Stop a service in ~1.9 ms vs Docker's ~310 ms
- One 1.52 MB binary footprint versus daemon stacks
- Always rootless isolation (Docker opt-in)
- Resource profiles carve CPU, memory, disk from host budget once in kern.toml
- docker-compose.yml works without Docker Desktop or overlay networks
- Python and Node SDKs with fault-result data, not exceptions
- MCP server enables local code interpreter for Claude Desktop, Cursor, etc.
- Adversarial pentest suites verify kernel-enforced boundaries
- Works natively on Linux, WSL2, and ARM boards (Raspberry Pi, Jetson, UNO Q)
- CLI and read verbs output JSON for machine parsing
- Faults are data: timeout, OOM, blocked syscall returned as result fields
Disadvantages
- Isolation boundary is the Linux kernel; kernel privilege-escalation bug possible escape
- Built on unprivileged user namespaces, a fertile source of kernel LPE bugs
- Mounts are trust decisions, not kernel-enforced boundaries (-v $HOME:/host gives full home)
- `--net host` and `--privileged` are opt-outs by name, reducing isolation
- Not a Docker Engine reimplementation: missing overlay networks, plugins, Swarm, CRI
- No Kubernetes runtime; no CRI support (use containerd or CRI-O)
- GPU slices not shipped; on roadmap only with judgement-only detection, no hard caps
- vgpio binds whole chip, not per-line restrictions; cooperative metadata not a boundary
- Single-shot latency floor ~1-2 ms (unshare + exec), top tier sits inside its own noise
- Two orders of magnitude gap to engine-level performance (Docker, runc)
- No native Windows build; WSL2 required
- No native macOS build; requires Linux VM (colima, OrbStack, etc.)
- Resource caps do not bite on default macOS guest
- userns trade not free; unprivileged user namespace remains attack surface
Installation
native
# if you do not have Rust yet curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh cargo install --git https://github.com/getkern/kern getkern --locked
FAQ
How does kern differ from Docker and Podman?
kern is daemonless and rootless by default: it starts in ~3.5 ms versus Docker's ~297 ms, uses 0 MB of RAM at rest versus Docker's 154–160 MB, and ships as a single 1.52 MB binary. It speaks Docker formats (OCI images, docker-compose.yml) but not the Docker API, so no overlay networks, Swarm, or plugins. Podman also has no daemon but shares Docker's slower cold-start times (~293 ms). kern is a container runtime, sandbox, and resource slicer in one.
How do I safely run untrusted or AI-generated code?
Pass --security-profile untrusted to the box command. This applies a seccomp allowlist, drops all capabilities, makes the root filesystem read-only, disables networking, and caps memory and pids. You can add --require-limits to refuse starting unless those caps actually bind. Example: kern box job --image python:3.12-slim --security-profile untrusted --memory 256m -v ./job:/w -- python3 /w/x.py
What are the system requirements for kern?
kern requires a Linux kernel with unprivileged user namespaces and cgroup v2 enabled. It runs natively on Linux, inside WSL2 on Windows, and on ARM boards (Raspberry Pi, Jetson, Arduino UNO Q). There is no native Windows or macOS build; on macOS, run kern inside a Linux VM (Colima, Lima, OrbStack, or Docker's existing VM). Run kern doctor to verify your system is ready.
Can I use my existing docker-compose.yml files with kern?
Yes. kern reads docker-compose.yml directly with no conversion step. Point it at your existing stack and run kern compose compose.yaml up. Services reach each other by name, ports publish to the host, and the stack costs only what the containers actually use. Note that overlay networks, Swarm, and some Docker plugins are not supported; see docs/DOCKER-COMPAT.md for the full compatibility matrix.
What are resource profiles and how do I use them?
Resource profiles (vcpu, vdisk, vgpio) are declared once in ~/.config/kern/kern.toml and attached by name to boxes or bare processes. A vcpu profile caps CPU and memory (e.g., 1.5 cores, 512 MiB), a vdisk caps a scratch disk, and a vgpio exposes specific device nodes. Attach profiles with flags like vcpu:heavy or vdisk:scratch when running: kern box train --image alpine vcpu:heavy vdisk:scratch -- ./train.sh. The same profile applies to unsandboxed processes with kern run vcpu:heavy -- ./train.sh.
Does kern support GPU access and acceleration?
GPU slices are on the roadmap but not yet shipped. kern doctor currently detects GPU hardware tiers (TIER-HW for MIG/SR-IOV partitions that enforce VRAM caps in hardware, and TIER-SOFT for consumer GPUs where caps are cooperative quotas, not kernel-enforced boundaries). No VRAM limiting is currently implemented. If you need GPU access today, use Docker or Podman instead.
Featured in Videos
YouTube tutorials and walkthroughs for kern
Alternatives
Similar projects ranked by category, topics, and text overlap.
