Render Sandboxes

Render Sandboxes, currently in beta, gives every AI agent its own isolated compute, persistent state, and filesystem. In the product's own words, it is a computer for every agent. Each sandbox is a separate Linux computer that an agent can use to run commands, keep files, and return to work it left running, rather than operating inside the same environment as the application it serves. Sandboxes are designed for developers building agents and agent harnesses — the product cites Claude Code and Codex as examples of what can run inside one — as well as for teams that need a safe place to execute untrusted code. The stated purpose is to give agents real tools, files, and processes that persist between sessions, all on the same platform as the rest of the application. Agents need somewhere to work. Running a coding agent or an autonomous task loop directly on application infrastructure raises practical questions: where do the files live between runs, how do you stop one agent from reaching another's data, and what happens to compute spend when the agent sits idle waiting for input. Render Sandboxes addresses those questions by making the sandbox the unit of work. Each one is isolated, so user-submitted code, model output, and uploaded files stay separated from the app's data and secrets. Each one persists, so an agent can pick up where it left off. And each one can be suspended, so idle waiting does not accumulate compute charges. The product also targets scale: Render says you can reliably run thousands of sandboxes at once, on the same platform as the rest of your app. Sandbox lifecycle is managed with TypeScript or Python SDKs or a CLI. The documented flow is explicit: create a sandbox and set a maximum lifetime, then wait until the sandbox is ready. From there you upload files and download artifacts, moving inputs into the sandbox and pulling out the files the code generates. You can run commands and stream output, receiving stdout, stderr, and the command's exit code as it arrives rather than waiting for a batch result. The quickstart example shows the same sequence in code: create a sandbox with a timeout, upload a task file, execute a Python agent followed by a test run, capture a snapshot, and terminate. Because output streams, an agent can inspect a failure and try a fix inside the same session. Snapshots give sandboxes a starting point. You can save a snapshot of a sandbox and later fork an independent sandbox from it, running processes included — so a session that has already installed dependencies, cloned a repository, or started a service does not have to repeat that work. New sandboxes can also start from custom images or saved snapshots preloaded with the files and tools each task needs, which Render describes as giving agents a head start. Multiple agents can work from the same starting point by forking the same snapshot, and each fork is independent. This matters for parallelism: instead of provisioning a fresh environment per task and paying the setup cost every time, you snapshot a known-good state once and branch from it. Isolation is the core of the design. Each Render sandbox runs in its own Firecracker microVM, so agents can use Docker and return to processes they left running without sharing a kernel with anything else. On top of isolation, Render provides access controls. You decide which domains each sandbox can reach: outbound requests can be limited to approved domains, or outbound traffic can be blocked entirely. Render API keys can be created with only the permissions a task needs — for example, managing sandboxes without access to other services (listed as early access). Sensitive credentials can be brokered: approved API requests are authenticated without giving sandbox code the raw keys or tokens (also early access). Together these controls let teams run untrusted code without handing it the keys to production. Overall, the approach is to treat each agent's environment as a disposable, resumable machine rather than a long-lived server. Sandboxes start in under a second, even when traffic arrives in bursts, and they run on the same platform as the rest of your application, so the agent's compute sits alongside the app it is working on rather than in a separate system to be wired up. Sandboxes suspend automatically when idle, with no compute charges until your agent sends its next command, and they wake with files and memory intact. While a sandbox runs, you are billed only for the CPU it actually uses. The benefits follow from those mechanics. Agents keep their work between sessions instead of rebuilding context and environment on every run. Failures are visible and debuggable because logs, errors, and exit codes stream back. Setup cost is paid once and reused through snapshots and custom images. Demand spikes are absorbed because start times stay under a second and thousands of sandboxes can run concurrently. Spend tracks actual CPU use rather than wall-clock time spent waiting for input, since idle sandboxes are suspended. And risk is contained: untrusted code, model output, and uploaded files stay isolated from application data and secrets. Render names three use cases directly. First, run your agent inside a sandbox: give agents tools, files, and processes that persist between sessions. Second, spin up a full copy of your app: run your whole stack with Docker Compose inside a sandbox so your agents can test changes end to end. Third, safely execute untrusted code: keep user-submitted code, model output, and uploaded files isolated from your app's data and secrets. The lifecycle primitives extend these — snapshots and forks support multiple agents working from the same starting point, and streamed output supports agents that iterate on a failing test, while sub-second starts support bursty workloads where many sandboxes are needed at once. The product is aimed at developers and teams building agents and agent harnesses, and at applications that need to execute code they did not write. It fits teams already deploying on Render, since sandboxes live on the same platform, and it is exposed through TypeScript and Python SDKs and a CLI, with a quickstart that walks through installing the Render CLI, signing in through the browser, creating a sandbox, running a command, and terminating. Pricing is usage-based: sandboxes suspend when idle, there are no compute charges until the next command, and while running you pay only for the CPU actually used. Render points to its pricing page for details. Render Sandboxes packages a simple idea — a computer for every agent — into an operational one. Isolation comes from Firecracker microVMs; persistence comes from a filesystem and snapshots that survive suspension and can be forked; control comes from domain restrictions, scoped API keys, and credential brokering; and economics come from suspending idle sandboxes and billing actual CPU. As Stuart Layton, Head of Technology at FinQore, puts it in the customer quote on the page, Render Sandboxes have kept the promise of moving fast. For teams putting agents to work on real code and real files, it is a way to give them a machine without giving them the keys.