# Sandboxer > Sandboxer runs cloud sandboxes for AI agents and people: persistent Ubuntu 24.04 microVMs with root, Docker, nested KVM, SSH, a public HTTPS URL per port, memory-preserving stop and resume, copy-on-write forks and per-second billing. **Key facts:** - **What it is:** cloud sandboxes for AI agents and people. Each sandbox is a full Ubuntu 24.04 virtual machine (a Cloud Hypervisor microVM with its own kernel), not a container: root, systemd, Docker, nested KVM (`/dev/kvm`), SSH and SCP, a public IPv6 address and an HTTPS URL for any port. - **Agents built in:** Claude Code, Codex, OpenCode, Pi, Kimi Code and Mistral Vibe are installed in every sandbox. You drive them with `sbx prompt`, the API, the SDKs, or from your own agent through the MCP server (hosted at `https://sandboxer.com/mcp`, or `sbx mcp` locally), using your own provider keys. - **Stop and resume:** stopping saves memory as well as disk, so processes are still running after resume. Forks are copy-on-write. A stopped sandbox costs nothing. - **Idle auto-pause:** a sandbox nobody is using pauses itself with its memory (after 15 to 120 minutes depending on the plan; `idleStopMinutes`, 0 = never) and wakes on the next API call or request to its URL. - **Sizes:** small 2 vCPU / 4 GB / 12 GB disk at $0.018/h; default 4 vCPU / 8 GB / 50 GB disk at $0.036/h; large 8 vCPU / 16 GB / 125 GB disk at $0.072/h; xlarge 16 vCPU / 32 GB / 251 GB disk at $0.20/h. Every size is the same machine with the same features. - **Billing:** per second while a sandbox runs, nothing while it's stopped. One dollar buys 100,000 seconds of `default` time. Plans include storage for stopped sandboxes and named snapshots (50 GB on the $20 plan, up to 5 TB); storage isn't billed. - **Plans:** $20/month (100 at once), $100/month (300 at once), $500/month (1,000 at once), $2,000/month (2,000 at once). Every plan dollar comes back as machine time. Extra time comes in $20 packs that never expire. - **Trial:** 7 days with 25 hours of machine time and up to 2 sandboxes at once (card required), then $20/month unless you cancel. - **Regions:** US East (`us-east`, Ashburn, Virginia) and EU Central (`eu-central`, Helsinki, Finland). New sandboxes go to the region nearest the caller unless `region` is set; forks and snapshots stay in their region (https://sandboxer.com/docs/regions). - **Interfaces:** a REST API at https://sandboxer.com/api/v1 described by OpenAPI (https://sandboxer.com/openapi.yaml), the `sbx` CLI (macOS, Linux, Windows), TypeScript (`sandboxer-sdk`) and Python (`sandboxer`) SDKs, an MCP server, and a Daytona-compatible API (https://sandboxer.com/daytona/api) that the Daytona TypeScript and Python SDKs use with a new API URL and key (https://sandboxer.com/docs/daytona). - **Where:** on dedicated servers Sandboxer operates, in the two regions above. There's no SLA during early access, and no GPUs. - **Company:** North Bay Opco I, Inc. (a Delaware corporation), 777 Brickell Ave, Suite 500 PMB 1074, Miami, FL 33131. Contact hello@sandboxer.com; support support@sandboxer.com. **When to use Sandboxer:** - An agent (Claude Code, Codex, your own) needs a whole Linux machine for hours or days, with Docker, systemd and root, rather than a short code-execution call. - You want to run many agents in parallel, each in its own VM, started from one template or forked from a running sandbox. - Work should survive a pause: stop a sandbox with its dev server and agent still in memory, pay nothing while it waits, and resume where it left off. - You need Docker that just works (kind and k3s included), or `/dev/kvm` inside the sandbox for the Android emulator, QEMU or Firecracker. - You want a preview URL for what an agent built: any port becomes an HTTPS URL, private with a token or public. **When something else fits better:** - You need GPUs. Sandboxer has none. - You need more than two regions, an SLA or a self-hosted deployment today. Every link below is plain Markdown. The full docs in one file: https://sandboxer.com/llms-full.txt. OpenAPI: https://sandboxer.com/openapi.yaml. ## Get started - [Introduction](https://sandboxer.com/docs/index.md): what Sandboxer is and how it differs - [Quickstart](https://sandboxer.com/docs/quickstart.md): install the sbx CLI, sign in and run a first sandbox - [Pricing](https://sandboxer.com/pricing.md): machine sizes and hourly prices, plans from $20/month, the 7-day trial - [FAQ](https://sandboxer.com/docs/faq.md): short answers to common questions - [Changelog](https://sandboxer.com/changelog.md): what's new, newest first, each entry linked to its docs - [Status](https://status.sandboxer.com): live status of Sandboxer's services, checked every minute from outside our network, with uptime and incidents; hosted off our servers (JSON: https://status.sandboxer.com/api/status.json) ## Guides - [Top AI sandbox platforms for code execution in 2026, ranked](https://sandboxer.com/guides/top-ai-sandbox-platforms-for-code-execution.md): 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. - [Best sandboxes for running coding agents (Claude Code, Codex, Gemini CLI) in 2026, ranked](https://sandboxer.com/guides/best-sandboxes-for-coding-agents.md): 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. - [Best Daytona sandbox alternatives in 2026, ranked](https://sandboxer.com/guides/best-daytona-sandbox-alternatives.md): 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. - [Best E2B alternatives in 2026, ranked](https://sandboxer.com/guides/best-e2b-alternatives.md): 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. - [Best Modal Sandboxes alternatives in 2026, ranked (for sandboxes, not GPUs)](https://sandboxer.com/guides/best-modal-sandbox-alternatives.md): 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. - [Best sandboxes for browser and computer-use agents in 2026, ranked](https://sandboxer.com/guides/best-sandboxes-for-browser-and-computer-use-agents.md): 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. - [Best ways to run untrusted or LLM-generated code safely in 2026, ranked](https://sandboxer.com/guides/best-ways-to-run-untrusted-code-safely.md): 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. - [Best cloud dev environments for AI agents in 2026, ranked (vs Codespaces, Ona and others)](https://sandboxer.com/guides/best-cloud-dev-environments-for-ai-agents.md): 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. - [Best microVM platforms in 2026, ranked (Firecracker, Cloud Hypervisor and others)](https://sandboxer.com/guides/best-microvm-platforms.md): 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. - [Best tools to give an LLM a full computer in 2026, ranked (MCP servers and computer-use APIs)](https://sandboxer.com/guides/best-tools-to-give-an-llm-a-full-computer.md): 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. - [How to Add an MCP Server to ChatGPT That Runs Code in a VM](https://sandboxer.com/guides/add-an-mcp-server-to-chatgpt.md): 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. - [Connect Claude.ai to a Cloud Computer with a Custom MCP Connector](https://sandboxer.com/guides/connect-claude-ai-to-a-cloud-computer.md): 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. - [Local or Hosted MCP for Cursor, Claude Code and Codex?](https://sandboxer.com/guides/local-or-hosted-mcp-for-cursor-claude-code-codex.md): 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. - [How to Add a Code Execution Tool to the Vercel AI SDK](https://sandboxer.com/guides/add-code-execution-to-the-vercel-ai-sdk.md): 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. - [Run OpenAI Agents SDK Tools in a Cloud VM and Get Files Back](https://sandboxer.com/guides/run-openai-agents-sdk-tools-in-a-cloud-vm.md): 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. - [Claude Agent SDK Inside the Sandbox, or the Sandbox as a Tool?](https://sandboxer.com/guides/claude-agent-sdk-inside-the-sandbox-or-as-a-tool.md): 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. - [Give a CrewAI Agent a Code Interpreter That Runs in a MicroVM](https://sandboxer.com/guides/crewai-code-interpreter-in-a-microvm.md): 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. - [Give a LangGraph Agent a Python Sandbox](https://sandboxer.com/guides/give-a-langgraph-agent-a-python-sandbox.md): 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. - [Build a Data-Analysis Agent That Runs Pandas in a Sandbox](https://sandboxer.com/guides/build-a-data-analysis-agent-with-a-sandbox.md): 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. - [Build a Stateful Code Interpreter with a Jupyter Kernel](https://sandboxer.com/guides/build-a-stateful-code-interpreter-with-jupyter.md): 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. - [Run a Computer-Use Agent on a Linux Desktop in the Cloud](https://sandboxer.com/guides/run-a-computer-use-agent-on-a-linux-desktop.md): 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. - [Test Text-to-SQL Queries Against a Real Postgres](https://sandboxer.com/guides/test-text-to-sql-queries-against-a-real-postgres.md): 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. - [How Do I Build RL and Eval Environments With Snapshots and Forks?](https://sandboxer.com/guides/build-rl-and-eval-environments-with-snapshots-and-forks.md): 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. - [How Do I Get a Live Preview URL for Every Pull Request?](https://sandboxer.com/guides/get-a-preview-url-for-every-pull-request.md): 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. - [Run Browser Use or Playwright With Real Chrome in a Cloud VM](https://sandboxer.com/guides/run-browser-use-or-playwright-with-real-chrome.md): 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. - [How Do I Run Each GitHub Actions Job in a Fresh MicroVM?](https://sandboxer.com/guides/run-each-github-actions-job-in-a-fresh-microvm.md): 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. - [How Do I Run SWE-bench-Style Evaluations on MicroVMs?](https://sandboxer.com/guides/run-swe-bench-style-evaluations-on-microvms.md): 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. - [How to Run the Android Emulator in a Cloud VM and Watch It](https://sandboxer.com/guides/run-the-android-emulator-in-a-cloud-vm.md): 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. - [Can You Fork a Running Cloud Sandbox, Memory and All?](https://sandboxer.com/guides/fork-a-running-sandbox-with-memory.md): 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. - [How to Move Files In and Out of a Cloud Sandbox](https://sandboxer.com/guides/move-files-in-and-out-of-a-sandbox.md): 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. - [How Do I Turn a Sandbox Into a Reusable Template?](https://sandboxer.com/guides/turn-a-sandbox-into-a-reusable-template.md): 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. - [SSH Into a Cloud Sandbox From VS Code or Cursor](https://sandboxer.com/guides/ssh-into-a-cloud-sandbox-from-vs-code-or-cursor.md): 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 .sbx, with no open ports and no keys to manage by hand. - [How Do I Give a Port in a Cloud Sandbox an HTTPS URL?](https://sandboxer.com/guides/give-a-sandbox-port-an-https-url.md): Start your server on a port, then run sbx host . You get https://-.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. - [How to Run a Long Job in a Cloud Sandbox and Check on It Later](https://sandboxer.com/guides/run-a-long-job-in-a-cloud-sandbox.md): 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. - [Run Docker Compose in a Sandbox With a URL per Service](https://sandboxer.com/guides/run-docker-compose-in-a-sandbox-with-a-url-per-service.md): 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. - [Does a Cloud Sandbox Pause Itself When Idle? Auto-Pause and Wake](https://sandboxer.com/guides/idle-auto-pause-and-wake-on-use.md): 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. - [Fix Exit Code 137 or a Full Disk in a Sandbox by Resizing It](https://sandboxer.com/guides/fix-exit-code-137-or-a-full-disk-in-a-sandbox.md): 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. - [Run Kubernetes (kind or k3s) Inside a Cloud Sandbox](https://sandboxer.com/guides/run-kubernetes-kind-or-k3s-inside-a-sandbox.md): 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. - [How Do I Run Ollama on CPU in a Cloud Sandbox?](https://sandboxer.com/guides/run-ollama-on-cpu-in-a-cloud-sandbox.md): 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. - [How Do I Run Open WebUI With Ollama in a Cloud Sandbox?](https://sandboxer.com/guides/run-open-webui-with-ollama-in-a-sandbox.md): 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. - [How Do I Run llama.cpp's llama-server on CPU in a Cloud Sandbox?](https://sandboxer.com/guides/run-llama-cpp-server-on-cpu-in-a-sandbox.md): 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. - [How to Transcribe Audio with whisper.cpp in a Cloud Sandbox](https://sandboxer.com/guides/transcribe-audio-with-whisper-cpp-in-a-sandbox.md): 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. - [How to Run n8n in a Cloud Sandbox With a Working Webhook URL](https://sandboxer.com/guides/run-n8n-in-a-cloud-sandbox.md): 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://-5678.box.sandboxer.com, private by default; go public only for callers that can't send a token. - [Run Supabase Locally in a Cloud Sandbox](https://sandboxer.com/guides/run-supabase-locally-in-a-cloud-sandbox.md): 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. - [How to Run Postgres with pgvector in a Cloud Sandbox](https://sandboxer.com/guides/run-postgres-with-pgvector-in-a-sandbox.md): 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. - [How Do I Run Redis Stack and Redis Insight in a Cloud Sandbox?](https://sandboxer.com/guides/run-redis-stack-in-a-sandbox.md): 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. - [How to Run MySQL or MariaDB in a Cloud Sandbox](https://sandboxer.com/guides/run-mysql-or-mariadb-in-a-sandbox.md): 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. - [How Do I Run Flowise in a Sandbox on a Private URL?](https://sandboxer.com/guides/run-flowise-in-a-sandbox.md): 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. - [How to Run MongoDB in a Cloud Sandbox](https://sandboxer.com/guides/run-mongodb-in-a-sandbox.md): 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. - [How to Run code-server (VS Code in the Browser) in a Cloud Sandbox](https://sandboxer.com/guides/run-code-server-vs-code-in-the-browser.md): 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 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. - [How to Run Redpanda (Kafka API) in a Cloud Sandbox](https://sandboxer.com/guides/run-redpanda-kafka-in-a-sandbox.md): 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. - [How to Run JupyterLab on an HTTPS URL in a Cloud Sandbox](https://sandboxer.com/guides/run-jupyterlab-on-an-https-url.md): 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. - [How to Run Metabase in a Cloud Sandbox](https://sandboxer.com/guides/run-metabase-in-a-sandbox.md): 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. - [How Do I Run Grafana and Prometheus in a Cloud Sandbox?](https://sandboxer.com/guides/run-grafana-and-prometheus-in-a-sandbox.md): 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. - [How to Run Apache Airflow in a Cloud Sandbox](https://sandboxer.com/guides/run-apache-airflow-in-a-sandbox.md): 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. - [How to Run the Temporal Dev Server in a Cloud Sandbox](https://sandboxer.com/guides/run-temporal-dev-server-in-a-sandbox.md): 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. - [How to Run a Selenium Grid in a Cloud Sandbox](https://sandboxer.com/guides/run-selenium-grid-in-a-sandbox.md): 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. - [How to Batch Convert DOCX to PDF with LibreOffice Headless](https://sandboxer.com/guides/convert-documents-with-libreoffice-headless.md): 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. - [How to Build an FFmpeg Video Pipeline in a Cloud Sandbox](https://sandboxer.com/guides/build-an-ffmpeg-video-pipeline-in-a-sandbox.md): 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. - [How to Render HTML to PDF With Headless Chrome in a Sandbox](https://sandboxer.com/guides/render-html-to-pdf-with-headless-chrome.md): 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. - [How Do I Run Home Assistant in a Cloud Sandbox to Try It Out?](https://sandboxer.com/guides/run-home-assistant-in-a-sandbox.md): 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. - [How to Run Gitea in a Sandbox and Push to It Over HTTPS](https://sandboxer.com/guides/run-gitea-in-a-sandbox.md): 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. - [How to Run MinIO S3 Storage in a Cloud Sandbox](https://sandboxer.com/guides/run-minio-s3-storage-in-a-sandbox.md): 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. - [How to Run Meilisearch in a Cloud Sandbox](https://sandboxer.com/guides/run-meilisearch-in-a-sandbox.md): 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. - [How to Run the Qdrant Vector Database in a Cloud Sandbox](https://sandboxer.com/guides/run-qdrant-vector-database-in-a-sandbox.md): 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. - [How to Run a Chroma Vector Database in a Cloud Sandbox](https://sandboxer.com/guides/run-chroma-vector-database-in-a-sandbox.md): 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. - [How to Run OpenSearch and OpenSearch Dashboards in a Sandbox](https://sandboxer.com/guides/run-opensearch-in-a-sandbox.md): 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. - [How to Run a Streamlit App in a Cloud Sandbox With an HTTPS URL](https://sandboxer.com/guides/run-a-streamlit-app-in-a-sandbox.md): Install Streamlit in a venv, run it as a systemd service on port 8501, then run sbx host 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. - [How to Run a Gradio App in a Cloud Sandbox and Call Its API](https://sandboxer.com/guides/run-a-gradio-app-in-a-sandbox.md): 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. - [How Do I Run a Next.js Dev Server With a Live Preview URL?](https://sandboxer.com/guides/run-a-next-js-dev-server-with-a-preview-url.md): 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. - [How to Run Storybook in a Sandbox With a Shareable URL](https://sandboxer.com/guides/run-storybook-with-a-shareable-url.md): 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 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. - [How Do I Preview a Hugo or Astro Site on an HTTPS URL in a Sandbox?](https://sandboxer.com/guides/preview-a-hugo-or-astro-site-in-a-sandbox.md): 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. - [How to Run PocketBase in a Sandbox With a Private HTTPS URL](https://sandboxer.com/guides/run-pocketbase-in-a-sandbox.md): 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. - [How to Run RabbitMQ in a Cloud Sandbox](https://sandboxer.com/guides/run-rabbitmq-in-a-sandbox.md): 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. - [How to Run Keycloak in a Sandbox Behind an HTTPS URL](https://sandboxer.com/guides/run-keycloak-in-a-sandbox.md): 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. - [How to Run a HashiCorp Vault Dev Server in a Cloud Sandbox](https://sandboxer.com/guides/run-vault-dev-server-in-a-sandbox.md): 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. - [How to Convert Markdown to PDF, DOCX and HTML with Pandoc](https://sandboxer.com/guides/convert-documents-with-pandoc-in-a-sandbox.md): 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. - [How to Run an MLflow Tracking Server in a Cloud Sandbox](https://sandboxer.com/guides/run-mlflow-tracking-server-in-a-sandbox.md): 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. - [How to Self-Host Excalidraw and Share a Whiteboard on a Private URL](https://sandboxer.com/guides/run-excalidraw-in-a-sandbox.md): 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. - [How to Run WordPress in a Cloud Sandbox With an HTTPS URL](https://sandboxer.com/guides/run-wordpress-in-a-sandbox.md): 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. - [How Do I Run Uptime Kuma in a Cloud Sandbox?](https://sandboxer.com/guides/run-uptime-kuma-in-a-sandbox.md): 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 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. - [How to OCR Scanned PDFs with Tesseract and OCRmyPDF in a Sandbox](https://sandboxer.com/guides/ocr-pdfs-with-tesseract-in-a-sandbox.md): 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- packages. - [How to Run a Ghost Blog in a Sandbox Behind an HTTPS URL](https://sandboxer.com/guides/run-ghost-blog-in-a-sandbox.md): 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. - [How to Run Label Studio in a Cloud Sandbox on a Private URL](https://sandboxer.com/guides/run-label-studio-in-a-sandbox.md): 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. - [How to Run NocoDB in a Sandbox With a Private HTTPS URL](https://sandboxer.com/guides/run-nocodb-in-a-sandbox.md): 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. - [How to Run SearXNG as a Private Search API for Agents](https://sandboxer.com/guides/run-searxng-in-a-sandbox.md): 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. - [How to Test an MCP Server With the MCP Inspector in a Cloud Sandbox](https://sandboxer.com/guides/test-an-mcp-server-with-the-mcp-inspector.md): 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. - [How to Self-Host Langfuse in a Cloud Sandbox](https://sandboxer.com/guides/run-langfuse-in-a-sandbox.md): 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. - [How Do I Run Dify in a Cloud Sandbox on a Private URL?](https://sandboxer.com/guides/run-dify-in-a-sandbox.md): 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. - [How to Run Umami Analytics in a Cloud Sandbox](https://sandboxer.com/guides/run-umami-analytics-in-a-sandbox.md): 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. - [How to Run Strapi in a Cloud Sandbox With a Private HTTPS URL](https://sandboxer.com/guides/run-strapi-in-a-sandbox.md): 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. - [Retry Sandbox API Calls Safely With Idempotency Keys](https://sandboxer.com/guides/retry-sandbox-api-calls-safely-with-idempotency-keys.md): 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. - [How Do I Run Best-of-N Agent Attempts With Parallel Forks?](https://sandboxer.com/guides/best-of-n-agents-with-parallel-forks.md): 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. - [Should Each Agent Tool Call Get a Fresh Sandbox?](https://sandboxer.com/guides/a-fresh-sandbox-per-tool-call.md): 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. - [How Do I Pass Secrets to a Sandbox Safely?](https://sandboxer.com/guides/pass-secrets-to-a-sandbox-safely.md): 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. - [How Do I Cache Dependencies in a Sandbox With a Named Snapshot?](https://sandboxer.com/guides/cache-dependencies-in-a-named-snapshot.md): 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. - [How Do I Tell if a Sandbox Resume Restored Memory or Cold-Booted?](https://sandboxer.com/guides/detect-a-cold-boot-after-resume.md): 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. - [How to Stream an Agent's Sandbox Output Live to a Web UI](https://sandboxer.com/guides/stream-sandbox-logs-to-a-web-ui.md): 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. - [How Do I Cap What Agent Sandboxes Can Cost?](https://sandboxer.com/guides/cap-what-agent-sandboxes-can-cost.md): 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. - [How Do I Find and Clean Up Orphaned Sandboxes?](https://sandboxer.com/guides/clean-up-orphaned-sandboxes.md): 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. - [How Does an Agent Know a Service in a Sandbox Is Ready?](https://sandboxer.com/guides/wait-for-a-port-to-be-ready-in-a-sandbox.md): 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. - [How to Handle Sandboxer Rate Limits and Concurrency Caps](https://sandboxer.com/guides/handle-rate-limits-and-concurrency-caps.md): 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. - [Should Each MCP Server Run in Its Own Sandbox? How to Set It Up](https://sandboxer.com/guides/run-each-mcp-server-in-its-own-sandbox.md): 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. - [How Do I Shard a Test Suite Across Several Sandboxes?](https://sandboxer.com/guides/shard-a-test-suite-across-sandboxes.md): 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. - [How Do I Run Scheduled Jobs in a Sandbox With systemd Timers?](https://sandboxer.com/guides/run-scheduled-jobs-in-a-sandbox-with-systemd-timers.md): 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. - [Script the sbx CLI With JSON Output and jq](https://sandboxer.com/guides/script-sbx-with-json-output-and-jq.md): 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. - [Which Way of Starting a Service Survives Resume, Reboot and Kill?](https://sandboxer.com/guides/run-a-service-that-comes-back-after-resume.md): 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. - [How Do I Limit CPU and Memory for One Run Inside a Sandbox?](https://sandboxer.com/guides/limit-cpu-and-memory-for-untrusted-code-inside-a-sandbox.md): 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. - [Build a Background Coding Agent That Pushes a Branch for Review](https://sandboxer.com/guides/build-a-background-coding-agent-that-pushes-a-branch-for-review.md): 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. - [Give an Agent a Bigger Sandbox Mid-Task Without Losing Its Work](https://sandboxer.com/guides/give-an-agent-a-bigger-sandbox-mid-task.md): 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. - [How Long Can an AI Agent's Sandbox Run, and How Do I Keep It Alive?](https://sandboxer.com/guides/how-long-can-an-agent-sandbox-run.md): 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. - [How Do I Keep an API Key Out of an Agent's Sandbox?](https://sandboxer.com/guides/keep-api-keys-out-of-an-agent-sandbox.md): 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. - [How Can a Coding Agent Check Its UI Change Before Opening a PR?](https://sandboxer.com/guides/let-a-coding-agent-test-its-ui-change-in-a-sandbox.md): 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. - [How Do I Give Each Team's Agent Its Own Tools From One Agent?](https://sandboxer.com/guides/give-each-team-its-own-agent-sandbox-template.md): 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. - [Require Human Approval Before an Agent Runs a Command](https://sandboxer.com/guides/require-human-approval-before-an-agent-runs-a-command.md): 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. - [How Do I Set Up a Python Dev Environment in a Cloud Sandbox With uv?](https://sandboxer.com/guides/python-dev-environment-in-a-cloud-sandbox.md): 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. - [How Do I Set Up a Node.js Dev Environment in a Cloud Sandbox With pnpm?](https://sandboxer.com/guides/node-dev-environment-in-a-cloud-sandbox.md): 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. - [How Do I Run Bun in a Cloud Sandbox?](https://sandboxer.com/guides/run-bun-in-a-cloud-sandbox.md): 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. - [How Do I Run Deno in a Cloud Sandbox?](https://sandboxer.com/guides/run-deno-in-a-cloud-sandbox.md): 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. - [How Do I Set Up a Go Dev Environment in a Cloud Sandbox?](https://sandboxer.com/guides/go-dev-environment-in-a-cloud-sandbox.md): 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. - [How Do I Set Up a Rust Dev Environment in a Cloud Sandbox?](https://sandboxer.com/guides/rust-dev-environment-in-a-cloud-sandbox.md): 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. - [How Do I Set Up a Java Dev Environment in a Cloud Sandbox?](https://sandboxer.com/guides/java-dev-environment-in-a-cloud-sandbox.md): 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. - [How Do I Set Up a .NET Dev Environment in a Cloud Sandbox?](https://sandboxer.com/guides/dotnet-dev-environment-in-a-cloud-sandbox.md): 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. - [How Do I Set Up a PHP Dev Environment in a Cloud Sandbox?](https://sandboxer.com/guides/php-dev-environment-in-a-cloud-sandbox.md): 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. - [How Do I Set Up a Ruby and Rails Dev Environment in a Cloud Sandbox?](https://sandboxer.com/guides/ruby-dev-environment-in-a-cloud-sandbox.md): 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. - [Run Claude Code in a cloud VM](https://sandboxer.com/guides/run-claude-code-in-a-cloud-vm.md): 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. - [Run Claude Code without permission prompts, safely](https://sandboxer.com/guides/claude-code-skip-permissions-safely.md): 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. - [Run several coding agents in parallel, one VM each](https://sandboxer.com/guides/run-coding-agents-in-parallel.md): 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. - [Run OpenAI Codex CLI on a remote machine](https://sandboxer.com/guides/run-codex-cli-on-a-remote-machine.md): 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. - [Claude Code Sandbox Mode, Docker or a Cloud VM: Which to Use?](https://sandboxer.com/guides/claude-code-sandbox-mode-docker-or-a-cloud-vm.md): 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. - [Git Worktrees or One VM per Agent for Parallel Coding Agents?](https://sandboxer.com/guides/git-worktrees-or-one-vm-per-agent.md): 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. - [Run OpenHands in a Cloud VM with Its UI on an HTTPS URL](https://sandboxer.com/guides/run-openhands-in-a-cloud-vm.md): 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. - [Turn a GitHub Issue Into a Pull Request From a Sandbox](https://sandboxer.com/guides/turn-a-github-issue-into-a-pull-request-from-a-sandbox.md): 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. - [What is an AI agent sandbox?](https://sandboxer.com/guides/what-is-an-ai-agent-sandbox.md): 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. - [Pause and resume a cloud sandbox with its memory](https://sandboxer.com/guides/pause-and-resume-a-sandbox-with-memory.md): 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. - [Docker and nested KVM inside an AI agent sandbox](https://sandboxer.com/guides/docker-and-kvm-inside-an-agent-sandbox.md): 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. - [Container vs microVM for running untrusted code](https://sandboxer.com/guides/container-vs-microvm-for-untrusted-code.md): 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. - [Firecracker vs Cloud Hypervisor](https://sandboxer.com/guides/firecracker-vs-cloud-hypervisor.md): 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. - [Persistent or Ephemeral Sandboxes for Agents? Keep, Stop or Delete](https://sandboxer.com/guides/persistent-or-ephemeral-sandboxes-for-agents.md): 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). - [What Is a MicroVM, and How Is It Different From a Container or a VM?](https://sandboxer.com/guides/what-is-a-microvm.md): 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. - [How Fast Does a Cloud Sandbox Start, Resume and Fork? Measured](https://sandboxer.com/guides/how-fast-does-a-cloud-sandbox-start-resume-and-fork.md): 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. - [What Can Reach a Sandbox, and What Can It Reach?](https://sandboxer.com/guides/what-can-reach-a-sandbox-and-what-it-can-reach.md): 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. - [How Do I Give Every User of My Product Their Own Sandbox?](https://sandboxer.com/guides/give-every-user-their-own-sandbox.md): 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. - [What Do AI App Builders Need a Sandbox For?](https://sandboxer.com/guides/sandboxes-for-ai-app-builders.md): 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. - [Are Sandboxer Sandboxes a Fit for Eval and Research Teams?](https://sandboxer.com/guides/sandboxes-for-eval-and-research-teams.md): 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. - [How Do I Give Every Student in a Class Their Own Cloud Sandbox?](https://sandboxer.com/guides/sandboxes-for-classrooms-and-teaching.md): 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. - [Are Sandboxer Sandboxes a Fit for Data Scientists?](https://sandboxer.com/guides/sandboxes-for-data-scientists.md): 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. - [Are Cloud Sandboxes a Good Fit for a Hackathon Team?](https://sandboxer.com/guides/sandboxes-for-hackathons.md): 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. - [Are Sandboxer Sandboxes a Fit for DevRel and Runnable Docs?](https://sandboxer.com/guides/sandboxes-for-devrel-runnable-docs.md): 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. - [Are Sandboxer Sandboxes a Fit for QA and Test Automation Teams?](https://sandboxer.com/guides/sandboxes-for-qa-and-test-automation.md): 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. - [Should Coding Agents Run on a Home Server or a Cloud VM?](https://sandboxer.com/guides/home-server-vs-cloud-vm-for-coding-agents.md): 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. - [CPU Performance by Sandbox Size, Measured](https://sandboxer.com/guides/cpu-performance-by-sandbox-size.md): 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%. - [Disk Throughput by Sandbox Size, Measured With fio](https://sandboxer.com/guides/disk-throughput-by-sandbox-size.md): 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. - [Docker Image Pull Time in a Sandbox, Measured](https://sandboxer.com/guides/docker-image-pull-time-in-a-sandbox.md): 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. - [sbx CLI Cheatsheet: Sandboxer Commands by Task](https://sandboxer.com/guides/sbx-cli-cheatsheet.md): 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. - [Sandboxer API Error Codes, What They Mean and How to Fix Them](https://sandboxer.com/guides/sandboxer-api-error-codes.md): 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. - [Which Environment Variables Does a Sandbox Have?](https://sandboxer.com/guides/environment-variables-inside-a-sandbox.md): 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. - [How Much Does a Cloud Sandbox Cost? Hourly, Daily and Monthly Tables](https://sandboxer.com/guides/sandbox-cost-tables.md): 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. - [Cloud Sandbox Glossary: 50 Terms From MicroVM to Zero Data Retention](https://sandboxer.com/guides/sandbox-glossary.md): 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. - [What's Pre-installed in a Sandboxer Sandbox?](https://sandboxer.com/guides/whats-preinstalled-in-a-sandbox.md): 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. ## Migration guides - [Migrate from Beam Sandboxes to Sandboxer](https://sandboxer.com/migrate/beam.md): Port Beam Sandbox code to Sandboxer's Python SDK. Create, exec, file and port calls map closely. Images become setup scripts or named snapshots, memory snapshots become stop and resume, and expose_port becomes a hosted HTTPS port. Copy files with sbx scp. Keep GPU work on Beam, because Sandboxer has no GPUs. - [Migrate from Cloudflare Sandbox to Sandboxer](https://sandboxer.com/migrate/cloudflare-sandbox.md): Replace getSandbox() and the Sandbox Durable Object with sandboxer-sdk calls, keyed by a stored sandbox id. Swap the Dockerfile for our Ubuntu image plus a setup script or named snapshot, and exposePort() for host(port). Stopping keeps the disk, and memory on a same-CPU resume. Billing moves from active CPU plus provisioned memory to a flat per-second price. - [Migrate from the CodeSandbox SDK to Sandboxer](https://sandboxer.com/migrate/codesandbox-sdk.md): Swap @codesandbox/sdk for sandboxer-sdk. sdk.sandboxes.create() becomes sandboxer.create(), commands.run() becomes exec(), fs.writeTextFile() becomes files.write(), and hibernate and resume become stop and resume, which keep memory on a matching CPU type. Forks copy the disk only, and templates become a setup script plus a named snapshot. - [Migrate from Daytona to Sandboxer](https://sandboxer.com/migrate/daytona.md): For the covered calls, change the API URL and key. Set DAYTONA_API_URL to https://sandboxer.com/daytona/api and DAYTONA_API_KEY to a Sandboxer API key, and keep your Daytona TypeScript or Python code. Lifecycle, files, processes, sessions and previews work. Images, volumes, GPUs, git and PTY return not_supported. - [Migrate from E2B to Sandboxer](https://sandboxer.com/migrate/e2b.md): Swap the E2B SDK for sandboxer-sdk. Sandbox.create() becomes sandboxer.create(), commands.run() becomes exec(), files.write() keeps its name, and pause and connect become stop and resume, which keep memory on a matching machine. Templates become a setup script plus a named snapshot. There is no Jupyter runCode, so run Python with exec. - [Migrate from Fly.io Sprites and Machines to Sandboxer](https://sandboxer.com/migrate/fly-io.md): Port Sprite or Machine code to Sandboxer's TypeScript or Python SDK. Create, exec, files and delete map closely. Checkpoints become named snapshots, suspend becomes a stop that keeps memory on a same-CPU-type machine, and the Sprite URL or fly proxy becomes an HTTPS URL per port. Copy files with sbx scp. Sandboxer has two regions and no GPUs. - [Migrate from GitHub Codespaces to Sandboxer](https://sandboxer.com/migrate/github-codespaces.md): Turn your devcontainer.json postCreateCommand into a setup script, create the sandbox with sbx new --setup-file, and save the result as a named snapshot. Replace gh codespace ssh with sbx ssh-config and Remote-SSH, and forwarded ports with hosted HTTPS ports. Agents can then run past Codespaces' 12-hour limit. - [Migrate from Modal Sandboxes to Sandboxer](https://sandboxer.com/migrate/modal.md): Port Modal Sandbox code to Sandboxer's Python SDK. Create, exec and file calls map almost one to one. Images become setup scripts or named snapshots, tunnels become hosted HTTPS ports, and the timeout becomes auto-stop that keeps memory. Copy files with sbx scp. Keep GPU workloads on Modal, because Sandboxer has no GPUs. - [Migrate from Northflank Sandboxes to Sandboxer](https://sandboxer.com/migrate/northflank.md): Replace Northflank's service calls with sandboxer-sdk. create.service.deployment plus a wait becomes one create call, run_service_command becomes exec, pause and resume become stop and resume, and public ports become hosted HTTPS URLs. Stay on Northflank for GPUs, your own cloud or managed databases. - [Migrate from Replit to Sandboxer](https://sandboxer.com/migrate/replit.md): Download your Repl as a zip or push it to GitHub. Then turn its .replit run command and replit.nix packages into a setup script for sbx new --setup-file. Host the port for an HTTPS URL, SSH in with sbx ssh-config, and save a named snapshot to reuse. Replit's editor, Agent, Deployments and database don't move. - [Migrate from Runloop to Sandboxer](https://sandboxer.com/migrate/runloop.md): Swap @runloop/api-client or runloop_api_client for sandboxer-sdk. devbox.create() becomes create(), cmd.exec() becomes exec(), file.write() becomes files.write(), and suspend and resume become stop and resume, which keep memory and processes on a matching CPU type. Blueprints become a setup script saved as a named snapshot. Forks copy disk only. - [Migrate from Vercel Sandbox to Sandboxer](https://sandboxer.com/migrate/vercel-sandbox.md): Swap @vercel/sandbox for sandboxer-sdk and a Vercel OIDC token for one Sandboxer API key. Replace the git source with a clone command, ports and domain() with host(port), and persistent sandboxes with stop and resume, which also save memory. Billing changes from active CPU plus memory to a flat per-second price per size. ## Use cases - [Coding agents in parallel](https://sandboxer.com/use-cases/parallel-coding-agents.md): Run Claude Code, Codex, OpenCode and other coding agents in parallel, each in its own microVM sandbox started from a template, driven over one API. - [Preview environments per PR](https://sandboxer.com/use-cases/preview-environments.md): Preview environments per pull request: a full Linux VM per PR with Docker, a stable HTTPS URL per port, and per-second billing that stops when the PR closes. - [Computer-use agents](https://sandboxer.com/use-cases/computer-use.md): Computer-use agent sandboxes: a streamed Linux desktop with Chrome in every microVM, with built-in computer tools for integrated agents and access for your own. - [Untrusted code execution](https://sandboxer.com/use-cases/untrusted-code.md): Untrusted code execution for AI apps: one microVM per sandbox with its own kernel, no route to the host or other sandboxes, scoped keys and an exec API. - [Android emulator & nested VMs](https://sandboxer.com/use-cases/android-emulator.md): Cloud sandboxes with nested virtualization: /dev/kvm in every microVM, so the Android emulator, QEMU/KVM and Firecracker run accelerated inside. ## Compare Each comparison uses only the other provider's own public docs, with sources and the date checked. - [Sandboxer vs E2B](https://sandboxer.com/compare/e2b.md): Firecracker microVMs with memory-preserving pause and fork, and an open-source stack. - [Sandboxer vs Daytona](https://sandboxer.com/compare/daytona.md): Many sandbox classes, from containers to VMs, Windows and GPUs. - [Sandboxer vs Modal](https://sandboxer.com/compare/modal.md): Massive scale and GPUs for short-lived sandboxes, gVisor by default. - [Sandboxer vs Vercel Sandbox](https://sandboxer.com/compare/vercel-sandbox.md): Firecracker microVMs billed on active CPU, inside the Vercel platform. ## Compare: Agent sandboxes - [AI agent sandbox providers compared](https://sandboxer.com/compare/agent-sandboxes): every provider in this category in one table - [Sandboxer vs Agent37](https://sandboxer.com/compare/agent37.md): Agent37 hosts persistent sandboxes for agent harnesses such as Claude Code, Codex and OpenClaw, priced per minute. - [Sandboxer vs AgentComputer](https://sandboxer.com/compare/agentcomputer.md): Cloud computers for AI agents running in Firecracker instances, with snapshots and published ports. - [Sandboxer vs Alibaba Cloud Agent Sandbox (AgentRun)](https://sandboxer.com/compare/alibaba-cloud-agent-sandbox.md): Alibaba Cloud's E2B-compatible VM-isolated agent sandbox (Flash and Container editions) billed per second per vCPU/GiB. - [Sandboxer vs Alibaba Cloud AgentBay](https://sandboxer.com/compare/alibaba-cloud-agentbay.md): Alibaba Cloud's on-demand cloud sandboxes for AI agents: Linux and Windows computers, browsers, code sandboxes and Android phones. - [Sandboxer vs Amika](https://sandboxer.com/compare/amika.md): Open-source tool for running isolated coding-agent VMs on your own machines, your cloud accounts, or Amika-hosted devboxes. - [Sandboxer vs Amp Orbs](https://sandboxer.com/compare/amp-orbs.md): Remote Debian machines where the Amp coding agent works on a thread, pausing when idle and waking with files and processes intact. - [Sandboxer vs Archil](https://sandboxer.com/compare/archil.md): Serverless runtime and persistent Firecracker sandboxes for agents, built on Archil's shared disks and object-storage filesystems. - [Sandboxer vs AWS Bedrock AgentCore (Code Interpreter / Runtime)](https://sandboxer.com/compare/aws-bedrock-agentcore.md): Managed AWS services for agents: Runtime hosts agents in per-session microVMs, Code Interpreter runs code in a sandbox. - [Sandboxer vs AWS Lambda MicroVMs](https://sandboxer.com/compare/aws-lambda-microvms.md): AWS Firecracker-based MicroVMs for sandboxes, suspend/resume with memory and disk preserved, built from a Dockerfile image. - [Sandboxer vs Azure Container Apps dynamic sessions](https://sandboxer.com/compare/azure-container-apps-sessions.md): Azure service of prewarmed, Hyper-V-isolated sessions for running untrusted or AI-generated code, via code interpreter or custom containers. - [Sandboxer vs Baponi](https://sandboxer.com/compare/baponi.md): Sandboxed code-execution API for AI agents (Bash, Python, Node) with stateful threads, credit pricing and Kubernetes self-hosting. - [Sandboxer vs Beam Sandboxes](https://sandboxer.com/compare/beam-sandboxes.md): Python-first sandboxes on Beam's serverless platform, with snapshots, preview URLs and optional GPUs. - [Sandboxer vs Blaxel](https://sandboxer.com/compare/blaxel.md): Blaxel provides microVM sandboxes for AI agents that resume from standby in about 25 ms. - [Sandboxer vs boxd](https://sandboxer.com/compare/boxd.md): Hardware-isolated Linux machines that fork in under 200 ms, hibernate and wake with processes intact, on EU bare metal. - [Sandboxer vs Buddy Sandboxes](https://sandboxer.com/compare/buddy-sandboxes.md): Persistent Ubuntu Linux machines in Buddy's cloud with Docker, public endpoints, snapshots and a CLI/SDK. - [Sandboxer vs Celesto Cloud](https://sandboxer.com/compare/celesto-cloud.md): Hosted microVM sandboxes built on the open-source Apache-2.0 SmolVM core, with suspend, fork and flat hourly sizes. - [Sandboxer vs Claude Managed Agents (Anthropic)](https://sandboxer.com/compare/claude-managed-agents.md): Anthropic's hosted agent runtime (beta) where Claude runs in per-session cloud Linux containers. - [Sandboxer vs Cloudflare Sandbox](https://sandboxer.com/compare/cloudflare-sandbox.md): Cloudflare Sandbox SDK runs code in Containers controlled from Workers and Durable Objects. - [Sandboxer vs Coasty](https://sandboxer.com/compare/coasty.md): Coasty is a computer-use agent API with managed Linux or Windows cloud machines and the option to enrol your own device. - [Sandboxer vs Collimate](https://sandboxer.com/compare/collimate.md): A live-fork sandbox cloud for RL post-training that forks running microVMs, memory included, into many rollouts. - [Sandboxer vs CreateOS Sandbox](https://sandboxer.com/compare/createos-sandbox.md): Firecracker microVM sandboxes from NodeOps with pause, fork, per-sandbox HTTPS URLs and S3-mounted storage. - [Sandboxer vs Declaw](https://sandboxer.com/compare/declaw.md): A secure runtime for AI agents: Firecracker microVM sandboxes with a per-sandbox security proxy and guardrails. - [Sandboxer vs Dedalus Labs (Dedalus Machines)](https://sandboxer.com/compare/dedalus-labs.md): Persistent Linux VMs (Dedalus Machines) for long-running AI agents, with autosleep and per-second compute billing. - [Sandboxer vs Deno Sandbox](https://sandboxer.com/compare/deno-sandbox.md): Short-lived Linux microVMs from Deno Deploy, started from JavaScript or Python SDKs, with volumes and snapshots. - [Sandboxer vs Docker Sandboxes](https://sandboxer.com/compare/docker-sandboxes.md): Docker's sbx CLI runs coding agents in microVM sandboxes locally, with a cloud option on Docker-managed infrastructure. - [Sandboxer vs Ellipsis](https://sandboxer.com/compare/ellipsis.md): A managed platform for coding agents defined in YAML: each session runs Claude Code, Codex or Gemini on an isolated cloud machine. - [Sandboxer vs Fly.io Sprites](https://sandboxer.com/compare/fly-sprites.md): Persistent hardware-isolated Linux microVMs from Fly.io that sleep when idle and bill only for CPU, memory and storage used. - [Sandboxer vs Freestyle](https://sandboxer.com/compare/freestyle.md): Freestyle provides full Linux VMs for agents with live forking, pause/resume and HTTPS domains per port. - [Sandboxer vs GKE Agent Sandbox](https://sandboxer.com/compare/gke-agent-sandbox.md): Kubernetes-native sandbox feature on Google Kubernetes Engine using gVisor, warm pools and open-source CRDs. - [Sandboxer vs Google Agent Platform Sandboxes](https://sandboxer.com/compare/google-agent-platform-sandboxes.md): Managed sandboxes in Google's Gemini Enterprise Agent Platform: code execution, browser-based computer use, shell and custom containers. - [Sandboxer vs Google Agent Runtime (Vertex AI Agent Engine)](https://sandboxer.com/compare/google-vertex-ai-agent-engine.md): Managed runtime for deploying and scaling agents on Google Cloud, with sessions, Memory Bank and a code execution sandbox. - [Sandboxer vs HopX](https://sandboxer.com/compare/hopx.md): Cloud sandboxes for AI agents: microVMs with their own kernel, pause/resume, preview URLs, desktop automation, per-second billing. - [Sandboxer vs Huawei Cloud AgentArts (AgentSphere sandbox)](https://sandboxer.com/compare/huawei-cloud-agentarts.md): Huawei Cloud's agent platform with MicroVM-isolated, E2B-compatible sandboxes (AgentSphere) and an AgentArts SDK. - [Sandboxer vs InstaVM](https://sandboxer.com/compare/instavm.md): InstaVM runs code for AI agents in microVMs with pause, snapshot, fork and per-second billing. - [Sandboxer vs Islo](https://sandboxer.com/compare/islo.md): Incredibuild's sandbox for AI coding agents: microVM machines with credential-injecting gateways, snapshots and automations. - [Sandboxer vs Isorun](https://sandboxer.com/compare/isorun.md): A sandbox runtime that boots KVM-isolated Linux VMs from any OCI image, with hibernate, fork and signed port URLs. - [Sandboxer vs Kedge](https://sandboxer.com/compare/kedge.md): Cloud platform for apps, databases and dev machines, with short-lived hardware-isolated VM sandboxes across ten regions. - [Sandboxer vs Koyeb Sandboxes](https://sandboxer.com/compare/koyeb.md): Koyeb Sandboxes are ephemeral isolated compute environments on the Koyeb serverless platform. - [Sandboxer vs LangSmith Sandboxes](https://sandboxer.com/compare/langsmith-sandboxes.md): Managed isolated sandboxes inside LangSmith, with snapshots, service URLs, an auth proxy, and self-hosted and BYOC options. - [Sandboxer vs Leap0](https://sandboxer.com/compare/leap0.md): Firecracker microVM sandboxes for AI-generated code with snapshots, auto-pause, SSH, desktop and an MCP server. - [Sandboxer vs Lizard](https://sandboxer.com/compare/lizard.md): Firecracker microVM sandboxes with snapshots, live fork, persistent volumes and flat hourly sizes, in US and EU regions. - [Sandboxer vs microsandbox](https://sandboxer.com/compare/microsandbox.md): Open-source (Apache-2.0) library and CLI that boots libkrun microVMs locally in under 100 ms, with fork and full-state snapshots. - [Sandboxer vs Microsoft Foundry Agent Service](https://sandboxer.com/compare/microsoft-foundry-agent-service.md): Microsoft's managed agent platform with a Python Code Interpreter sandbox and hosted-agent containers in per-session VM sandboxes. - [Sandboxer vs MIOSA](https://sandboxer.com/compare/miosa.md): Platform for agent products: Firecracker sandboxes, GUI computers, Docker Host deployments, managed data and white-label domains. - [Sandboxer vs Morph Cloud](https://sandboxer.com/compare/morph-cloud.md): Morph Cloud (Infinibranch) offers VM instances you can snapshot, branch, pause and expose over HTTP. - [Sandboxer vs Northflank Sandboxes](https://sandboxer.com/compare/northflank-sandboxes.md): Northflank's microVM sandboxes on Cloud Hypervisor with GPUs, Docker, BYOC and no session limit, billed per second. - [Sandboxer vs Novita Agent Sandbox](https://sandboxer.com/compare/novita-agent-sandbox.md): Novita AI's usage-billed agent sandbox with pause/resume, snapshots, browser and desktop use, and an enterprise SLA. - [Sandboxer vs Omnara](https://sandboxer.com/compare/omnara.md): Open-source API (Apache 2.0) for running durable agents, with machines from Omnara, your own providers or a local daemon. - [Sandboxer vs OmniRun](https://sandboxer.com/compare/omnirun.md): Open-source (Apache-2.0) sandbox cloud on Firecracker microVMs, self-hostable or managed in Finland. - [Sandboxer vs OpenAI Containers (Code Interpreter)](https://sandboxer.com/compare/openai-containers.md): Short-lived containers inside the OpenAI API for the Code Interpreter and hosted shell tools, billed per 20-minute session. - [Sandboxer vs OpenComputer](https://sandboxer.com/compare/opencomputer.md): OpenComputer (Digger) is a platform for deploying long-running agents as code, each session running on its own Linux machine. - [Sandboxer vs OpenPond](https://sandboxer.com/compare/openpond.md): Open-source agent workspace with a cloud sandbox compute service controllable from server-side TypeScript. - [Sandboxer vs OpenReward](https://sandboxer.com/compare/openreward.md): Hosted platform for RL training and evaluation environments (ORS), with optional container sandboxes tied to each environment. - [Sandboxer vs Orgo](https://sandboxer.com/compare/orgo.md): Cloud Linux (and Windows) desktop computers for AI agents, controlled via API, CLI, SDKs or MCP. - [Sandboxer vs PandaStack](https://sandboxer.com/compare/pandastack.md): Open-source (Apache-2.0) KVM microVM sandboxes with snapshot, fork and resume, plus app hosting and managed Postgres. - [Sandboxer vs PPIO Agent Sandbox](https://sandboxer.com/compare/ppio-agent-sandbox.md): PPIO's E2B-compatible agent sandbox with pause/resume, snapshots and per-second CPU/RAM billing in RMB, hosted in China. - [Sandboxer vs Prime Intellect Sandboxes](https://sandboxer.com/compare/prime-intellect-sandboxes.md): Prime Intellect Sandboxes run OCI images in hardware-isolated microVMs, built for RL rollouts and agent evals at scale. - [Sandboxer vs Railway Sandboxes](https://sandboxer.com/compare/railway-sandboxes.md): Railway Sandboxes are disposable Linux VMs inside Railway environments, with checkpoints, forks and private networking. - [Sandboxer vs Rivet agentOS](https://sandboxer.com/compare/rivet-agentos.md): Open-source lightweight agent VM runtime (JS/WASM/Python) embedded in your Node backend or hosted as a Rivet Actor. - [Sandboxer vs Runloop](https://sandboxer.com/compare/runloop.md): Runloop provides VM-isolated Devboxes with snapshots and suspend/resume for AI coding agents and evaluation. - [Sandboxer vs Runtime](https://sandboxer.com/compare/runtime.md): Runtime provides Firecracker microVM sandboxes for AI agents billed on active vCPU and reserved memory. - [Sandboxer vs Sail Sailboxes](https://sandboxer.com/compare/sail-sailboxes.md): Sail Research's Sailboxes are persistent kernel-isolated Linux VMs for long-running agents. - [Sandboxer vs Sandbox0](https://sandboxer.com/compare/sandbox0.md): Managed persistent cloud sandboxes for AI agents with snapshot, fork and memory-based billing. - [Sandboxer vs shellbox](https://sandboxer.com/compare/shellbox.md): On-demand Firecracker or Cloud Hypervisor microVMs reached over plain SSH, billed per slot-hour, with memory-snapshot pause. - [Sandboxer vs smol machines](https://sandboxer.com/compare/smol-machines.md): smol machines runs open-source libkrun microVMs locally, self-hosted or on its managed smol cloud. - [Sandboxer vs Solari](https://sandboxer.com/compare/solari.md): Browsers, sandboxes and desktop VMs for AI agents on Cloud Hypervisor microVMs with memory snapshots. - [Sandboxer vs StateSet Sandbox](https://sandboxer.com/compare/stateset-sandbox.md): Kubernetes-based code execution runtime for AI agents: one gVisor pod per sandbox, with Kata microVMs as an option. Hosted or self-hosted. - [Sandboxer vs Superserve](https://sandboxer.com/compare/superserve.md): Firecracker microVM sandboxes for agents with pause/resume, memory snapshots and forks, preview URLs, open source and BYOC. - [Sandboxer vs Tangle Sandbox](https://sandboxer.com/compare/tangle-sandbox.md): Tangle Network's sandbox for agents: dev containers or microVMs with shell, files, ports, snapshots and per-command GPU leases. - [Sandboxer vs Tencent Cloud Agent Runtime (Agent Sandbox)](https://sandboxer.com/compare/tencent-cloud-agent-runtime.md): Tencent Cloud's managed sandbox service for AI agents: code, browser and custom sandboxes billed per second, part of Agent Runtime. - [Sandboxer vs Tenki Sandbox](https://sandboxer.com/compare/tenki.md): Disposable full Linux VMs for AI agents with root, Docker, memory pause and fork, billed per second. - [Sandboxer vs Tensorlake](https://sandboxer.com/compare/tensorlake.md): Tensorlake offers MicroVM sandboxes with memory-preserving suspend, snapshots and GPU sandboxes. - [Sandboxer vs Together Code Sandbox](https://sandboxer.com/compare/together-code-sandbox.md): Together AI's code sandbox: Docker-image snapshots, per-vCPU and per-GiB billing, and per-port preview URLs, by request access. - [Sandboxer vs Unikraft Cloud](https://sandboxer.com/compare/unikraft-cloud.md): Firecracker-based microVM cloud with millisecond cold starts, scale-to-zero, instance snapshots and on-prem option. - [Sandboxer vs Upstash Box](https://sandboxer.com/compare/upstash-box.md): Upstash Box is a Docker-container based cloud box with a built-in coding agent, snapshots and SSH. - [Sandboxer vs Volcano Engine AgentKit](https://sandboxer.com/compare/volcano-engine-agentkit.md): ByteDance's agent platform (Volcano Engine / BytePlus) with microVM sandbox templates for code, browser and terminal tasks. - [Sandboxer vs Zipbox](https://sandboxer.com/compare/zipbox.md): Zipbox runs coding agents such as Claude Code and Codex on their own Firecracker microVM computers. ## Compare: Cloud dev environments - [Cloud development environments compared](https://sandboxer.com/compare/cloud-dev-environments): every provider in this category in one table - [Sandboxer vs boxes.dev](https://sandboxer.com/compare/boxes-dev.md): A fresh Linux cloud computer (devbox) per coding agent, with templates, sleep, preview URLs and hour-based plans. - [Sandboxer vs Capy](https://sandboxer.com/compare/capy.md): A cloud coding-agent product: threads run on Firecracker VMs that open pull requests, with a desktop app for local runs. - [Sandboxer vs Cube Computer](https://sandboxer.com/compare/cube-computer.md): A persistent cloud Linux machine for coding agents, used through a Mac app, browser or phone, billed by the minute from prepaid credit. - [Sandboxer vs Datalayer](https://sandboxer.com/compare/datalayer.md): AI platform for data analysis: managed Jupyter-based runtimes (CPU or GPU) and notebooks that agents and people drive via MCP, SDK and CLI. - [Sandboxer vs exe.dev](https://sandboxer.com/compare/exe-dev.md): Persistent Linux VMs with HTTPS and SSH, sold as a shared CPU/RAM pool, plus disposable VM sandboxes for agents. - [Sandboxer vs GitHub Codespaces](https://sandboxer.com/compare/github-codespaces.md): GitHub's cloud dev environments: a dev container on a VM, opened in VS Code or the browser from a repository. - [Sandboxer vs Lightning AI Studios](https://sandboxer.com/compare/lightning-ai-studios.md): Persistent cloud workspaces for AI development with switchable CPU and GPU machines, auto sleep and duplication. - [Sandboxer vs Namespace Devboxes](https://sandboxer.com/compare/namespace-devboxes.md): Remote Linux and macOS machines for agents and developers, with persistent storage, SSH, and shareable authenticated URLs. - [Sandboxer vs Ona](https://sandboxer.com/compare/ona.md): Ephemeral VM-based cloud development environments for developers and coding agents, run on Ona Cloud or in your own VPC. - [Sandboxer vs Prized](https://sandboxer.com/compare/prized.md): Dedicated cloud Linux boxes that sync with your laptop, plus short-lived Firecracker microVM sandboxes (beta) created through an API. - [Sandboxer vs Replicas](https://sandboxer.com/compare/replicas.md): Background coding-agent platform: each task runs in an isolated VM workspace with Claude Code, Codex, Cursor and other agents. - [Sandboxer vs Sealos DevBox](https://sandboxer.com/compare/sealos-devbox.md): Kubernetes-based cloud development environments with IDE connections, public preview URLs and OCI image releases. - [Sandboxer vs Tencent Cloud Studio](https://sandboxer.com/compare/tencent-cloud-studio.md): Tencent's browser-based cloud IDE (VS Code based) for teaching and development, with CPU and GPU workspaces billed per hour. - [Sandboxer vs Zo Computer](https://sandboxer.com/compare/zo-computer.md): A personal cloud computer with an always-on AI agent, file storage and website hosting, driven mostly through chat. ## Compare: Cloud browsers - [Cloud browser providers compared](https://sandboxer.com/compare/cloud-browsers): every provider in this category in one table - [Sandboxer vs Anchor Browser](https://sandboxer.com/compare/anchor-browser.md): Cloud browsers for AI agents with managed authentication, persistent profiles and natural-language tasks. - [Sandboxer vs Browser Use (cloud)](https://sandboxer.com/compare/browser-use-cloud.md): Hosted cloud browsers and agent platform from Browser Use, with pay-as-you-go pricing and an open-source library. - [Sandboxer vs Browserbase](https://sandboxer.com/compare/browserbase.md): Headless browser infrastructure for AI agents, with Stagehand SDK, search/fetch and monthly plans. - [Sandboxer vs BrowserCloud](https://sandboxer.com/compare/browsercloud.md): Hosted browsers for automation and AI agents with stealth, proxies and live view. - [Sandboxer vs Browserless](https://sandboxer.com/compare/browserless.md): Managed headless browser platform for scraping, PDFs and AI agents, with BrowserQL and REST APIs. - [Sandboxer vs CloudCruise](https://sandboxer.com/compare/cloudcruise.md): Healthcare browser automation platform for payer portals and EHRs, with a builder agent and managed VMs. - [Sandboxer vs Cloudflare Browser Run (Browser Rendering)](https://sandboxer.com/compare/cloudflare-browser-run.md): Headless Chrome on Cloudflare's network, driven from Workers or REST, billed by browser hour. - [Sandboxer vs Firecrawl](https://sandboxer.com/compare/firecrawl.md): Web data API for scrape, crawl, search and an interactive browser sandbox for agents, billed in credits. - [Sandboxer vs GoLogin Cloud Browser](https://sandboxer.com/compare/gologin-cloud-browser.md): Real Chrome in the cloud with persistent fingerprinted profiles, driven over CDP, from $4.50/month. - [Sandboxer vs Hyperbeam](https://sandboxer.com/compare/hyperbeam.md): Embeddable virtual computers (browser, Android) streamed into your web app, priced per participant-minute. - [Sandboxer vs Hyperbrowser](https://sandboxer.com/compare/hyperbrowser.md): Cloud browser infrastructure for AI agents with credit-based plans and proxies. - [Sandboxer vs Kernel (onkernel)](https://sandboxer.com/compare/kernel.md): Cloud browsers for agents with per-second billing, standby mode and browser pools. - [Sandboxer vs Lightpanda Cloud](https://sandboxer.com/compare/lightpanda-cloud.md): Hosted endpoint for Lightpanda, an open-source headless browser written in Zig, or Chrome, over CDP. - [Sandboxer vs Notte](https://sandboxer.com/compare/notte.md): Cloud browser sessions, agents and functions for web automation, with monthly plans and credits. - [Sandboxer vs Opensteer](https://sandboxer.com/compare/opensteer.md): AI agents that browse the web on schedules, with an MIT-licensed browser-control runtime and hosted cloud browsers. - [Sandboxer vs Remote Browser](https://sandboxer.com/compare/remote-browser.md): Cloud Chromium sessions over CDP with stealth mode, persistent profiles, live viewer and recordings. - [Sandboxer vs Scrapeless (Scraping Browser)](https://sandboxer.com/compare/scrapeless-scraping-browser.md): Cloud scraping browser with residential proxies, CAPTCHA solving and persistent profiles. - [Sandboxer vs Scrapfly Cloud Browser](https://sandboxer.com/compare/scrapfly-cloud-browser.md): Scrapfly's pay-per-minute cloud browsers with geo-located residential exits, over CDP. - [Sandboxer vs Steel](https://sandboxer.com/compare/steel.md): Browser API for AI agents; open-source Steel Browser plus a hosted cloud with session plans. - [Sandboxer vs Surfsky](https://sandboxer.com/compare/surfsky.md): Cloud Chromium with fingerprints, residential proxies and CAPTCHA solving for anti-bot scraping and automation. - [Sandboxer vs ZenRows (Scraping Browser)](https://sandboxer.com/compare/zenrows-scraping-browser.md): Remote scraping browser reached over a WebSocket, with rotating residential proxies and fingerprints. ## Compare: Clouds and VPS hosts - [Clouds and VPS hosts compared with Sandboxer](https://sandboxer.com/compare/clouds-and-vps): every provider in this category in one table - [Sandboxer vs Alibaba Cloud ACK](https://sandboxer.com/compare/alibaba-cloud-ack.md): Alibaba Cloud's managed Kubernetes service (Container Service for Kubernetes) on ECS, bare metal, GPU and serverless nodes. - [Sandboxer vs Alibaba Cloud ECS](https://sandboxer.com/compare/alibaba-cloud-ecs.md): Elastic Compute Service: virtual machines, bare metal and GPU instances on Alibaba Cloud with per-second pay-as-you-go billing. - [Sandboxer vs Amazon WorkSpaces](https://sandboxer.com/compare/amazon-workspaces.md): AWS managed virtual desktops (Windows and Linux) streamed to users, billed monthly or hourly. - [Sandboxer vs AWS EC2](https://sandboxer.com/compare/aws-ec2.md): General-purpose virtual machines on AWS: pick an instance type, run any Linux, billed per second. - [Sandboxer vs AWS Lambda](https://sandboxer.com/compare/aws-lambda.md): AWS's serverless functions service: event-driven code or container images, billed per request and GB-second. - [Sandboxer vs Azure Virtual Machines](https://sandboxer.com/compare/azure-virtual-machines.md): General-purpose Linux and Windows virtual machines on Microsoft Azure, billed per minute by size. - [Sandboxer vs Civo](https://sandboxer.com/compare/civo.md): Cloud compute instances, Kubernetes and GPUs billed hourly, with free egress and regional sovereign clouds. - [Sandboxer vs Contabo Cloud VPS](https://sandboxer.com/compare/contabo-cloud-vps.md): Low-cost unmanaged VPS plans on KVM with monthly contracts and data centres in nine regions. - [Sandboxer vs DigitalOcean Droplets](https://sandboxer.com/compare/digitalocean-droplets.md): DigitalOcean's Linux virtual machines with simple plans, per-second billing and 16 datacenters. - [Sandboxer vs E2E Networks](https://sandboxer.com/compare/e2e-networks.md): Indian cloud provider selling GPU cloud, CPU compute VMs and an AI platform (TIR). - [Sandboxer vs Exoscale](https://sandboxer.com/compare/exoscale.md): European cloud provider with KVM-based compute instances, GPU instances and per-second billing. - [Sandboxer vs Gcore Cloud VMs](https://sandboxer.com/compare/gcore-cloud-vms.md): Virtual machines from Gcore in Standard, CPU-, memory-optimized, high-frequency and GPU types across 30+ locations. - [Sandboxer vs GitHub Copilot cloud agent](https://sandboxer.com/compare/github-copilot-cloud-agent.md): GitHub's Copilot agent that works on repository tasks in an ephemeral cloud environment and opens pull requests. - [Sandboxer vs Google Cloud Run](https://sandboxer.com/compare/google-cloud-run.md): Google Cloud's managed platform for running containers that scale to zero, billed per second of CPU and memory. - [Sandboxer vs Google Compute Engine](https://sandboxer.com/compare/google-compute-engine.md): Google Cloud's general-purpose virtual machine service with a wide range of machine types, GPUs and global regions. - [Sandboxer vs Hetzner Cloud](https://sandboxer.com/compare/hetzner-cloud.md): Virtual servers on shared or dedicated vCPUs, priced hourly and monthly, in Germany, Finland, Singapore and the USA. - [Sandboxer vs Hetzner Dedicated (root servers)](https://sandboxer.com/compare/hetzner-dedicated-root-servers.md): Rented physical servers (AX, EX, GPU, SX, DX and other lines) in Germany and Finland, with full root access. - [Sandboxer vs Hostinger VPS](https://sandboxer.com/compare/hostinger-vps.md): KVM virtual private servers with root access, NVMe storage and prepaid monthly or multi-year plans. - [Sandboxer vs IBM Cloud VPC (Virtual Servers)](https://sandboxer.com/compare/ibm-cloud-vpc.md): Virtual server instances on IBM Cloud VPC, in balanced, compute and memory profiles, billed hourly. - [Sandboxer vs IONOS Cloud Compute](https://sandboxer.com/compare/ionos-cloud-compute.md): IONOS Cloud virtual servers (Cubes) in EU and US data centres, billed per minute. - [Sandboxer vs KakaoCloud Virtual Machine](https://sandboxer.com/compare/kakaocloud.md): Kakao Enterprise's public cloud VMs (Beyond Compute Service) in a Seoul region, with Linux, Windows and GPU images. - [Sandboxer vs Kamatera](https://sandboxer.com/compare/kamatera.md): Cloud VPS provider with custom-configured KVM servers, hourly or monthly billing, and data centers on four continents. - [Sandboxer vs Latitude.sh](https://sandboxer.com/compare/latitude-sh.md): Bare-metal servers, GPU servers and virtual machines with hourly and monthly pricing and 20 TB free outbound. - [Sandboxer vs Linode (Akamai Cloud)](https://sandboxer.com/compare/linode-akamai-cloud.md): Virtual machines (Linodes) on shared or dedicated CPU, billed hourly, now part of Akamai Cloud. - [Sandboxer vs machine0](https://sandboxer.com/compare/machine0.md): Persistent cloud VMs for CLI and MCP-driven agents, with static IPs, per-minute billing, optional GPUs and five regions. - [Sandboxer vs NAVER Cloud Platform Server](https://sandboxer.com/compare/naver-cloud-platform-server.md): NAVER Cloud's virtual server service, with hourly or monthly billing and separate GPU and bare-metal server products. - [Sandboxer vs netcup (VPS / root server)](https://sandboxer.com/compare/netcup.md): German hosting provider selling KVM VPS and root servers on monthly contracts from five locations. - [Sandboxer vs Open Telekom Cloud (ECS)](https://sandboxer.com/compare/open-telekom-cloud-ecs.md): Elastic Cloud Server virtual machines and metal instances on a KVM hypervisor, with hourly and reserved pricing, now branded T Cloud Public. - [Sandboxer vs Oracle Cloud Compute](https://sandboxer.com/compare/oracle-cloud-compute.md): Virtual machine and bare metal instances on Oracle Cloud Infrastructure, with flexible shapes billed per second. - [Sandboxer vs OVHcloud Public Cloud instances](https://sandboxer.com/compare/ovhcloud-public-cloud.md): OVHcloud's Public Cloud virtual instances: general purpose, GPU and other instance types billed hourly. - [Sandboxer vs Sakura Cloud](https://sandboxer.com/compare/sakura-cloud.md): Japanese cloud with virtual servers, dedicated-core plans, GPU servers and container hosting, billed hourly or daily with a 20-day monthly cap. - [Sandboxer vs Samsung Cloud Platform Virtual Server](https://sandboxer.com/compare/samsung-cloud-platform-virtual-server.md): Samsung SDS's enterprise cloud VM service with standard and high-capacity specs, custom images and usage-based billing. - [Sandboxer vs Self-hosted Firecracker](https://sandboxer.com/compare/self-hosted-firecracker.md): Open source microVM monitor from AWS that you run yourself on KVM-capable hosts. - [Sandboxer vs STACKIT Compute Engine](https://sandboxer.com/compare/stackit-compute-engine.md): STACKIT's European sovereign-cloud virtual machines, hourly billed in euros, with GPU instances. - [Sandboxer vs Ubicloud](https://sandboxer.com/compare/ubicloud.md): Cloud on bare-metal providers such as Hetzner, Leaseweb and AWS Bare Metal, with per-minute VM billing. - [Sandboxer vs UpCloud](https://sandboxer.com/compare/upcloud.md): European cloud provider selling Linux and Windows cloud servers, GPU servers and managed services. - [Sandboxer vs Vultr](https://sandboxer.com/compare/vultr.md): Public cloud with hourly-billed VMs (Cloud Compute, VX1), bare metal and NVIDIA GPU instances in 33 regions. ## Compare: App platforms - [App and serverless platforms compared with Sandboxer](https://sandboxer.com/compare/app-platforms): every provider in this category in one table - [Sandboxer vs Aptible](https://sandboxer.com/compare/aptible.md): Compliance-focused PaaS that runs Docker apps and managed databases on dedicated or shared stacks. - [Sandboxer vs AWS Fargate](https://sandboxer.com/compare/aws-fargate.md): Serverless container runtime for Amazon ECS: you give it a container image and CPU/memory, AWS runs the task. - [Sandboxer vs Azure Container Apps](https://sandboxer.com/compare/azure-container-apps.md): Serverless container platform with scale-to-zero, per-second billing, jobs, GPUs, and dynamic sessions for sandboxed code. - [Sandboxer vs Clever Cloud](https://sandboxer.com/compare/clever-cloud.md): European PaaS that deploys apps and Docker images onto per-instance VMs with autoscaling and per-second billing. - [Sandboxer vs Cloudflare Workers for Platforms](https://sandboxer.com/compare/cloudflare-workers-for-platforms.md): Cloudflare product for platforms to run customer or AI-generated code in isolated Workers on its global network. - [Sandboxer vs Fly.io Machines](https://sandboxer.com/compare/fly-io-machines.md): Fast-launching VMs from container images, controlled by a REST API, with per-second billing and region choice. - [Sandboxer vs Heroku](https://sandboxer.com/compare/heroku.md): Salesforce's long-running PaaS that runs apps in dynos (containers) with add-on data services. - [Sandboxer vs Hugging Face Jobs](https://sandboxer.com/compare/hugging-face-jobs.md): Pay-per-second batch compute on Hugging Face infrastructure: run a command in a Docker image on CPU, GPU or TPU hardware. - [Sandboxer vs InsForge](https://sandboxer.com/compare/insforge-instacloud.md): Open-source backend platform for AI-built apps (Postgres, auth, storage, functions) with a managed cloud and long-running compute containers. - [Sandboxer vs Mastra Cloud](https://sandboxer.com/compare/mastra-cloud.md): Hosted platform for deploying and observing Mastra AI agents and workflows, built on an Apache 2.0 TypeScript framework. - [Sandboxer vs Modelence](https://sandboxer.com/compare/modelence.md): Cloud platform that deploys and runs backends, databases and jobs for agent-written apps, plus an open-source framework. - [Sandboxer vs Red Hat OpenShift](https://sandboxer.com/compare/red-hat-openshift.md): Enterprise Kubernetes platform, self-managed or as managed services on AWS, Azure, Google Cloud and IBM Cloud. - [Sandboxer vs Render](https://sandboxer.com/compare/render.md): Cloud platform for web services, static sites, workers, cron jobs and databases, with early-access Sandboxes. - [Sandboxer vs Replit](https://sandboxer.com/compare/replit.md): AI app-building workspace with hosted deployments (Autoscale, Reserved VM, Static, Scheduled). - [Sandboxer vs Specific](https://sandboxer.com/compare/specific.md): Cloud platform where a coding agent defines and deploys an app and its infrastructure from one specific.hcl file. - [Sandboxer vs Tencent Cloud SCF (Serverless Cloud Function)](https://sandboxer.com/compare/tencent-cloud-scf.md): Serverless function service that runs event-triggered code with automatic scaling and usage-based billing. - [Sandboxer vs Tinfoil](https://sandboxer.com/compare/tinfoil.md): Confidential-computing AI cloud: private inference plus Docker containers run inside hardware-encrypted enclaves with attestation. - [Sandboxer vs Trigger.dev](https://sandboxer.com/compare/trigger-dev.md): Open-source platform for running long-running background tasks and workflows in TypeScript, billed per second of compute. - [Sandboxer vs Wasmer Edge](https://sandboxer.com/compare/wasmer-edge.md): Serverless edge platform that runs WebAssembly/WASIX apps and common languages with microsecond cold starts. - [Sandboxer vs Zeabur](https://sandboxer.com/compare/zeabur.md): Deployment platform that runs apps, Docker images and templates on servers you buy through it or bring from other clouds. ## Compare: CI and build services - [CI and build services compared with Sandboxer](https://sandboxer.com/compare/ci-and-build): every provider in this category in one table - [Sandboxer vs AWS CodeBuild](https://sandboxer.com/compare/aws-codebuild.md): Managed continuous-integration build service from AWS that runs build commands on on-demand or reserved compute. - [Sandboxer vs Azure Pipelines](https://sandboxer.com/compare/azure-pipelines.md): Microsoft's CI/CD service that runs jobs on Microsoft-hosted agents (fresh VM per job) or your own self-hosted agents. - [Sandboxer vs Bitbucket Pipelines](https://sandboxer.com/compare/bitbucket-pipelines.md): Atlassian's CI/CD built into Bitbucket Cloud; steps run in Docker images with size multipliers. - [Sandboxer vs Bitrise](https://sandboxer.com/compare/bitrise.md): Mobile-focused CI/CD service with hosted macOS and Linux build machines, plus Build Hub runners for GitHub Actions. - [Sandboxer vs Blacksmith](https://sandboxer.com/compare/blacksmith.md): Drop-in GitHub Actions runners on Firecracker microVMs, with caching and Docker build acceleration. - [Sandboxer vs Buildkite hosted agents](https://sandboxer.com/compare/buildkite-hosted-agents.md): Buildkite's managed CI agents on Linux, macOS and Windows, billed per vCPU-minute, alongside self-hosted agents. - [Sandboxer vs CircleCI](https://sandboxer.com/compare/circleci.md): Hosted CI/CD with Docker, Linux VM, macOS, Windows and GPU resource classes billed in credits. - [Sandboxer vs Codemagic](https://sandboxer.com/compare/codemagic.md): CI/CD for mobile and Flutter apps on macOS and Linux machines, billed per minute or annually. - [Sandboxer vs Depot](https://sandboxer.com/compare/depot.md): Fast container builds and GitHub Actions runners on ephemeral AWS instances, with a newer sandbox product. - [Sandboxer vs Expo EAS Build](https://sandboxer.com/compare/expo-eas-build.md): Expo's cloud build service for Android and iOS apps, priced per build. - [Sandboxer vs GitHub Actions hosted runners](https://sandboxer.com/compare/github-actions-hosted-runners.md): GitHub-managed virtual machines that run Actions workflow jobs, with larger and GPU runners on paid plans. - [Sandboxer vs GitLab.com hosted runners](https://sandboxer.com/compare/gitlab-hosted-runners.md): GitLab-managed runners for GitLab.com pipelines on Linux (Windows and macOS in beta), metered in compute minutes. - [Sandboxer vs Google Cloud Build](https://sandboxer.com/compare/google-cloud-build.md): Google Cloud's managed CI/CD service that runs build steps as containers on default or private pools. - [Sandboxer vs RunsOn](https://sandboxer.com/compare/runs-on.md): Self-hosted GitHub Actions runners that launch one ephemeral EC2 instance per job in your own AWS account. - [Sandboxer vs StarSling](https://sandboxer.com/compare/starsling.md): AI-native CI: drop-in GitHub Actions runners on single-use microVMs, plus agents that optimise workflows. - [Sandboxer vs WarpBuild](https://sandboxer.com/compare/warpbuild.md): Drop-in GitHub Actions runners on cloud VMs, plus Docker builders and bring-your-own-cloud. ## Compare: GPU clouds - [GPU clouds compared with Sandboxer](https://sandboxer.com/compare/gpu-clouds): every provider in this category in one table - [Sandboxer vs Baseten](https://sandboxer.com/compare/baseten.md): Platform for model inference and training with dedicated deployments billed per minute. - [Sandboxer vs Cerebrium](https://sandboxer.com/compare/cerebrium.md): Serverless GPU and CPU platform for deploying AI apps, billed per second of compute. - [Sandboxer vs Crusoe Cloud](https://sandboxer.com/compare/crusoe-cloud.md): AI infrastructure cloud with GPU and CPU VMs, GPU clusters and managed inference. - [Sandboxer vs Hyperstack](https://sandboxer.com/compare/hyperstack.md): GPU cloud from NexGen Cloud with on-demand and reserved GPU VMs billed per minute. - [Sandboxer vs Jarvislabs](https://sandboxer.com/compare/jarvislabs.md): GPU cloud with container instances, full VMs and serverless endpoints, billed per minute, with India regions. - [Sandboxer vs Nebius AI Cloud](https://sandboxer.com/compare/nebius.md): Hyperscale-style AI cloud with GPU and CPU virtual machines, preemptible capacity and GPU clusters. - [Sandboxer vs OVHcloud GPU instances](https://sandboxer.com/compare/ovhcloud-gpu.md): Public Cloud GPU instances (H100, L40S, L4 and more) virtualised with KVM, billed hourly or monthly. - [Sandboxer vs Paperspace (DigitalOcean)](https://sandboxer.com/compare/paperspace.md): Cloud GPU and CPU virtual machines, notebooks and container deployments, now part of DigitalOcean. - [Sandboxer vs Replicate](https://sandboxer.com/compare/replicate.md): Cloud API for running, fine-tuning and deploying AI models, billed per second of hardware or per output. - [Sandboxer vs Runpod](https://sandboxer.com/compare/runpod.md): GPU cloud with container Pods, serverless endpoints and clusters, per-second billing, Community and Secure tiers. - [Sandboxer vs SF Compute](https://sandboxer.com/compare/sf-compute.md): GPU cloud selling reserved clusters, VMs, bare metal and Slurm, with a market to resell unused capacity. - [Sandboxer vs Verda (formerly DataCrunch)](https://sandboxer.com/compare/verda.md): Dedicated CPU and GPU cloud instances with on-demand and spot pricing, from H100 to GB300. ## Docs: Sandboxes - [Machines & sizes](https://sandboxer.com/docs/machines.md): What every sandbox is, the four sizes, and how to change size. - [Regions](https://sandboxer.com/docs/regions.md): US East (Virginia) and EU Central (Finland), and how a region is chosen. - [Snapshots](https://sandboxer.com/docs/snapshots.md): Stop, resume with memory, fork, and named snapshots. - [Hosting](https://sandboxer.com/docs/hosting.md): Serve any port on a stable HTTPS URL. - [SSH & file transfer](https://sandboxer.com/docs/ssh.md): Shells, scp, port forwarding and direct IPv6. - [Long-running tasks](https://sandboxer.com/docs/long-running.md): Auto-stop, background commands, history and services. - [Environments & secrets](https://sandboxer.com/docs/environments.md): Variables, secret files and repos that new sandboxes start with. ## Docs: Agents & desktop - [Integrated agents](https://sandboxer.com/docs/agents.md): Run Claude Code, Codex, OpenCode and more inside a sandbox. - [Desktop](https://sandboxer.com/docs/desktop.md): A streamed Linux desktop with Chrome, for people and computer-use agents. ## Docs: Agent frameworks - [MCP server](https://sandboxer.com/docs/mcp.md): Hosted at https://sandboxer.com/mcp: connect Claude, ChatGPT, Claude Code, Codex, Cursor or any MCP client (OAuth or an API key), or run sbx mcp locally. - [Claude Agent SDK](https://sandboxer.com/docs/claude-agent-sdk.md): Run the code your Claude agent writes in a Sandboxer sandbox. - [OpenAI Agents SDK](https://sandboxer.com/docs/openai-agents.md): Give an OpenAI agent a cloud sandbox to run code in. - [LangChain & LangGraph](https://sandboxer.com/docs/langchain.md): Sandboxer tools for LangChain agents and LangGraph graphs. ## Docs: Build - [API reference](https://sandboxer.com/docs/api.md): Every endpoint of the public HTTP API. - [TypeScript SDK](https://sandboxer.com/docs/sdk-typescript.md): sandboxer-sdk for Node, Bun, Deno and browsers. - [Python SDK](https://sandboxer.com/docs/sdk-python.md): The sandboxer-sdk package for Python 3.10+. - [CLI reference](https://sandboxer.com/docs/cli.md): Every sbx command and flag. - [API keys](https://sandboxer.com/docs/api-keys.md): Create, scope, rotate and revoke keys. - [Webhooks](https://sandboxer.com/docs/webhooks.md): Signed lifecycle events delivered to your endpoint. - [OpenTelemetry](https://sandboxer.com/docs/opentelemetry.md): Export metrics and lifecycle events over OTLP. - [Daytona-compatible API](https://sandboxer.com/docs/daytona.md): Point the Daytona SDK at Sandboxer by changing the API URL and key. ## Docs: Account - [Organizations](https://sandboxer.com/docs/organizations.md): Shared wallets, members, seats and caps. - [Billing](https://sandboxer.com/docs/billing.md): Per-second billing, plans, packs and the trial. - [Limits & errors](https://sandboxer.com/docs/limits.md): Concurrency, start limits and error codes. - [Security](https://sandboxer.com/docs/security.md): How sandboxes are isolated and how secrets are handled. ## Optional One page per API operation; the same content is in https://sandboxer.com/openapi.yaml. - [Get current Sandboxer user](https://sandboxer.com/docs/api/me.md): GET /me - [List organizations](https://sandboxer.com/docs/api/listOrganizations.md): GET /orgs - [Create an organization](https://sandboxer.com/docs/api/createOrganization.md): POST /orgs - [List organization members and pending invites](https://sandboxer.com/docs/api/orgMembers.md): GET /orgs/{orgId}/members - [Set the active organization](https://sandboxer.com/docs/api/setActiveOrganization.md): PATCH /orgs/active - [Get account data-retention policy](https://sandboxer.com/docs/api/getDataRetention.md): GET /account/data-retention - [Update account data-retention policy](https://sandboxer.com/docs/api/updateDataRetention.md): PATCH /account/data-retention - [Turn storage auto-delete on or off](https://sandboxer.com/docs/api/updateStorage.md): PATCH /account/storage - [Get deletion operation](https://sandboxer.com/docs/api/getDeletionOperation.md): GET /deletion-operations/{operationId} - [List regions](https://sandboxer.com/docs/api/listRegions.md): GET /regions - [Get Sandboxer limits](https://sandboxer.com/docs/api/limits.md): GET /limits - [List GitHub repositories available to Sandboxer](https://sandboxer.com/docs/api/repos.md): GET /repos - [Select repository for sandboxes](https://sandboxer.com/docs/api/selectRepo.md): POST /repos - [List API keys](https://sandboxer.com/docs/api/apiKeys.md): GET /api-keys - [Create a scoped API key](https://sandboxer.com/docs/api/createScopedApiKey.md): POST /api-keys/scoped - [Revoke an API key](https://sandboxer.com/docs/api/revokeApiKey.md): DELETE /api-keys/{apiKeyId} - [Rotate an API key](https://sandboxer.com/docs/api/rotateApiKey.md): POST /api-keys/{apiKeyId}/rotate - [Get API key usage](https://sandboxer.com/docs/api/apiKeyUsage.md): GET /api-keys/{apiKeyId}/usage - [List webhooks](https://sandboxer.com/docs/api/listWebhooks.md): GET /webhooks - [Create webhook](https://sandboxer.com/docs/api/createWebhook.md): POST /webhooks - [Get webhook](https://sandboxer.com/docs/api/getWebhook.md): GET /webhooks/{webhookId} - [Update webhook](https://sandboxer.com/docs/api/updateWebhook.md): PATCH /webhooks/{webhookId} - [Delete webhook](https://sandboxer.com/docs/api/deleteWebhook.md): DELETE /webhooks/{webhookId} - [Rotate webhook signing secret](https://sandboxer.com/docs/api/rotateWebhookSigningSecret.md): POST /webhooks/{webhookId}/rotate - [Get OpenTelemetry export](https://sandboxer.com/docs/api/getTelemetry.md): GET /telemetry - [Set OpenTelemetry export](https://sandboxer.com/docs/api/setTelemetry.md): PUT /telemetry - [Remove OpenTelemetry export](https://sandboxer.com/docs/api/deleteTelemetry.md): DELETE /telemetry - [Get Sandboxer secrets setup](https://sandboxer.com/docs/api/secrets.md): GET /secrets - [Update Sandboxer secrets setup](https://sandboxer.com/docs/api/updateSecrets.md): POST /secrets - [List Sandbox environments](https://sandboxer.com/docs/api/environments.md): GET /environments - [Create a sandbox environment](https://sandboxer.com/docs/api/createEnvironment.md): POST /environments - [Update a sandbox environment](https://sandboxer.com/docs/api/updateEnvironment.md): PUT /environments/{environmentId} - [Delete a sandbox environment](https://sandboxer.com/docs/api/deleteEnvironment.md): DELETE /environments/{environmentId} - [Upgrade sandboxes to an environment's latest version](https://sandboxer.com/docs/api/upgradeEnvironment.md): POST /environments/{environmentId}/upgrade - [Set one environment variable](https://sandboxer.com/docs/api/setEnvironmentVar.md): PUT /environments/{environmentId}/vars/{key} - [Remove one environment variable](https://sandboxer.com/docs/api/deleteEnvironmentVar.md): DELETE /environments/{environmentId}/vars/{key} - [Write one secret file](https://sandboxer.com/docs/api/setEnvironmentSecretFile.md): PUT /environments/{environmentId}/secret-files - [Remove one secret file](https://sandboxer.com/docs/api/deleteEnvironmentSecretFile.md): DELETE /environments/{environmentId}/secret-files - [Add a repository to an environment](https://sandboxer.com/docs/api/addEnvironmentRepo.md): POST /environments/{environmentId}/repos - [Remove a repository from an environment](https://sandboxer.com/docs/api/deleteEnvironmentRepo.md): DELETE /environments/{environmentId}/repos/{repositoryId} - [List sandboxes](https://sandboxer.com/docs/api/sandboxes.md): GET /sandboxes - [Create sandbox](https://sandboxer.com/docs/api/create.md): POST /sandboxes - [Get sandbox](https://sandboxer.com/docs/api/get.md): GET /sandboxes/{sandboxId} - [Update sandbox](https://sandboxer.com/docs/api/update.md): PATCH /sandboxes/{sandboxId} - [Permanently delete sandbox data](https://sandboxer.com/docs/api/deleteSandbox.md): DELETE /sandboxes/{sandboxId} - [Stop and archive sandbox](https://sandboxer.com/docs/api/stop.md): POST /sandboxes/{sandboxId}/stop - [Share sandbox with the organization](https://sandboxer.com/docs/api/share.md): POST /sandboxes/{sandboxId}/share - [Recover a sandbox that stopped responding](https://sandboxer.com/docs/api/recover.md): POST /sandboxes/{sandboxId}/recover - [Resume sandbox](https://sandboxer.com/docs/api/resume.md): POST /sandboxes/{sandboxId}/resume - [Fork sandbox](https://sandboxer.com/docs/api/fork.md): POST /sandboxes/{sandboxId}/fork - [Prompt Sandbox](https://sandboxer.com/docs/api/prompt.md): POST /sandboxes/{sandboxId}/prompt - [List sandboxer events](https://sandboxer.com/docs/api/events.md): GET /sandboxes/{sandboxId}/events - [List sandboxer conversations](https://sandboxer.com/docs/api/conversations.md): GET /sandboxes/{sandboxId}/conversations - [Get prompt run status](https://sandboxer.com/docs/api/promptRunStatus.md): GET /sandboxes/{sandboxId}/prompts/{promptId} - [Get a stop by id](https://sandboxer.com/docs/api/getStop.md): GET /sandboxes/{sandboxId}/stops/{stopId} - [Read a file from a sandbox](https://sandboxer.com/docs/api/readFile.md): GET /sandboxes/{sandboxId}/files - [Write a file in a sandbox](https://sandboxer.com/docs/api/writeFile.md): PUT /sandboxes/{sandboxId}/files - [Execute a command in a sandbox](https://sandboxer.com/docs/api/command.md): POST /sandboxes/{sandboxId}/commands - [Get detached command status and logs](https://sandboxer.com/docs/api/commandStatus.md): GET /sandboxes/{sandboxId}/commands/{processId} - [Stop a detached command](https://sandboxer.com/docs/api/stopCommand.md): DELETE /sandboxes/{sandboxId}/commands/{processId} - [Attach to a detached command](https://sandboxer.com/docs/api/attachCommand.md): GET /sandboxes/{sandboxId}/commands/{processId}/stream - [List the command and process history](https://sandboxer.com/docs/api/commandHistory.md): GET /sandboxes/{sandboxId}/command-history - [Get one command from the history](https://sandboxer.com/docs/api/getCommand.md): GET /sandboxes/{sandboxId}/command-history/{commandId} - [Read a command's stored output](https://sandboxer.com/docs/api/commandLogs.md): GET /sandboxes/{sandboxId}/command-history/{commandId}/logs - [List the processes in a sandbox](https://sandboxer.com/docs/api/processes.md): GET /sandboxes/{sandboxId}/processes - [Download a sandbox artifact](https://sandboxer.com/docs/api/artifact.md): GET /sandboxes/{sandboxId}/artifacts - [Steer a running turn](https://sandboxer.com/docs/api/steer.md): POST /sandboxes/{sandboxId}/steer - [Interrupt running work](https://sandboxer.com/docs/api/interrupt.md): POST /sandboxes/{sandboxId}/interrupt - [Get desktop streaming URL](https://sandboxer.com/docs/api/desktop.md): POST /sandboxes/{sandboxId}/desktop - [List hosted ports](https://sandboxer.com/docs/api/listHostedPorts.md): GET /sandboxes/{sandboxId}/host - [Expose a sandbox port on a public HTTPS URL](https://sandboxer.com/docs/api/hostPort.md): POST /sandboxes/{sandboxId}/host - [Hide a hosted port](https://sandboxer.com/docs/api/unhostPort.md): DELETE /sandboxes/{sandboxId}/host - [Configure sandbox SSH key](https://sandboxer.com/docs/api/sshKey.md): POST /sandboxes/{sandboxId}/sshkey - [Interactive exec over WebSocket](https://sandboxer.com/docs/api/execWebSocket.md): GET /sandboxes/{sandboxId}/exec/ws - [Raw TCP tunnel to the sandbox SSH server over WebSocket](https://sandboxer.com/docs/api/sshWebSocket.md): GET /sandboxes/{sandboxId}/ssh - [Live resource usage](https://sandboxer.com/docs/api/stats.md): GET /sandboxes/{sandboxId}/stats - [Resource usage history](https://sandboxer.com/docs/api/metrics.md): GET /sandboxes/{sandboxId}/metrics - [Usage sparklines for many sandboxes](https://sandboxer.com/docs/api/metricsSummary.md): GET /sandboxes/metrics - [List agent providers and models](https://sandboxer.com/docs/api/providerModels.md): GET /provider-models - [List named snapshots](https://sandboxer.com/docs/api/listNamedSnapshots.md): GET /named-snapshots - [Save a named snapshot](https://sandboxer.com/docs/api/saveNamedSnapshot.md): POST /named-snapshots - [Get a named snapshot](https://sandboxer.com/docs/api/getNamedSnapshot.md): GET /named-snapshots/{name} - [Remove a named snapshot](https://sandboxer.com/docs/api/deleteNamedSnapshot.md): DELETE /named-snapshots/{name} - [List share codes of a named snapshot](https://sandboxer.com/docs/api/listSnapshotShares.md): GET /named-snapshots/{name}/shares - [Share a named snapshot](https://sandboxer.com/docs/api/createSnapshotShare.md): POST /named-snapshots/{name}/shares - [Revoke a share code](https://sandboxer.com/docs/api/revokeSnapshotShare.md): DELETE /named-snapshots/{name}/shares/{shareId} - [List snapshots](https://sandboxer.com/docs/api/listSnapshots.md): GET /snapshots - [List sandboxer snapshots](https://sandboxer.com/docs/api/listSandboxSnapshots.md): GET /sandboxes/{sandboxId}/snapshots - [Permanently delete all snapshots of a sandbox](https://sandboxer.com/docs/api/deleteSandboxSnapshots.md): DELETE /sandboxes/{sandboxId}/snapshots - [Get latest sandboxer snapshot](https://sandboxer.com/docs/api/getLatestSandboxSnapshot.md): GET /sandboxes/{sandboxId}/snapshots/latest - [Get sandboxer usage](https://sandboxer.com/docs/api/usage.md): GET /sandboxes/{sandboxId}/usage - [Permanently delete snapshot data](https://sandboxer.com/docs/api/deleteSnapshot.md): DELETE /snapshots/{snapshotId} - [Get snapshot file tree](https://sandboxer.com/docs/api/getSnapshotTree.md): GET /snapshots/{snapshotId}/tree - [Download a file or folder from a snapshot](https://sandboxer.com/docs/api/getSnapshotFile.md): GET /snapshots/{snapshotId}/files - [Get snapshot download](https://sandboxer.com/docs/api/getSnapshotDownload.md): GET /snapshots/{snapshotId}/download