Short answers, real commands.

For running AI-written code we rank Sandboxer, Freestyle and E2B first: each gives code its own VM with an API or SDK and can pause with memory. Pick Daytona for Windows or GPUs, Modal or Northflank for GPUs at scale, E2B or Northflank to run in your own cloud, and Vercel Sandbox if your app lives on Vercel.

For coding agents we rank Sandboxer first: a full Ubuntu VM with Claude Code and Codex preinstalled, Docker, and stop-and-resume that keeps the agent's session in memory. Freestyle and Amp Orbs also keep memory across pauses. Pick E2B for prebuilt agent templates on open source, Docker Sandboxes for free local runs, and Codespaces if you live in GitHub.

The best Daytona alternatives depend on why you're switching. For a full Linux microVM on every sandbox with memory-saving stop and Docker, we rank Sandboxer first. E2B suits open source and self-hosting, Modal massive short-job fleets, Northflank bring-your-own-cloud with GPUs, and Vercel Sandbox apps on Vercel.

If you're leaving E2B for longer sessions or a fuller machine, we rank Sandboxer first, then Freestyle: both give each sandbox a full Linux VM that keeps memory across pauses, with Docker and no short session cap. Pick Daytona for Windows or GPUs, Northflank for bring-your-own-cloud, and stay on E2B if you need open source.

For sandbox use rather than GPU work, we rank Sandboxer first, then Freestyle and E2B: each gives a sandbox its own VM kernel instead of Modal's default gVisor, and keeps memory across pauses. Pick Northflank for GPUs in your own cloud, Vercel Sandbox for apps on Vercel, and stay on Modal for GPUs or very large numbers of short jobs.

For agents that must drive a whole desktop, we rank Sandboxer first: a Linux VM with an XFCE desktop and Chrome, computer-use tools for its built-in agents, and a live stream you can watch. Pick E2B or Daytona for desktop SDKs (Daytona and Orgo for Windows), and Browserbase, Kernel or Anchor when the agent only needs a browser.

Run it in a disposable microVM that holds none of your secrets, then throw it away. We rank Sandboxer first for full Linux microVMs with a no-secrets mode, then E2B, Vercel Sandbox and Cloudflare Sandbox. Use OpenAI's Code Interpreter for quick analysis inside the OpenAI API, and microsandbox or Firecracker to run microVMs yourself.

For coding agents we rank Sandboxer first: a full Ubuntu microVM per agent with root, Docker and agents preinstalled, which keeps memory across a stop. Prized and exe.dev also give agents full Linux boxes. Pick Codespaces if your work lives in GitHub, Namespace for macOS, Lightning AI for GPUs, and Ona for environments inside your own VPC.

For a hosted microVM you can treat as a whole Linux machine, we rank Sandboxer (Cloud Hypervisor) first, then E2B and AWS Lambda MicroVMs (Firecracker), all of which keep memory across a pause. Pick Unikraft Cloud for millisecond scale-to-zero, Northflank for bring-your-own-cloud, and self-hosted Firecracker or microsandbox to run microVMs yourself.

Connect your agent to a cloud VM it can control through MCP or an API. We rank Sandboxer first: its MCP server lets Claude, Codex or Cursor create Ubuntu microVMs, run commands, edit files, publish ports and stop them. Freestyle and E2B give agents full VMs too; Orgo offers a hosted MCP server, and Daytona and Coasty computer-use APIs.

In ChatGPT on the web, open Plugins, click +, choose Add custom MCP server, enter https://sandboxer.com/mcp with OAuth, create and install the plugin, then type @ in a chat. OpenAI lists full MCP, including the write tools that run code, for Business and Enterprise/Edu. Developer mode is no longer required.

In Claude, open Customize > Connectors, click + Add, then Add custom connector. Name it Sandboxer, enter https://sandboxer.com/mcp, choose Sign in now, then sign in to Sandboxer and click Allow. Turn it on from + > Connectors in a chat, and Claude can create Linux sandboxes, run commands, serve ports and delete them.

Use the hosted server at https://sandboxer.com/mcp if you want nothing to install, browser sign-in, or web clients like claude.ai and ChatGPT. Use the local stdio server (sbx mcp or npx -y sandboxer-mcp) if you want default sizes and auto-stop for every sandbox, or the handoff_session tool. Both create the same cloud microVMs.

Define an AI SDK tool() with a zod inputSchema for language and code. In its execute function, create a Sandboxer sandbox with sandboxer-sdk, write the code to a file, run it with exec and return stdout, stderr and the exit code. Pass the tool to generateText, then delete the sandbox when the run ends.

Wrap sandboxer-sdk calls in @function_tool functions, so the agent's shell commands and file reads run in a cloud Ubuntu VM, and add a download tool that copies results to your machine. Or write no tool code at all: connect MCPServerStreamableHttp to https://sandboxer.com/mcp with a Bearer API key and get 18 tools.

Run the agent inside the sandbox when its built-in Bash and file tools should only ever touch a disposable VM and it works for long stretches alone. Keep the agent on your server and give it Sandboxer as an MCP tool when your keys and app state must stay with you and only code execution needs isolating.

Write a CrewAI BaseTool whose _run sends the agent's Python to a Sandboxer microVM through sandboxer-sdk, then pass it in the agent's tools list. The sandbox starts on the first call and keeps files and packages between calls. CrewAI's own CodeInterpreterTool has been removed, and CrewAI now points you to a sandbox service.

Write a LangGraph tool that sends the model's Python to a Sandboxer microVM with the Python SDK and returns stdout, stderr and the exit code. Key the sandbox by the graph's thread_id, so each conversation keeps its own files, give every run a timeout, and delete or stop the sandboxes when the graph is done.

Give the agent one tool that runs Python in a Sandboxer microVM. Upload the CSV with the Python SDK, install pandas and matplotlib once per sandbox, let the tool run the model's code, then pull each chart PNG back with files.read_bytes and return the printed table. Reuse the sandbox for follow-up questions.

Install ipykernel and jupyter_client in a venv inside a Sandboxer sandbox, start the kernel with sbx exec --detach, and send each cell through a small client script. Variables persist between calls. In our test the same kernel and its variables survived sbx stop and sbx resume; a cold boot loses them, so check the kernel after resuming.

Start a Sandboxer sandbox and open its desktop once with sbx desktop, which starts XFCE with Chrome on display :1. Give your agent two kinds of tools that run inside it, a screenshot (ffmpeg x11grab) and actions (xdotool click, type, key), and loop. The desktop URL lets you watch the screen live.

Run Postgres in a Sandboxer microVM with Docker, load your schema and sample rows, and save it as a named snapshot. Give the agent a run_sql tool that runs each candidate query as a read-only role, inside a read-only transaction with a statement timeout, and returns the rows or the exact Postgres error.

Set up the task once in a sandbox and save it as a named snapshot. Start each episode in a fresh sandbox with sbx new --from, or sbx fork the running setup sandbox. The episode runs your policy and grader, writes a reward file you read back, and the sandbox is deleted. A fork copies disk only, never memory.

Have CI create one small sandbox per pull request, labelled with the PR number. It checks out the PR head, builds, serves the app and runs sbx host for an HTTPS URL you post on the PR. Idle previews pause and wake on the next visit. When the PR closes, find the sandbox by label and delete it.

Every Sandboxer VM has Google Chrome installed. Install Playwright or Browser Use with uv, point it at that Chrome, and run headless right away. To watch, open the desktop with sbx desktop, then launch Chrome headed on display :1, and it appears in the live stream in your browser.

Either keep GitHub's hosted runner and have the job call sbx to create a sandbox, copy the checkout in, run the tests there and delete it, or start a sandbox per job that registers an --ephemeral self-hosted runner, takes exactly one job and is then deleted.

Run the official SWE-bench harness inside a Sandboxer sandbox. Each sandbox is a microVM with its own Docker daemon, so the harness pulls the per-task image, applies the candidate patch, runs the task's tests and grades FAIL_TO_PASS and PASS_TO_PASS. Save one prepared sandbox as a snapshot and start one VM per task.

Create a large Sandboxer sandbox, which has /dev/kvm, install the Android command-line tools and an x86_64 system image, and start the emulator with -accel on. It cold-boots Android 15 in about 30 seconds. Run it headless and drive it with adb, or put its window on the sandbox's desktop and watch it in your browser.

No. sbx fork copies a running sandbox's disk into a new, independent sandbox in a few seconds, but the copy boots fresh, so no RAM and no running processes come across. Files written up to the fork are there. To keep memory, stop and resume the same sandbox, or run long-lived work as systemd services that save state to disk.

Use sbx scp for files and folders of any size, in either direction. From code, the SDK and MCP read and write single files up to 5 MiB, and the SDK downloads up to 50 MiB. Clone repos inside the sandbox with git, and pull files from a stopped sandbox's snapshot without resuming it.

Set up one sandbox the way you want it, then save its disk under a name with sbx snapshot, passing the sandbox id and the name. Every sbx new --from with that name starts a new sandbox with your packages and files already in place. sbx snapshot rm deletes the template.

Run sbx ssh-config --install once. It adds a Host *.sbx entry to ~/.ssh/config that tunnels through the sbx CLI over HTTPS, so ssh, rsync and VS Code or Cursor Remote-SSH reach any sandbox as <id>.sbx, with no open ports and no keys to manage by hand.

Start your server on a port, then run sbx host <id> <port>. You get https://<subdomain>-<port>.box.sandboxer.com with TLS and WebSockets. It is private by default: requests without the URL's _token get 401. Add --public for an open URL, or --localhost for apps bound to 127.0.0.1.

Start the job with sbx exec --detach, which returns a process id at once, then close your terminal. Later, sbx exec --status shows whether it's still running, its exit code and the end of its output. Extend auto-stop past the job's length, because a running job keeps the sandbox awake but doesn't hold off auto-stop.

Copy your compose.yaml into a Sandboxer sandbox, run docker compose up -d (Docker and Compose are preinstalled), then run sbx host for each published port. Each service gets its own HTTPS URL. A memory-restoring stop and resume keeps containers running; add restart unless-stopped so they also come back after a cold boot.

Yes. A Sandboxer sandbox pauses itself after idleStopMinutes without activity (15 to 120 minutes by default, depending on your plan). Pausing is a stop with memory, so compute isn't billed. The next API call or request to one of its hosted URLs wakes it. Set it with sbx new --idle or sbx idle.

Exit code 137 means the kernel's OOM killer sent SIGKILL because the sandbox ran out of RAM; "No space left on device" (ENOSPC) means the disk is full. Fix both the same way, with sbx stop and then sbx resume --type and a bigger size. Your files stay; running processes don't, so restart the job.

Yes. A Sandboxer sandbox is a full VM with Docker preinstalled, so kind create cluster gave us a Ready node in about 28 seconds in one run on a default sandbox, and the k3s install script about 13 seconds. Deploy with kubectl, expose the app with port-forward or a NodePort, then sbx host the port for an HTTPS URL.

Install Ollama with its Linux script in a default sandbox, pull a small model such as qwen2.5:0.5b, and bind it to 0.0.0.0 with a systemd override. Then sbx host the port for a private HTTPS URL. There is no GPU: expect about 30 to 55 tokens per second for 0.5B and 13 to 22 for 1B.

Install Ollama in a default Sandboxer sandbox, pull a small model, then run the official Open WebUI Docker image with --network=host and OLLAMA_BASE_URL=http://127.0.0.1:11434. Host port 8080 with sbx host: the URL is private by default, chat streams through it, and your account and chats survive stop and resume.

Download the prebuilt Linux x64 build from llama.cpp's GitHub releases, fetch a GGUF model from Hugging Face with curl, and run llama-server on 0.0.0.0 as a systemd service. Then sbx host the port for a private HTTPS URL that any OpenAI client can call. A 0.5B model generated 35 to 48 tokens per second on default.

Clone whisper.cpp, build it with cmake, fetch base.en or small.en with its download script, and run whisper-cli on 16 kHz WAV. On a 4-vCPU default sandbox, base.en ran 13x faster than realtime and small.en 5x. whisper-server behind a private sbx host URL accepts file POSTs.

Run n8n's Docker image in a Sandboxer sandbox with a volume and --restart unless-stopped, set N8N_HOST, N8N_PROTOCOL and N8N_WEBHOOK_URL to the hosted address, then run sbx host 5678. The editor and webhooks answer on https://<subdomain>-5678.box.sandboxer.com, private by default; go public only for callers that can't send a token.

Create a default Sandboxer sandbox, install the Supabase CLI from its .deb release, then run supabase init and supabase start. Docker is preinstalled. The first start took about 100 seconds. Host port 54323 (Studio) and 54321 (API) with sbx host for private HTTPS URLs. A memory-restoring stop and resume keeps the stack running.

Run the official pgvector/pgvector:pg17 Docker image in a Sandboxer microVM with --shm-size=1g and --restart unless-stopped, then create the vector extension and an HNSW index. On 10,000 random 384-dimension vectors, a top-10 query took 6 to 7 ms without the index and 2.6 to 5.9 ms with it.

Redis 8 replaces Redis Stack, so run the official redis:8 image in a Sandboxer microVM with AOF on and --restart unless-stopped. JSON, search and vector sets are built in. Put Redis Insight on a private sbx host URL with --localhost, and reach Redis from your laptop with redis-cli over ssh -L. Data survived stop and resume.

Run the official mysql:8.4 or mariadb:11.8 Docker image in a Sandboxer microVM, bound to 127.0.0.1 with --restart unless-stopped. Load the Sakila sample database, then reach it from your laptop with ssh -L through the stanza sbx ssh-config prints. Data survived a stop and resume.

Run the flowiseai/flowise:3.1.3 Docker image in a small Sandboxer sandbox with a volume on /home/node/.flowise, bound to 127.0.0.1:3000, and host it with sbx host --localhost. Create the admin account first. Scripts call the prediction API with a Cookie __sbx_auth header plus a Flowise API key.

Run the official mongo:8.0 Docker image in a Sandboxer microVM with a named volume, --restart unless-stopped and a port bound to 127.0.0.1, then connect from your laptop through an ssh -L tunnel. On 29,353 zip code documents, an index on city cut a query from scanning every document to reading 41.

Install code-server with its official install script, set bind-addr 0.0.0.0:8080 in its config, enable the code-server@user systemd service, then run sbx host <id> 8080. The private hosted URL's token gates the editor, terminal WebSockets included, so auth none is safe as long as the port stays private.

Run the official Redpanda image in a Sandboxer microVM with two listeners, one for containers and one advertised as localhost:19092, then reach it from your laptop with sbx forward. Kafka is TCP, so it doesn't go through a hosted HTTPS URL; Redpanda Console does. rpk produced 100,000 messages in about 0.2 seconds.

Install JupyterLab with uv in a venv, run it as an enabled systemd service on 0.0.0.0:8888 with its own token turned off, and host the port with sbx host. The private hosted URL's token then guards the Lab page, the REST API and the kernel websocket. Notebooks and running kernels survived sbx stop --wait and sbx resume.

Run the official metabase/metabase Docker image in a Sandboxer microVM with a volume for its application database, then host port 3000 on a private URL. It was healthy about 15 seconds after the JVM started, used 1.3 to 1.8 GB of RAM, and answered Sample Database queries in 5 to 20 ms.

Put Prometheus, node_exporter and Grafana in one compose.yaml with a provisioned data source and dashboard, run docker compose up -d in a default Sandboxer sandbox, and host only Grafana's port 3000 with sbx host. Prometheus stays internal, the URL is private by default, and data and logins survive stop, resume and reboot.

Install Airflow with pip and its constraints file in a venv, run airflow standalone as a systemd service with the venv on PATH, and host port 8080 on a private URL. In our run, Airflow 3.3.2 installed in 6 seconds, was healthy 9 seconds after a cold boot, and a REST-triggered three-task DAG finished in 5 to 8 seconds.

Install the Temporal CLI, run temporal server start-dev with --db-filename under systemd, and host the Web UI on port 8233 with sbx host --localhost. On a small sandbox the server was ready in 1.5 s and a one-activity workflow took about 100 ms. History survived stop, resume and a cold boot.

Start the official Selenium hub, Chrome and Firefox node images with Docker Compose in a default Sandboxer sandbox, host port 4444 with sbx host, and pass the URL's token to webdriver.Remote as a cookie header. Our remote tests passed on both browsers; each WebDriver command took about 136 ms from outside and 7 ms inside.

Install the no-GUI LibreOffice packages with apt, then pass all your files to one soffice --headless --convert-to pdf call. In our test, 50 DOCX files took 6 seconds that way, 51 seconds as one call per file, and 2.6 seconds split across 4 processes, each with its own profile.

FFmpeg 6.1.1 with x264, x265, SVT-AV1, VP9 and Opus is preinstalled in every sandbox, so a pipeline is one script. On 60 seconds of 1080p video, a 720p H.264 encode took 18 s on small and 13 s on default. A full 10.5-minute film took 188 s and 113 s.

Every Sandboxer VM has Google Chrome, so google-chrome --headless --print-to-pdf works right away. Add --virtual-time-budget so page scripts finish, and install fonts-noto-cjk for Asian text. For page numbers, margins and waiting on a selector, use Playwright's page.pdf(). One browser printed 50 pages in about 2 seconds.

Run the official Home Assistant Container image in a Sandboxer sandbox and host port 8123 with sbx host. Write an http block that trusts the sandbox's gateway as a reverse proxy before the first start, or every request through the URL gets 400 Bad Request. Onboarding, the REST API and WebSockets then work.

Run the official gitea/gitea Docker image in a Sandboxer microVM with SQLite and --restart unless-stopped, then host port 3000 privately. Git can't use the ?_token= link, so give git the __sbx_auth cookie with http.extraHeader and use a Gitea access token as the password. Push and clone then work over HTTPS.

MinIO's community edition is now source-only, so build it with go install inside a Sandboxer sandbox (93 seconds on default), run it as a systemd service and point the AWS CLI at it with --endpoint-url. A 1 GiB upload took 2.2 to 2.5 seconds inside the VM, and the S3 port worked on a hosted HTTPS URL.

Run the official getmeili/meilisearch Docker image in a Sandboxer microVM with a master key, a named volume and --restart unless-stopped, then host port 7700. We indexed 31,944 movies in 5.8 s; typo-tolerant searches took 0 to 2 ms in Meilisearch and 191 ms round trip from a laptop.

Run the official qdrant/qdrant Docker image in a Sandboxer microVM with an API key, bound to 127.0.0.1, then publish it with sbx host --localhost. On a small sandbox, 20,000 vectors of 384 dimensions loaded in 2 seconds and a filtered top-10 search took 4 ms inside the VM.

Run the chromadb/chroma Docker image in a Sandboxer microVM with a named volume and --restart unless-stopped, host port 8000 on a private HTTPS URL, and give the Python HttpClient the URL's auth cookie as a header. Our query took about 2 ms inside the VM and 129 ms from outside.

Run the official OpenSearch 3 and OpenSearch Dashboards images with Docker Compose in a default Sandboxer sandbox, keep port 9200 inside the VM, and host Dashboards on port 5601 behind a private URL. Both were green 80 seconds after a cold pull, and searches answered in about 14 ms.

Install Streamlit in a venv, run it as a systemd service on port 8501, then run sbx host <id> 8501. The private URL's token gates the page and the /_stcore/stream WebSocket. Keep Streamlit's CORS and XSRF protection on: uploads and reruns worked through the proxy with the default settings.

Install Gradio in a venv, launch with server_name="0.0.0.0", run it as a systemd service and host port 7860 on a private URL. To call it from gradio_client, trade the URL's _token for the proxy's cookie and pass it in headers. Our calls took about 0.6 seconds each.

Run next dev on port 3000 in the sandbox and host the port with sbx host. The page loads right away, but hot reload stays broken until you add "*.box.sandboxer.com" to allowedDevOrigins in next.config.ts and restart. Then edits made in the sandbox show up in the browser in under a second.

Run storybook dev on port 6006 in a sandbox, add .box.sandboxer.com to core.allowedHosts, set Vite's hmr.clientPort to 443, then run sbx host <id> 6006 --localhost. Keep that dev URL private. For a link anyone can open, run storybook build, serve storybook-static and host that port with --public.

Run hugo server with --baseURL set to the hosted URL, --appendPort=false and --liveReloadPort 443, or run astro dev with server.allowedHosts set to .box.sandboxer.com, then sbx host the port. Live reload works through the private URL. A 300-page build took about 0.15 s in Hugo and 4.2 s in Astro.

Download the PocketBase binary into a small Sandboxer sandbox, create a superuser with its CLI and run it as a systemd service on port 8090. sbx host gives the dashboard and API a private HTTPS URL. Clients send the __sbx_auth cookie plus PocketBase's own token. Records and a live realtime stream survived stop and resume.

Run the official rabbitmq:4-management Docker image in a Sandboxer microVM with both ports bound to 127.0.0.1. Reach AMQP on port 5672 from your laptop with sbx forward, and the management UI on a private HTTPS URL with sbx host --localhost. AMQP itself doesn't pass through hosted URLs. Persistent messages survived stop, resume and a broker restart.

Run the official Keycloak image with start, --hostname set to the sandbox's https hosted URL, --proxy-headers xforwarded and --http-enabled true, then host port 8080 with sbx host. Without the hostname setting, Keycloak builds http:// links, so the admin console fails on mixed content and tokens carry the wrong issuer.

Install Vault from HashiCorp's apt repo, run vault server -dev under systemd, and vault kv put and kv get work at once. The dev server is in-memory and unsealed, for learning and testing only. Its secrets survived stop and resume with memory, and were gone after a restart or a cold boot.

Install pandoc from its GitHub .deb and the Typst binary (248 MB together, about 2 seconds on a small sandbox), then run pandoc --citeproc --pdf-engine=typst. Typst rendered our report in 0.3 seconds; xelatex took 1.6 seconds after a 467 MB, 47-second TeX Live install. Use --reference-doc for DOCX and --embed-resources for HTML.

Install MLflow with uv, run mlflow server as a systemd service on 127.0.0.1:5000 with SQLite and local artifacts, and host it with sbx host --localhost. Put the hosted hostname in --allowed-hosts and --cors-allowed-origins or MLflow answers 403. Your laptop logs runs by sending the URL's __sbx_auth cookie.

Run the excalidraw/excalidraw Docker image and the excalidraw-room server behind one Caddy port in a small sandbox, point the client at your room server, and host the port with sbx host --localhost. Drawings stay in each browser; the room server relays encrypted updates, but the stock image still saves encrypted rooms to Excalidraw's Firebase.

Run the official wordpress and mariadb images with Docker Compose in a Sandboxer sandbox, bind WordPress to 127.0.0.1 and host it with sbx host --localhost. Install with WP-CLI using the hosted HTTPS URL as the site URL. The image already trusts X-Forwarded-Proto, so login, wp-admin and permalinks work.

Run docker run -d --restart unless-stopped -p 3001:3001 -v uptime-kuma:/app/data louislam/uptime-kuma:1 in a small Sandboxer sandbox, then sbx host <id> 3001 for a private HTTPS URL. It suits trying Uptime Kuma or watching apps in the same sandbox. No checks run while the sandbox is stopped, and Kuma doesn't flag that gap.

Install ocrmypdf with apt, which brings Tesseract 5.3.4, then run ocrmypdf --deskew --jobs N in.pdf out.pdf. On a 45-page typewritten scan, a 4-vCPU default sandbox took 2.2 seconds per page with 4 jobs, and a 2-vCPU small one 3.6 seconds with 2 jobs. Add languages with tesseract-ocr-<lang> packages.

Host port 2368 with sbx host first, then start the ghost and mysql images with Docker Compose and the hosted HTTPS URL as Ghost's url. Turn off staff device verification unless you configure mail, or a second login fails. Publish from a laptop with an Admin API key plus the __sbx_auth cookie.

Run the heartexlabs/label-studio Docker image on 127.0.0.1:8080 with a data volume, host the port privately with --localhost, and set CSRF_TRUSTED_ORIGINS to the hosted URL or every login fails with a 403. Use a personal access token for the API. It used about 210 MiB of RAM on a small sandbox.

Run NocoDB and Postgres with Docker Compose in a small Sandboxer sandbox, create the admin from environment variables and host port 8080 with sbx host --localhost. Scripts send the __sbx_auth cookie plus an xc-token API token. Turn on invite-only signup, because anyone with the private link can otherwise register.

Run the official searxng/searxng Docker image in a small Sandboxer sandbox, add json to search.formats, set a random secret_key, turn the limiter off, bind it to 127.0.0.1 and host it with sbx host --localhost. Agents then call /search?format=json with the __sbx_auth cookie. Which engines answer depends on upstream blocking.

Install @modelcontextprotocol/inspector with npm in a sandbox, run its web UI as a systemd service on 127.0.0.1:6274 with ALLOWED_ORIGINS set to the hosted origin, and host it with sbx host --localhost. Keep that URL private. The Inspector page hands its API token to anyone who loads it, and its backend runs any stdio command it is given.

Clone the Langfuse repo into a sandbox, write a .env with fresh secrets, NEXTAUTH_URL set to your hosted URL and headless-init API keys, publish port 3000 on 127.0.0.1 and run docker compose up -d. Host it with sbx host --localhost. The Python SDK sends traces through the private URL with the __sbx_auth cookie.

Clone Dify's release into a default Sandboxer sandbox, set CONSOLE_API_URL, CONSOLE_WEB_URL, SERVICE_API_URL, APP_API_URL, APP_WEB_URL and FILES_URL to the hosted address, bind nginx to 127.0.0.1:8080, run docker compose up -d and sbx host 8080 --localhost. Callers send the __sbx_auth cookie plus Dify's app key.

Run Umami's official Docker Compose stack in a small Sandboxer sandbox and keep its dashboard on a private URL. Visitors' browsers can't send the private URL's cookie, so add a small Caddy collector that exposes only /script.js and /api/send on a second, public URL. Countries come through correctly.

Create a Strapi 5 app with create-strapi in a small Sandboxer sandbox, build the admin panel and run strapi start under systemd on 127.0.0.1:1337. Host it with sbx host --localhost. Set proxy.koa so login cookies are Secure. Clients send the __sbx_auth cookie plus a Strapi API token.

Send an Idempotency-Key header on POST /sandboxes and on fork, and reuse it on every retry. For 24 hours, the same key and body return the same sandbox instead of a second billable one. Retry 429, 5xx and network errors with backoff. Don't retry other 4xx errors, because the request itself has to change.

Prepare the repo once in a sandbox. Fork it once per attempt with sbx fork, apply each attempt in its own fork, run the test suite there, and save its git diff and score. Delete each fork when it is scored, keep the diff with the most passing tests, and apply it locally with git apply.

Use a fresh sandbox per call when the input is untrusted or calls must not see each other. Start it from a pre-warmed named snapshot: on prod that took 3.2 seconds per call versus 12.9 seconds installing dependencies each time. Reuse one sandbox per session when calls build on each other: 0.55 seconds per call.

Start the sandbox with --no-env so it holds none of your account's secrets, then pass only what the task needs with -e, stdin or a file you delete after use. Never put a secret in a command line: sbx history stores every exec command for 90 days, and ps shows arguments to every process.

Install dependencies once in a sandbox, save it with sbx snapshot under a name that includes a hash of your lockfiles, and start each job with sbx new --from that name. On prod this replaced about 51 seconds of npm, uv and pip installs with a hash check. Rebuild the snapshot when the hash changes.

Read memoryRestored after every resume. true means memory came back and processes kept running. false means the sandbox booted from disk, and resumeReason says why (cpu_mismatch, resized, no_memory_snapshot or restore_failed). Inside the guest, compare /proc/sys/kernel/random/boot_id with a saved copy. On a cold boot, restart services and re-warm caches.

Start the command detached, attach to its output from your server with the SDK, and relay each chunk to the browser as Server-Sent Events. Use the byte offsets as event ids so a reconnect resumes with nothing lost or repeated. On prod, lines reached a Chrome page about 0.2 seconds after the sandbox printed them.

Stack the levers that exist. Per sandbox, pick a small size, a short TTL and an idle timeout, and delete it when the task ends. Per key, give agents scoped, expiring keys. Per account, your plan's concurrency and start limits, a prepaid balance without auto-refill and alerts set the ceiling. A watchdog deletes stragglers.

Label every sandbox at create with an owner and run id, then list by that label (GET /sandboxes?labels=…), check state and lastActivityAt, and delete with a dry run first. A TTL and idle pause stop forgotten sandboxes but keep their storage. Deleting removes automatic snapshots and hosted URLs; named snapshots stay.

Poll the real request, not the port. Inside the sandbox, loop curl against a health URL with a timeout. From outside, poll the hosted URL and ignore Sandboxer's own pages (they end in "Sandboxer · HTTP" and the status): 502 means nothing is listening yet. In our test, Grafana's port opened at 0.4 s but answered at 3.1 s.

Size a client-side semaphore to your plan's free sandbox places from GET /limits, pace starts under the per-minute limit, and branch on the error code. Wait for Retry-After on rate_limited, queue on limit_reached, try the next size on no_ready_machine or capacity_exceeded, back off with jitter on 5xx, and give up on other 4xx.

Yes, for any server you didn't write or that holds a secret. Run each one in its own --no-env sandbox with only its own -e variables, bridge stdio servers to Streamable HTTP on 127.0.0.1, host each port privately, and connect your client to every URL with its own __sbx_auth cookie header.

Install the project once, save it with sbx snapshot, then start one sandbox per shard with sbx new --from and run pytest-split's --splits N --group i in each. Copy each JUnit file back, merge them and delete the sandboxes. On prod, two small shards cut the networkx 3.5 suite from 96.9 s to 59.3 s.

Use a systemd timer with OnCalendar and Persistent=true, or cron. Neither fires while the sandbox is stopped or idle-paused. On a memory resume, missed wall-clock jobs run right away; elapsed-time timers don't count the stopped time. On a cold boot, only Persistent=true catches up. For exact schedules, keep it awake or schedule from outside.

Pipe sbx and it prints JSON, so jq can read every result. Most commands print one object with a type field. sbx new and sbx resume print JSON Lines events ending in ready, so select that event for the id. Errors go to stderr as an error event, and the exit code tells you what failed.

Every start method survives a resume that restores memory. Only an enabled systemd unit with Restart=always, or a Docker container with --restart unless-stopped, also comes back after a cold boot, a reboot and a killed process. nohup, sbx exec --detach and systemd-run are gone after any boot.

Wrap the run in a systemd scope, sudo systemd-run --scope -p MemoryMax=1G -p CPUQuota=100% -p TasksMax=256 -p RuntimeMaxSec=60. On a real sandbox a memory hog died with exit 137, a fork bomb stalled at 200 tasks, and the agent's own processes kept running. Use timeout, ulimit or a loop-mounted disk for narrower caps.

Run a small service with a task queue and a few workers. Each worker starts a sandbox from a named snapshot of your repo, runs the agent and the tests there, pulls the commit back as a git bundle, pushes the branch with the service's own credentials for review, reports status, and deletes the sandbox.

Yes, if the work is on disk. Stop the sandbox, then sbx resume --type with a bigger size. In our test that took about 6 seconds, and files came back while processes and memory did not (memoryRestored false, resumeReason resized). Have the agent checkpoint to disk so it can continue after the cold boot.

A Sandboxer sandbox auto-stops one hour after it starts unless you change that. Set a deadline up to 30 days, renew it while the job runs, or turn it off with --no-auto-stop (the trial caps it at 8 hours). A stop keeps disk and memory unless snapshots are off.

Run a small proxy on your own machine that holds the real key and adds it to each request. Expose it inside the sandbox with sbx forward --reverse, and give the agent only a proxy token you can revoke. The key never enters the VM, and every call is logged on your side.

Write a Playwright check for the change before the edit, and have the agent run it in the sandbox after every edit until it exits 0. It also fails on console errors. Then host the app and screenshots on private URLs for a human. Our scripted loop took 26 seconds.

Keep one agent and give each team a sandbox template. Save a versioned named snapshot per team with its CLI tools, MCP servers and instructions, label it with the team name, and have the agent create with fromLabels. Pin a release label to test a new version before the agent switches to it.

Give the agent no Sandboxer key, only a tool that calls a gate you run. Allowlisted read-only commands go straight to the exec API; anything else waits for a human yes at a terminal or a local web page. Only the gate holds a short-lived key scoped to one sandbox, and sbx history shows exec commands that went around it.

A new sandbox already has Python 3.12.3 and uv 0.13.1. Run uv python install for another version, clone your project, run uv sync --frozen and uv run pytest. Connect VS Code through sbx ssh-config, then save the sandbox as a named snapshot so the next one starts with Python, venv and cache ready.

A new sandbox has Node 22.23.3 and pnpm 12.14, and pnpm switches itself to the version in your packageManager field. For a newer Node, install fnm and run fnm install 24. Clone your repo, run pnpm install --frozen-lockfile, then save a named snapshot so the next sandbox skips the 11.7-second cold install.

A new sandbox has Bun 1.4.3 in /usr/local/bin, which bun upgrade can't overwrite without root. Bun's install script puts 1.4.4 in ~/.bun/bin, already first on PATH. Elysia installed 219 packages in 0.4 seconds from an empty cache, a migrated pnpm project in 1 second, and bun build --compile cross-compiled a server for macOS.

Deno is not in the sandbox image. The official install script added Deno 2.9.8 in 1.9 seconds. Its caches live in ~/.cache/deno on the sandbox disk, so a named snapshot cut a cold dependency install plus type check of the Fresh repo from about 20 seconds to about 6.

A new sandbox has Go 1.27.2 in /usr/local/go. Installing the current release from go.dev took 3 seconds. Modules cache in ~/go/pkg/mod and builds in ~/.cache/go-build, both on the sandbox disk, so a named snapshot cut a cold 87-second build of the GitHub CLI to 4.6 seconds.

A new sandbox already has Rust 1.99.1 through rustup, so clone and run cargo build --release. On 2026-10-27 a clean release build of ripgrep 15.1.0 took a median 36.4 s on small, 19.5 s on default and 12.6 s on large, about $0.0002 each. Save the target directory in a named snapshot to skip rebuilds.

Java isn't preinstalled. Add Adoptium's apt repository and install temurin-25-jdk, plus the JDK your Gradle toolchain asks for. On prod, Spring PetClinic built and tested in 142 seconds with empty caches, about 73 with a warm Gradle cache and daemon, and a build in a sandbox started from a named snapshot was up to date in 17 seconds.

A new sandbox has no .NET. Microsoft's dotnet-install.sh put SDK 10.0.403 in ~/.dotnet in 10 seconds. A first build of a real ASP.NET Core solution took 22 seconds on small; from a named snapshot with the NuGet cache and bin/obj, it took 2.7 seconds. Raise the inotify limit before running two dotnet watch sessions.

A new sandbox has no PHP. apt-get install php-cli gave Ubuntu's PHP 8.3.6 in 11 seconds; the ondrej/php PPA that php.net lists gave 8.5.12 in 56. Install Composer with its signature check, serve Laravel on 127.0.0.1, host it privately, and trust the 127.0.0.1 proxy or Laravel builds http:// links.

A new sandbox has no Ruby. Install rbenv and ruby-build, then rbenv install 4.0.9, which compiled in 4.4 minutes on small. Bundle a real Rails app, add libvips, run its tests, and save a named snapshot so the next sandbox has Ruby and every gem ready in seconds.

Create a cloud Ubuntu VM with Claude Code already installed, give it your Anthropic key, then prompt it from your laptop or SSH in and run claude. The VM keeps working when your laptop sleeps, and stopping it saves memory so the session resumes where it left off.

Only inside an isolated machine you can throw away. The flag lets Claude Code run every command without asking, so run it in a disposable VM with no access to your laptop, your production credentials or your other secrets, as a non-root user, and keep what it produces on a branch you review.

Give each agent its own cloud VM instead of sharing one checkout. Set up your repo once in a Sandboxer sandbox, save it as a named snapshot, start one sandbox per task from it, and send each a prompt. Every agent gets its own disk, Docker and ports, so they never collide, and you keep the branches that worked.

Start a cloud VM where Codex CLI is already installed, sign in with codex login --device-auth or an API key, and run codex or codex exec there. On Sandboxer, sbx new gives you that VM in seconds, and you can also send Codex tasks from your laptop with sbx prompt --provider codex.

Use Claude Code's built-in sandbox to cut prompts in everyday work on your own machine. Use a dev container when the team wants one standard, firewalled setup. Use a cloud VM for unattended runs, untrusted repos, work that needs Docker or KVM, or tasks that must keep running while your laptop sleeps.

Use git worktrees when parallel agents only edit and test code. They separate files but share one machine's ports, hooks, home directory, credentials and services. When agents run dev servers, databases or Docker, give each one its own VM, so every agent can bind port 3000 and gets its own URL.

Create a Sandboxer VM, run OpenHands' own docker run command inside it (Docker is preinstalled and the socket mount stays inside your VM), then sbx host 3000 for a private HTTPS link. In one test run on October 27, 2026, the UI answered about 40 seconds after sbx new, on the default size.

Create a sandbox with --no-env so it holds none of your secrets, pass one short-lived fine-grained GitHub token as GH_TOKEN, then clone, branch, run the agent, run the tests, push and open the pull request with gh. Delete the sandbox at the end. Our test run, with no model and no push, took 33 seconds.

An AI agent sandbox is an isolated computer where an agent can run code, install packages and use tools without touching your own machine, accounts or other users. A good one is a separate VM with its own kernel, holds only the secrets the task needs, limits what it can reach, and can be stopped, copied or thrown away.

Stop the sandbox with sbx stop. Sandboxer writes the VM's memory and device state to disk along with its files, then shuts it down, so nothing is billed. sbx resume restores that memory, and your dev server, tmux session and agent continue from the instruction where they stopped, with the same process IDs.

Use a sandbox that is a full virtual machine rather than a container. A Sandboxer sandbox is a Cloud Hypervisor microVM with its own kernel, Docker preinstalled and /dev/kvm available, so an agent can run docker build, docker compose, kind, QEMU or the Android emulator inside it without mounting the host's Docker socket.

Use a microVM when the code is untrusted. A container is a set of Linux namespaces and cgroups on the host's own kernel, so a kernel bug or a mounted Docker socket can let code out. A microVM gives the code its own kernel behind hardware virtualization, which is a much smaller boundary to attack. gVisor sits in between.

Both are open-source Rust virtual machine monitors built on KVM and the rust-vmm crates. Firecracker, from AWS, is deliberately minimal and built for dense, short-lived serverless microVMs. Cloud Hypervisor, a Linux Foundation project, is a general-purpose cloud VMM with PCI devices, VFIO and GPU passthrough, virtio-fs, CPU hotplug, live migration and Windows guests.

Delete the sandbox when the task is one-off and its results already left the VM. Stop it instead when the next task needs the same files, packages or running processes: a stopped Sandboxer sandbox bills no compute, usually resumes with its memory, and counts toward your plan's included storage (50 GB on the $20 plan).

A microVM is a virtual machine run by a minimal virtual machine monitor, such as Firecracker or Cloud Hypervisor, on Linux KVM. It boots its own guest kernel, sees a handful of paravirtualized virtio devices instead of an emulated PC, and gets hardware isolation with far less boot time and memory than a full VM.

Measured from our machine on 2026-10-27 in eu-central, 10 runs per size: a new sandbox reported ready in a median 3.2 seconds, a resume with memory in 1.35 seconds, and a fork in 3.35 seconds. The first command then took about 0.2 seconds. Every figure includes CLI and network time.

Inbound, only ports you host on the HTTPS proxy, the SSH endpoint and the public IPv6 address reach a sandbox, and ufw closes IPv6 except SSH. Outbound, it reaches the internet. Other sandboxes, private ranges and port 25 are blocked. Sandboxer has no egress allowlist; restrict outbound yourself with ufw inside the VM.

Create one sandbox per user with noEnv, so none of your secrets are inside, and tag it with labels such as user=alice so you can find it again. Each sandbox is its own microVM, so one user can't read another's files or reach their VM. Call the API with a scoped key, and let idle sandboxes pause.

Six jobs: run the code a model wrote, give each user a separate VM, keep your secrets out of it, show users what is running on a URL, keep their state between visits, and cap what it all costs. On prod, a noEnv small sandbox was ready in 2.66 seconds and ran model-written Python in 0.16 seconds.

Build each task environment once and save it as a named snapshot. Start one fresh microVM per task with sbx new --from, cap parallel runs at your plan's concurrency and start limits, and copy each task's diff, test report and environment fingerprint out before you delete it. Billing is per second, CPU only.

Build the lab once in a sandbox and save it as a named snapshot. Before class, create one small --no-env sandbox per student from it, with a TTL and an idle timeout, and send each student their own private code-server URL or SSH access. Delete them all at term end. A 30-student, 2-hour lab on small costs $1.08.

Yes, for CPU-only work that fits in RAM. Pick the size by peak memory, not file size: loading every column of a 473 MB Parquet file was killed on small (4 GB) and fit on default (8 GB). Run JupyterLab as a service on a private URL, and stop the sandbox between sessions to keep kernels warm.

Set up the stack once, save it as a named snapshot and give teammates a share code, so each gets the same machine in about 3 seconds. Run the demo as a systemd unit, host it with sbx host --public, and set a TTL that outlasts judging. A small sandbox for 48 hours costs $0.86.

Run every bash block of a docs page, in order, in a fresh noEnv sandbox and compare stdout with the page's expected output, so stale samples fail before readers find them. Host the finished demo on a private HTTPS URL, start workshop machines from a named snapshot, and delete everything after. Billing is per second.

Run each suite in a fresh microVM that already has Chrome, Node, Python and Docker. Copy JUnit, screenshots and traces out before you delete it. Repeat suspect tests in a clean VM to measure flake rates, keep a failing VM by stopping it instead of deleting it, and share the build on a private URL.

Keep agents on a home box when they need your local network, your devices or a GPU you own, and one always-on machine is enough. Use cloud VMs when you want agents kept off your home network, several copies at once, snapshots to roll back or fork, and HTTPS URLs without opening ports.

Measured on 2026-10-27 in eu-central, 3 runs per size. Single-thread speed was about the same on every size, a sysbench median of 2,130 to 2,297 events per second. All-thread throughput scaled with vCPUs, 4,553 on small, 8,424 on default and 16,824 on large, so the cost per unit of work stayed within about 8%.

Measured with fio on 2026-10-27 in eu-central, 3 runs per size, one sandbox at a time. small, default and large each read and wrote 1M blocks at a median 4,200 to 5,800 MB/s and handled 140,000 to 250,000 random 4k IOPS. Size made no clear difference. Results vary by host and neighbors.

Measured on 2026-10-27 in eu-central, 3 runs per size. A cold docker pull of node:22 (408 MB compressed) took a median 15.7 to 16.0 seconds, python:3.12-slim 3.7 to 3.9 s and alpine:3.20 about 1.6 s. Sandbox size made no difference. An image already on disk, also after a resume, starts in 0.2 s.

Sign in once, then most work takes seven commands. sbx new creates a sandbox, sbx exec or sbx ssh runs commands in it, sbx scp moves files, sbx host gives a port an HTTPS URL, sbx stop pauses it with its memory, and sbx resume continues. The tables below map each task to its command.

Every Sandboxer API error is JSON with ok false, an HTTP status, a stable code, a message and a requestId. Branch on code. A 400 means fix the request, 401 or 403 the key or plan, 402 billing, 409 the sandbox's current state, 429 a limit, and 502 or 503 a machine or capacity problem worth retrying.

Every sandbox gets SANDBOXER_ID, SANDBOXER_SUBDOMAIN, SANDBOXER_API_URL and SANDBOXER_TOKEN, a key limited to that one sandbox. Add your own with sbx new -e KEY=value. Variables live in /etc/sandboxer/env, reach login shells and sbx exec, and reach systemd services that load that file.

Sandboxer bills per second while a sandbox runs. small costs $0.018 an hour, default $0.036, large $0.072 and xlarge $0.20. A default sandbox left on costs $0.864 a day or $26.28 a month. Stopped and idle-paused sandboxes bill no compute, and each plan's price comes back as machine time.

Short, exact definitions of 50 terms you meet when running code in a cloud sandbox, from microVM, KVM and Cloud Hypervisor to snapshot, fork, memory restore, idle pause, hosted port, sandbox token, MCP server and egress. General terms follow their official docs; Sandboxer terms describe how the product works today.

A new default sandbox runs Ubuntu 24.04 with Python 3.12, Node.js 22, Go, Rust, Bun, Docker with Compose, git, gh, Google Chrome and six coding agents, including Claude Code and Codex. Java, Ruby, PHP, .NET and Deno are not installed. You have passwordless sudo, so apt adds anything missing in seconds.