Today we’re launching Render Sandboxes in public beta. Render Sandboxes let you safely give your agents a computer to work with: a fully isolated Linux environment where they can install dependencies, edit files, and run code.
Each sandbox starts quickly, runs indefinitely, and automatically suspends when idle. You can reliably run thousands at once and lock down what each one can reach. You’re billed for CPU only when your agents are actually using it.
Render Sandboxes work with any agent harness and model. You can operate sandboxes through the TypeScript or Python SDK, or the Render CLI.
Check out our quickstart, or share this prompt with your coding agent:
Agents need a computer of their own
Agents doing complex work need a separate machine for each task or user, isolated from your app and from each other. And since agent work comes in bursts, those machines need to start and stop with demand.
A web service isn’t built for this. Its instances stay up and serve all your users, and a new deploy can take minutes.
Render Sandboxes give each user or task its own machine the moment it’s needed. Each sandbox runs in its own Firecracker microVM.
We’ve long been fans of Render because it enables us to move fast, and Render Sandboxes have kept that promise. Sandboxes are the runtime for the agents in our software factory, and they let our customers securely run custom code on our platform. All in, setting up Sandboxes was fast and easy, which meant less time solving infrastructure challenges and more time solving customer problems.
Built to handle long-running work
Render Sandboxes can run indefinitely, so an agent on a multi-day task like a codebase migration keeps its running app, processes, and memory the whole time.
Each sandbox starts from an image: Render’s default, or a custom image that already includes your agent harness, dependencies, and configuration. From there, two types of snapshots can capture its progress:
- A filesystem snapshot saves files and installed tools. Use it to skip setup on new sandboxes, or to carry an agent’s notes from one session to the next.
- A runtime snapshot (the default) also saves memory and running processes, so your agent picks up mid-task instead of reloading its state from disk. This can make startup 3x to 10x faster.
By default, when a sandbox idles without a command, Render automatically snapshots and suspends it, and then wakes it back up on the next command. Importantly, you don’t pay for CPU or memory while a sandbox is suspended. (The default idle timeout of 15 minutes is configurable, and auto-suspend is optional.)
With the TypeScript and Python SDKs, you can also snapshot a sandbox yourself and restore it in a new one later:
Keep each sandbox secure
Agents often need network access and API keys to do useful work. Render Sandboxes let you grant them both, while controlling where each sandbox can send data and the keys it can see. This helps protect against situations such as an agent falling for a prompt injection attack, or unknowingly running malicious code.
Each sandbox has its own outbound network policy: allow all traffic, allow only a list of domains, or block outbound traffic entirely.
Render Sandboxes also support credential brokering, which keeps your API keys out of the sandbox entirely. Code inside the sandbox sends requests without credentials, and a broker outside the sandbox safely adds the right key or token as each request leaves for an allowed domain. This means a prompt injection attack can’t result in leaked keys.
You can also create scoped API keys with only the permissions a task needs, like managing sandboxes without access to your other services. That means you don't need to worry about (for instance) your agent mistakenly deleting your database because it can manage sandboxes.
Credential brokering and scoped API keys are currently in early access and are being rolled out to more customers. To request access, fill out the credential brokering form and/or the scoped API keys form.
Pay for the CPU your agent actually uses
A running sandbox is billed for actively-used CPU (not simply provisioned CPU), as well as memory allocated to it. That means waiting on a model or a person doesn’t cost you CPU time.
Once a sandbox is suspended, the memory charge stops too, and you pay only for its snapshot storage.
Render Sandboxes are available in Oregon on all workspace plans. See the pricing page for more.
Scale reliably from one sandbox to thousands
While sandboxes are new to Render, reliably spinning up isolated environments on demand is not. Render already does this for every build, more than one million times a day.
Drawing on that experience, we built Render Sandboxes to hold up whether you run one sandbox or thousands. Each one is typically ready for its first command in under one second; even faster when it’s restored from a snapshot. Expect startup time to improve through the beta.
Your sandboxes run next to the rest of your app
Your sandboxes live in the same Render workspace as the web services, background workers, and databases that make up the rest of your app. You manage them with Render API keys, through the Render CLI or the same SDK you’d use for Render Workflows, and they’re billed alongside your other Render services. There’s no extra provider to manage.
Inside a sandbox, agents can use Docker and Docker Compose to start a copy of your app and its database side by side, then test their changes before you deploy.
Render Sandboxes also pair well with Render Workflows. You can use Workflows for the steps that should happen the same way every time, like fetching inputs, calling a model, and saving the output. Sandboxes are best suited to the non-deterministic part, where the agent decides what to do next and needs its state to carry over between runs.
Get started
To try Render Sandboxes in code, install the TypeScript SDK with npm install @renderinc/sdk or the Python SDK with pip install render, set RENDER_API_KEY and RENDER_WORKSPACE_ID in your app's environment, and run your first command in a sandbox:
Or start with your coding agent:
- Install the Render Sandboxes skill.
- Have your agent build from a template: a software factory, a vibe-coding app, or a support engineering triage agent.
For the full SDK and CLI reference, see the Sandboxes docs. To run Claude Managed Agents, Cursor Cloud Agents, or the OpenAI Agents API in a sandbox, follow our setup guides.
What's next
Render Sandboxes are in public beta today. On the way to general availability, we're working on:
- Private networking, so sandboxes can reach the rest of your Render services without going over the public internet.
- More regions beyond Oregon.
- SSH access and public URLs, so you can work inside a running sandbox and open the app an agent started from your browser.
- CPU and memory bursting, so a sandbox can temporarily use more resources for heavy work without moving to a larger size.
- Shared Filesystems are also coming soon. A Shared Filesystem gives your sandboxes and workflow tasks the same persistent files, so parallel agents can read shared inputs, write their own outputs, and build on each other's work. Files stay put after the compute that used them shuts down. Request early access.
As agents become part of more products, giving each one a computer should be the easy part. We’re excited to see what this helps you build.