xiaods/k8e

What is K8E?

K8E (hosted at k8e.sh) is an open‑source sandbox platform for AI agents. It ships as a single binary (< 100 MB) that turns any Linux machine into a cluster where autonomous agents (Claude Code, Codex, Pi, etc.) can run untrusted code safely. The sandbox uses pluggable isolation runtimes – gVisor, Kata Containers, or Firecracker microVMs – and provides a lightweight API (gRPC + E2B‑compatible HTTP) that agents can call directly.

Core capabilities

Feature	What it does
Hardware isolation	Choose gVisor (userspace kernel), Kata (VM‑backed) or Firecracker (microVM) per session.
Network policies	Per‑session eBPF rules via Cilium (toFQDNs), no external proxy needed.
Resource quotas	CPU / memory limits per agent to avoid runaway costs.
Warm‑pool pods	Pre‑booted sandbox pods give sub‑500 ms claim latency for new sessions.
Ephemeral workspaces	Automatic cleanup after a session; sub‑agents share the parent pod but are reset on reuse.
Content‑addressed snapshots	SHA‑256‑based layered storage with zstd compression; incremental restore via --base.
Exec transcripts & logs	File‑backed, resumable command logs accessible via k8e-sandbox-cli log.
Observability	Prometheus metrics and an NDJSON event stream (events, ps commands).
E2B SDK compatibility	The API matches the public E2B SDK, so existing SDK code works unchanged.
CLI catalog	Machine‑readable command description (catalog) for auto‑generating SDK bindings.

Architecture at a glance

AI Agent ──► k8e‑sandbox‑cli (gRPC/mTLS) ──► Sandbox Gateway
                                            │
                                            ├─► Warm‑pool controller (keeps ready pods)
                                            └─► Isolated sandbox pod (gVisor/Kata/Firecracker)

The gateway is the only public entry point; it handles session lifecycle, file I/O, PTY terminals, snapshotting, and exposure of services.

Quick‑start (30‑second install)

# 1️⃣ Install an isolation runtime – gVisor is the default and needs no KVM
ARCH=$(uname -m)
URL=https://storage.googleapis.com/gvisor/releases/release/latest/${ARCH}
wget ${URL}/runsc ${URL}/runsc.sha512 \
     ${URL}/containerd-shim-runsc-v1 ${URL}/containerd-shim-runsc-v1.sha512
sha512sum -c runsc.sha512 -c containerd-shim-runsc-v1.sha512
chmod +x runsc containerd-shim-runsc-v1
sudo mv runsc containerd-shim-runsc-v1 /usr/local/bin/

# 2️⃣ Install K8E itself (single‑binary installer)
curl -sfL https://k8e.sh/install.sh | sh -

# 3️⃣ Verify the service
k8e-sandbox-cli status          # → {"available":true,…}

# 4️⃣ Run a command in a sandbox
k8e-sandbox-cli run 'echo hello from the sandbox'

All of the above works on any modern x86_64, ARM64, or RISC‑V Linux host.

Using the sandbox from an AI agent

1. Create an API key on the server (TTL defaults to 30 days):

   k8e sandbox-apikey create my‑agent
   # → {"name":"my‑agent","key":"k8e‑abc123…"}
   

2. Download the client binary for your platform (≈ 44 MB) and symlink it to k8e-sandbox-cli.
3. Connect – this performs mTLS authentication and installs the /k8e‑sandbox skill into the agent’s harness:

   ./k8e-sandbox-cli --endpoint <server‑ip>:50051 \
       --apikey k8e‑abc123… connect
   

4. The agent can now issue natural‑language commands such as “run this Python snippet in a sandbox”; the skill translates the request into k8e-sandbox-cli run … behind the scenes.

Main CLI commands (agent‑facing)

Command	Purpose
run <code>	Execute a one‑off command or script (auto‑creates a session).
create	Explicitly start a session – you can set runtime, allowed hosts, Git repo, etc.
destroy <sid>	Tear down a session and free its resources.
write / read / list	Manipulate files inside the sandbox workspace.
subagent <parent‑sid>	Spawn a child sandbox that re‑uses the parent pod (max depth 1).
catalog	Dump a machine‑readable description of the CLI – useful for SDK generation.
sandbox‑apikey …	Manage server‑side API keys (create, list, delete).

When would you use K8E?

• Agentic AI services that need to execute arbitrary code (e.g., code‑generation agents, data‑analysis bots).
• Multi‑tenant platforms where each tenant’s agent must be isolated from others.
• Cost‑sensitive deployments – warm‑pool pods keep start‑up latency low while keeping the binary footprint tiny.
• Self‑hosted alternatives to commercial offerings like E2B, Daytona, or the Kubernetes SIG agent‑sandbox project.

How it differs from other sandboxes

	K8E	E2B	Daytona	agent‑sandbox (SIG)
Self‑hosted, single binary	✅ (< 100 MB)	❌ heavy VM images	✅	❌ requires full K8s cluster
Pluggable runtimes	gVisor / Kata / Firecracker	Firecracker only	microVM/containers	RuntimeClass (needs K8s)
Warm‑pool for sub‑500 ms starts	✅	❌	✅	❌
E2B SDK compatibility	✅ native	✅	❌	❌
Built‑in eBPF network policies	✅ (Cilium)	❌	❌	❌

---

TL;DR

K8E is a compact, self‑contained sandbox matrix that lets you run AI‑generated code securely at scale. Install a runtime (gVisor is easiest), run the one‑line installer, create an API key, and your agents can start executing code in isolated pods with millisecond latency—all without needing a full Kubernetes cluster or heavyweight VMs.