Spawnbox gives each AI agent its own small, safe computer to run code in. It is open source and runs on your own servers. A new one is ready in less than 100 ms. Your API keys never go inside.
≈8ms
Start a new sandbox
60–75ms
Start from a saved copy
≈65ms
Wake up a paused sandbox
16copies
Copies of one sandbox, made in under 1 s
Measured on the Spawnbox test server.
STEP 1 — YOUR AGENT
One API call or one command. A fresh, empty computer is ready in about 8 ms.
POST /v1/sandboxesspawnbox createSTEP 2 — THE SANDBOX
It is a tiny virtual machine. If the agent breaks something, only its own sandbox breaks.
spawnbox pause $Sspawnbox ports publish $S 3000spawnbox cp ./src $S:/workspace/srcspawnbox events --followSTEP 3 — KEYS AND INTERNET
The agent sees a fake key. When it calls OpenAI, Spawnbox puts the real key in on the way out. Other sites get only the fake one.
sbx_ph_... (a fake key)github.com, *.pypi.orgblockedSTEP 4 — YOUR SERVER
Install it with one script on a Linux machine. Nothing goes to our cloud.
Linux with KVMmachines without KVMadd more serversA sandbox is a full Linux computer. If it runs on Linux, it runs in Spawnbox.
› fix the failing test
- return total
+ return round(total, 2)
✓ 14 tests passed
Run Claude Code, Codex or Copilot CLI on a real repo. Let them install packages and run tests. If they break something, only the sandbox breaks. Your API keys stay outside.
Give an agent its own browser, or a whole desktop you add to its template. It clicks, types, fills forms and uses apps. It can only reach the sites you allow, and every visit is logged.
Run the Next.js or Vite app you ship to Vercel, or one you made in Lovable. Start it with npm run dev, publish port 3000, and open the link.
23 features in six groups. Coming later: TypeScript and Python SDKs, an MCP server and disk speed limits.
SB-01
Start, list, look at and delete sandboxes. Give each one a time limit, settings and labels.
SB-02
Run any command. Get the result at the end, or watch it live. Type input into it.
SB-03
Read, write, list and delete files and folders.
SB-04
Open a live terminal into the sandbox.
SB-05
Share a short-lived link to one sandbox's terminal and web apps. No API key needed.
SB-06
Download code from Git. Private repos work with a saved secret.
SB-07
Save a starting setup with your tools already installed. Start from Debian, a Docker image or devcontainer.json.
SB-08
Keep spares ready and waiting. A new sandbox starts in about 8 ms. The number of spares grows and shrinks with use.
SB-09
Store templates in S3-compatible storage. Build each one only once. A sandbox can start before the whole template has downloaded.
SB-10
Keep files after a sandbox ends. Share one read-only folder with many sandboxes.
SB-11
Pause a sandbox and save everything to disk. Wake it up in about 65 ms. Idle sandboxes pause by themselves.
SB-12
Make up to 16 copies of a running sandbox in under 1 s. Save it as a template without stopping it.
SB-13
Open a web app that runs in a sandbox from a link. The link can be public, need a token, or be private.
SB-14
Choose which websites a sandbox can reach: all, some or none. Limit its speed. Log every connection.
SB-15
Your API keys stay locked outside the sandbox. They are added to requests only for sites you allow.
SB-16
Add servers when you need room. Each new sandbox goes to the server with the most space. Empty a server before you remove it.
SB-17
Uses Firecracker on servers with KVM, and gVisor on servers without it. You can require Firecracker for a customer.
SB-18
Serve many customers from one install. Each gets its own keys, limits, templates, secrets and site rules.
SB-19
A log of everything an agent does: commands, file changes, connections and key use. Watch it live or send it to OpenTelemetry.
SB-20
Numbers for each server, ready for Prometheus: start times, errors, connections and free space.
SB-21
See how much CPU, memory, disk and network each customer and sandbox used, hour by hour.
SB-22
One spawnbox command does it all: sandboxes, files, templates, secrets, customers and logs.
SB-23
Install with one script. Runs as a normal system service with HTTPS. Comes back by itself after a crash.
Inside its sandbox, an agent can run code, use the internet, keep files and use your keys safely. You can watch it, pause it or copy it.
›
Run any command and watch the output live. Or open a full terminal.
Share a web app with a link. Pick which sites the agent can reach. Every connection is logged.
Put files in and take files out. Keep a folder after the sandbox is gone.
See every step the agent takes, live. Send it to your own tools with OpenTelemetry.
API key = fake-keyAPI key = real key ••••The agent only sees a fake key. Spawnbox swaps in the real one on the way to sites you allow.
Idle sandboxes pause by themselves to save room. Wake one up, save it, or make copies.
Make up to 16 copies of a running sandbox, with everything in it, in under 1 s.
Add servers when you need more room. You talk to one main server, and it starts each sandbox on the server with the most space.
We checked each project's own website on 8 Nov 2026. Spawnbox is not the cheapest cloud or the fastest start. It is made to be easy to run yourself, to serve many customers, and to log everything agents do.
| Spawnbox | E2B | Daytona | microsandbox | CubeSandbox | InstaVM | |
|---|---|---|---|---|---|---|
| Open source | ●Apache-2.0 | ●Apache-2.0 | ○Repo archived Oct 2026; core moved private | ●Apache-2.0 | ●Apache-2.0 | ?Not stated |
| Run it on your own server | ●One install script | ●Docker Compose or Terraform | ○Open-source repo no longer maintained | ◐Runs locally as a child process; beta | ●KVM x86_64 host | ○Cloud service; local tool for development |
| How sandboxes are kept apart | ●Firecracker microVM | ●Firecracker microVM | ?Dedicated kernel; technology not named | ●microVM | ●KVM microVM (RustVMM) | ●microVM |
| Works on servers without KVM | ●Uses gVisor instead | ○KVM required | ?Not stated | ◐Needs KVM, Apple Silicon or Windows WHP | ○KVM required | ?Not stated |
| Many customers, each with own keys and limits | ●Own keys, limits, secrets, site rules | ◐Auth and quotas | ◐Organizations, API keys, limits | ?Not stated | ◐Per-sandbox traffic tokens | ◐API keys, volume quotas |
| API keys stay outside the sandbox | ●Added outside the sandbox | ?Not stated | ?Not stated | ●Never enter the VM | ●Credential vault via egress proxy | ●Injected via a proxy |
| Pause and resume | ●Pauses by itself, wakes in ≈65 ms | ●Auto-pause | ◐Snapshots | ●Stop, start, snapshots | ●Auto-pause and resume | ●Pause, snapshot, resume |
| Copy a running sandbox | ●Up to 16 copies, < 1 s | ●Up to 100 per request | ?Not stated | ●msb fork | ◐Fork from a checkpoint | ◐Clone a VM |
| Also sold as a hosted cloud | ○None, by design | ●E2B Cloud, BYOC | ●Daytona cloud | ?Not stated | ?Not stated | ●InstaVM cloud |
You need a Linux server: Ubuntu 22.04+ or Debian 12+, x86_64. KVM is best, but not required.
spawnbox command or the HTTP API.WARNING Sandboxes run code you do not trust. Use a separate server, not your own laptop or a live production server.