boxkiteGive your agent a sandbox, not your servers.
Your agent gets its own Kubernetes pod — no network access by default, sealed off from the rest of your infrastructure. Self-host it on your cluster, or start on the hosted API in minutes.
Free during the beta — no credit card. Self-hosting is free forever under the MIT license.
Agent execution, on infrastructure you already control
No vendor lock-in
Stop routing agent code through a third-party sandbox API. Run the exact same execution layer on your own Kubernetes cluster — your data never has to leave your network.
Enterprise-grade isolation
Real Kubernetes pod isolation, not a shared container. If the agent hallucinates and runs rm -rf /, it destroys a temporary pod — not your host machine, not your cloud network.
Batteries included
Four native SDKs (Python, TypeScript, Go, Rust) and an MCP server, out of the box — a clean install path whether your stack is Python-first or not.
Architecture, SDKs, and self-hosting — in one watch
Not a mockup — the real request path through the control-plane and SandboxManager into an isolated pod, the four native SDKs, and every self-hosting option. Try the exec path yourself in the playground below.
Handing an LLM a shell is handing it your infrastructure — unless that shell has nowhere else to go.
Why this exists
Agent frameworks are increasingly comfortable letting an LLM write and execute its own code. Running that in a subprocess on the same box as everything else isn't a security boundary — it's a hope. boxkite's answer is structural: every session gets its own Kubernetes pod, a fresh network namespace per executed command, a non-root user with every Linux capability dropped, and a read-only root filesystem.
Pod-per-session isolation isn't novel — projects like kubernetes-sigs/agent-sandboxalready do it well. What's been missing is the layer on top: a complete, already-hardened tool surface wired to that pod, framework-agnostic, that you hand to your agent today instead of building it yourself over the next few weeks.
One request, four hardened layers
Click a layer to see what it actually does.
Your agent
Any framework, or plain HTTP/MCP — boxkite doesn't require a dependency on any of them. The adapters convert the same tool specs for whichever one you use.
Real numbers off the live API, not a spec sheet
boxkite isn't the fastest cold start on the market — microVM platforms win that on raw spin-up. What it is: a warm session in about nine-tenths of a second and sub-half-second in-sandbox ops, on infrastructure you own. Every figure below was measured against our own hosted API, and we publish the methodology.
Warm session start
~0.9s p50 / ~1.3s p95
p50 877 ms · p95 1289 ms · min 836 ms
POST /v1/sandboxes · n=10
In-sandbox exec
~0.4s
p50 419 ms · p95 509 ms
POST /exec · n=12
File operations
~0.4s
create, view, str_replace, grep
all ~0.4s p50 · n=6
Session destroy
~0.6s
p50 560 ms
session teardown · n=10
Per-tier memory budget
Enforced on the sidecar cgroup where agent code runs — a hard ceiling, not a best-effort request.
Measured against our hosted API on 2026-07-21; sample size shown per metric, client-side wall-clock around each REST call, cluster warm and image cached. Methodology: /blog/measuring-session-start-latency.
Wire a hardened sandbox into your agent in a few lines
create_sandbox_tool_specshands back 15 tools already bound to a live session — bash, a persistent Python interpreter, file and search ops, process control. They're framework-agnostic: call a handler directly, or convert the list for LangChain or OpenAI-style function calling. No LangChain dependency required.
from uuid import uuid4
from boxkite import SandboxManager
from boxkite.tools import create_sandbox_tool_specs
manager = SandboxManager()
session_id = str(uuid4())
await manager.create_session(organization_id=uuid4(), session_id=session_id)
specs = create_sandbox_tool_specs(sandbox_manager=manager, session_id=session_id)
# specs = [ToolSpec(name="bash_tool", ...), ToolSpec(name="file_create", ...), ...]
# Framework-agnostic: no LangChain/LangGraph dependency. Call spec.handler(**kwargs)
# directly, wire into CrewAI/AutoGen/a hand-rolled loop, or convert the list:
# boxkite.tools.adapters.to_openai_functions(specs) # stdlib, no extra dep
# boxkite.tools.adapters.to_langchain_tools(specs) # needs the [langchain] extraRun a real command in a real sandbox — no signup
A throwaway pod spins up just for you, times out on its own in a few minutes, and never touches anything but itself.
Spin up a real, throwaway sandbox and run a command in it — right from this page.
Every session is structurally sealed off
One pod, two containers. Defense in depth — each control below is an independent boundary, so getting past one still leaves agent code trapped by the rest.
| sandbox container | sidecar container | |
|---|---|---|
| Runs | Agent-generated code | The HTTP API + storage sync |
| User | Non-root (UID 1001), runAsNonRoot: true | Root (needed for nsenter) |
| Capabilities | All dropped (capabilities.drop: [ALL]) | Only SYS_PTRACE/SYS_ADMIN — never inherited by agent code |
| Filesystem | Read-only root filesystem | Read-write (owns the shared volumes) |
| Network | Denied by default — NetworkPolicy + a fresh network namespace per exec | Only what storage sync needs |
| Priv. escalation | allowPrivilegeEscalation: false | Same |
- Sidecar auth fails closed. Every route but
/healthrequires anX-Sidecar-Auth-Tokengenerated fresh per pod at creation time — never a static, repo-wide value. If the token isn't set, protected routes return503instead of running unauthenticated. - Per-exec network isolation is the real boundary, not NetworkPolicy alone. In Kubernetes mode, every
/execruns inside a freshly created, empty network namespace — no interfaces at all, so it structurally can't reach the network or the sidecar's own port. - Manager-to-sidecar traffic is encrypted,over TLS pinned per pod to a self-signed cert minted at creation — the auth token and every command cross the pod network verified against that one pod's cert and no other.
We publish the full threat model — every layer, its residual risk, and what's in and out of scope for security reports. Read the security page →
Self-hosted, not just self-branded
E2B, Modal, and Daytona run your agent's code on their infrastructure. boxkite runs on yours — that's the whole bet, so it's the axis this comparison is built around.
| boxkite | E2B / Modal / Daytona | |
|---|---|---|
| Self-hostable | Yes — your own cluster | No — hosted-first (Daytona's core is reportedly privatized) |
| Data stays in your infra | Never leaves your cluster | Runs on their infrastructure — see each vendor |
| Open source | Yes — MIT | No |
| Vendor lock-in | None — you own the whole stack | Hosted dependency |
Built for agents that actually do things
The image ships with real tooling pre-installed, so an agent can get to work the moment its sandbox comes up — no runtime installs, no network required.
Data analysis
pandas, numpy, polars, matplotlib and scikit-learn are pre-installed — hand your agent a dataset and let it compute, plot, and hand results back.
Document processing
pandoc, LibreOffice, poppler, Tesseract OCR and the python-docx/pptx/pdf stack are baked in for agents that parse, convert, and generate documents.
Coding agents
The opt-in git tools plus file editing, grep, and a persistent Python interpreter let an agent clone a repo, change it, run the tests, and commit.
Long-running services
Start a dev server or watcher as a tracked background process and expose it through a signed preview URL — stream its output, send it input, stop it.
Two ways to run it
Point the CLI at the hosted control-plane to try it in minutes, or self-host the whole stack — same control-plane/ code either way.
Fastest — hosted API
pip install boxkite-sandbox # ships the `boxkite` CLI
# signs up, mints an API key, and saves both — one command
boxkite signup --url https://your-control-plane.example.com
# create a sandbox and run something in it
boxkite session create --label demo
boxkite exec "python3 -c 'print(1 + 1)'"Self-host — docker compose up
A real cluster (or a local kind one) is only needed once you want the full pod isolation model above; compose mode is for kicking the tires.
Copy the env template and generate a sidecar auth secret — this is required, not optional, since every sidecar route but /health checks it.
Brings up the sandbox container, the sidecar HTTP API, and a local MinIO for S3-compatible storage.
Hit /health, then exercise /exec and /file-create directly before wiring it into any agent framework — see the code sample above.
# 1. clone + configure
git clone https://github.com/EvAlssment/boxkite.git && cd boxkite
cp .env.example .env
echo "SIDECAR_AUTH_TOKEN=$(openssl rand -hex 32)" >> .env
# 2. build + start
docker compose -f deploy/docker-compose.yml up -d --build
# 3. check it's healthy
curl http://localhost:8080/health