boxkiteThe agent sandbox that runs on infrastructure you control.
E2B, Modal, and (now) Daytona are hosted-first — your agents' code runs on someone else's servers. boxkite is the opposite bet: an open-source, batteries-included sandbox you self-host on your own Kubernetes, so data never leaves your cluster and there's no vendor to lock into.
Where boxkite wins, honestly
This matrix compares along the axis boxkite is actually built for: running the whole tool surface on infrastructure you own. Every boxkite cell reflects shipped code. The other three are hosted products — a "see vendor" cell means the capability isn't something you self-host, not a claim they lack it; check each vendor's site for their hosted equivalent.
| boxkite | Daytona | E2B | Modal | |
|---|---|---|---|---|
| Self-hostable | Yes — your own cluster | No — reportedly privatized (verify) | No — hosted-first | No — hosted-first |
| Open source | Yes — MIT | No longer — core privatized | No | No |
| Data stays in your infra | Yes — never leaves your cluster | Hosted platform — see vendor | Hosted platform — see vendor | Hosted platform — see vendor |
| Isolation model | K8s pod — container isolation, not microVM | Unmaintained OSS — see vendor | Own hosted runtime — see vendor | Own hosted runtime — see vendor |
| Session start | ~0.9s p50 / ~1.3s p95 warm — measured on our API | sub-90ms — vendor-claimed | <200ms — vendor-claimed | ~1s — vendor-claimed |
| Framework-agnostic tools | 15 tools incl. python_interpreter — no LangChain required | Not the product focus | Not the product focus | Not the product focus |
| Git operations | Opt-in, 8-tool git set | Full git porcelain as SDK methods | First-class SDK git methods | No SDK helper — shell out via sandbox.exec |
| Long-running processes | Background start, stream, stdin, stop | Sessions, WebSocket streaming, interactive input | Interactive stream control incl. PTY | exec() streams stdout/stdin, poll()/wait() |
| Secrets handling | Encrypted proxy-substitution broker | Org-wide intercepting egress proxy | Encrypted org secrets, outbound proxy substitution | Plain env-var injection, no proxy substitution |
| Preview URLs | Signed URLs for sandbox ports | Standard + signed variants, public/private toggle | Public hostname per exposed port | HTTPS tunnels per exposed port |
| Custom sandbox images | Opt-in declarative builder (off by default) | Fluent SDK, Dockerfile passthrough, build cache | Custom Docker-based templates, build cache | Fluent Image API, Dockerfile support, layer cache |
| Filesystem snapshot/restore | Snapshot & restore session files | Persistent workspaces — snapshot specifics undocumented | Full memory+CPU snapshot (MicroVM) | Volumes (explicit commit) + experimental memory snapshot |
| Human-facing GUI access | No — headless only, by design | Full desktop automation API | Desktop VNC/GUI + computer-use agent | Not the product focus |
| Vendor lock-in | None — you own the stack | Hosted dependency | Hosted dependency | Hosted dependency |
Honest about the one axis we don't win
We won't pretend boxkite beats a microVM on raw cold start — it doesn't, and it's not trying to. E2B and Fly run Firecracker; that class of platform spins up in the low hundreds of milliseconds. boxkite's answer is a warm pool: a session is claimable in ~0.9s p50 / ~1.3s p95, measured against our own API — competitive with the gVisor class, and a deliberate trade for running the whole stack on infrastructure you own.
Warm session start
~0.9s p50 / ~1.3s p95
p50 877 ms · p95 1289 ms · n=10
In-sandbox exec
~0.4s
p50 419 ms · p95 509 ms · n=12
File operations
~0.4s
create/view/str_replace/grep, all ~0.4s p50 · n=6
| Platform | Isolation | Cold start (vendor-claimed) |
|---|---|---|
| E2B | Firecracker microVM | <200ms (same region; 80ms secure variant) e2b.dev ↗ |
| Modal | gVisor | ~1s (boots in about one second) modal.com ↗ |
| Fly Machines | Firecracker microVM | subsecond fly.io ↗ |
| Daytona | container dev-envs | sub-90ms creation daytona.io ↗ |
boxkite figures 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. Competitor figures are each vendor's own published cold-start claim, not a head-to-head reproduction. Methodology: /blog/measuring-session-start-latency.
Nothing here is a novel isolation primitive — it's the complete tool surface, hardened and wired to a real K8s pod, that you run yourself.
Reach for a hosted platform like E2B or Modal when you want zero operational surface and are fine with agent code running on a third party's infrastructure. Reach for boxkite when compliance, data-residency, or cost control means the sandbox has to run inside your own cluster — and you still want a batteries-included bash/python/file/process tool surface on day one instead of building it over the next few weeks.
Two ways to run boxkite — same code
This isn't "the good version vs. the trial version." Both paths run identical control-plane/ code — pick the operational model that fits.
Self-host
The OSS repo, your cluster
docker compose for kicking the tires, or real Kubernetes for production. You run it on your own infrastructure, with full control over the isolation model — data never leaves your cluster.
MIT licensed: fully permissive, free to use, modify, and self-host for any purpose with no restriction.
Best for
- Already running Kubernetes
- Compliance requirements that prevent sending code to a third-party API
- Wanting to inspect or modify the isolation model directly
Hosted API
The beta control-plane
Try boxkite without standing up Kubernetes yourself — the same control-plane/ code as the OSS repo, not a different product, running as a managed service.
Fair-use free tier: 20 sandbox-hours/month, 2 concurrent sandboxes. No billing yet.
Best for
- Kicking the tires fast
- Not wanting to operate Kubernetes at all
Both paths run identical code, so nothing here is "the good version vs. the trial version" — it's genuinely which operational model fits.
The hosted API isn't a crippled preview of the self-hosted product, and self-hosting isn't the "real" version with the hosted API as an afterthought. Pick self-hosting if you need your code to never leave your own infrastructure or you already operate Kubernetes; pick the hosted beta if you want to see boxkite work against a real API before deciding whether to run any of it yourself.