Render
The cloud for AI-native applications
5.0•80 reviews•1.5K followers
The cloud for AI-native applications
5.0•80 reviews•1.5K followers
Render is the AI-native cloud platform, used by more than 8 million builders. It gives teams an intuitive way to deploy and scale the AI agents inside their products, the long-running services behind them, and the data they depend on, all on a single platform. Git-based deploys, private networking, and preview environments come built in, with no glue code to write.
This is the 2nd launch from Render. View more
Render Sandboxes
Launching today
Render Sandboxes give every agent its own isolated Linux computer.
Sandboxes starts in under a second and can run any agent or harness, like Claude Code or Codex. Your agent can also run your app with Docker Compose to test its changes.
You decide which domains each sandbox can reach. When your agent goes idle, the sandbox suspends and compute charges stop. It wakes with files and memory intact. And you can reliably run thousands at once - all on the same platform as the rest of your app.
Launch Team / Built With
Dropbox SignSimple, secure eSignatures for the way your team works.
Promoted
Congrats on the launch! How would you recommend running long AI jobs alongside a web API on Render? I'd be especially interested in what happens to jobs already in progress during a deployment.
@stan_xu1 thank you! We're excited to be able to get this in the hands of users.
It depends on the shape of your AI jobs! Render Workflows can be a great way to run more deterministic pipelines, and they'll be able to handle deployments in the middle of a running workflow. Sandboxes are also a great way to run long running AI jobs, since you can run them for as long as you'd like.
Hey Product Hunt 👋 I'm Slav, PM for Render Sandboxes.
The work agents are given is becoming increasingly complex. Like people, agents need machines on which to do this work, so they can write and run code, install dependencies, manipulate files, and more.
But not just any machine will do! To work safely, agents 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.
Render Sandboxes give each user or task its own machine the moment it’s needed. Each sandbox runs in its own Firecracker microVM.
Speed: a sandbox is ready for its first command in under a second.
Scale: you can run thousands of sandboxes at once, reliably.
Security: you can set each sandbox to allow all outbound traffic, allow only the domains you list, or block outbound traffic entirely. Credential brokering (now in early access; let us know if you're interested) adds your API keys to outgoing requests, so the keys never sit inside the sandbox.
Pricing: you pay for the CPU a sandbox actually uses and the memory it allocates. A suspended sandbox stops both charges and billing, except for snapshot storage.
Long-running work: A sandbox can run with no time limit. When it goes idle, Render suspends it and wakes it on the next command with its files and memory intact.
One platform: your sandboxes live in the same workspace as your web services, background workers, and Render Postgres databases, with one API key, one SDK, and one bill.
Teams use Render Sandboxes to run an agent harness like Claude Code or Codex inside a sandbox, to start a full copy of an app so a coding agent can test its changes, and to run code and files they didn't write.
Render Sandboxes are in public beta - tell us if anything feels missing or doesn't work as expected. We'll be here throughout the day answering questions!
Keeping memory and files through a pause is useful for longer tasks. When debugging a retry, I'd also want to see clearly which work resumed and which work ran again.
Thanks @oleksii_sekundant!
Anything in particular you're looking to build?
If it helps, you can check a sandbox’s status (including from the CLI or SDK) to see whether it’s suspended or running. Command output also stream back to your client as well.
I've run a dozen or more coding agents at once on one 48GB Mac. In September that took the whole machine down from memory exhaustion and every session died together, so the isolation is the part I care about here. What happens when one sandbox hits its memory limit: does only that agent die while the others keep going? And how well does suspend and wake hold up with a big install? Our node_modules is 18GB.
@robksawyer exactly, that's where isolation is really useful! If you manage to OOM a single sandbox, the other agents (each in their own sandbox) should be able continue as normal.
Suspend performance scales with the size of the disk / memory. For a 20GB disk, I would expect it would take on the order of tens of second for a suspend, but there's a lot of factors that go into that (if it's a fresh install vs using a snapshot that you haven't modified). I'd recommend trying it out to see what kind of performance you get! We're also continuously making optimizations to improve that