Render Sandboxes Are in Public Beta. Where Should Your Real Backend and Database Run Now?

Key points:

• Render Sandboxes entered public beta in early November 2026. Each sandbox is a Firecracker microVM with sub-second starts, automatic suspend when idle, up to 8 CPU and 16 GB of RAM, a 40 GB disk, and outbound traffic you can allowlist or block. During the beta it runs in one region, Oregon (Render blog, Render docs: limits).
• A sandbox and a backend are two different jobs. A sandbox is a disposable computer where an agent runs code nobody reviewed. A backend is the long-lived API, workers and database your customers depend on. Most teams need both, and they do not have to come from the same vendor.
• Render is the better fit when you already run on Render, nobody requires the stack to live in your own cloud account, and you want agent sandboxes, web services and Postgres from one vendor and one bill.
• A backend in your own cloud account is the better fit when contracts, data residency, committed cloud spend or audit evidence say the database must sit in your AWS, GCP, Azure or Scaleway account. Render's docs describe outbound AWS PrivateLink from Render to your VPC, not running services inside your account (Render docs: PrivateLink).
• Qovery is not a sandbox. It deploys and governs the backend on Kubernetes in your own account. Pair it with the sandbox that fits: Render, E2B or Daytona as hosted services, or AWS Nitro Sandboxes on an EKS cluster you run, launched on 9 November 2026 at no additional charge (AWS).

Render shipped Sandboxes in public beta this month, and it is a good launch. Every agent gets its own isolated Linux machine, it suspends when idle, wakes with its files intact, and sits in the same workspace as your Render web services and Postgres. Congratulations to the Render team.

The launch also triggered a question I now get on almost every product call: "If Render runs our agents' sandboxes, should our backend move to Render too? Or the other way round?" I lead product at Qovery, and I think the question mixes two workloads that have very different requirements. This guide pulls them apart, compares the options fairly, and tells you which one fits when. All facts were checked against vendor pricing pages and docs on 14 November 2026.

What did Render launch with Sandboxes?

Render Sandboxes are isolated Firecracker microVMs, one per agent, user or task, that start in under a second, suspend automatically when idle and wake with their filesystem intact. They launched in public beta in early November 2026 with four compute sizes up to 8 CPU and 16 GB of RAM, available on every Render workspace plan (Render blog, Render changelog).

The facts that matter for an architecture decision, from Render's own docs:

• Isolation: each sandbox runs in its own Firecracker microVM (Render blog).
• Sizes: 1c-2g (default), 2c-4g, 4c-8g and 8c-16g, with a 40 GB writable filesystem per sandbox (Render docs: limits).
• Lifetime: a runtime timeout that defaults to 24 hours and ranges from 60 seconds to 30 days, or disabled; an idle timeout that defaults to 15 minutes. Suspended sandboxes keep their filesystem for 30 days (Render docs: creating sandboxes).
• Network: all outbound traffic allowed by default, or an allowlist of up to 100 HTTPS destinations, or deny-all (Render docs).
• Scale: up to 1,000 concurrent sandboxes per sandbox group and 10 groups per workspace; suspended sandboxes do not count (Render docs: limits).
• Region: Oregon only during the beta (Render docs: limits).
• Price: $0.12 per active CPU hour, plus $0.038 per hour of provisioned memory on the 2 GB size, and $0.08 per GB-month of snapshot storage (Render pricing).
• Integrations: TypeScript and Python SDKs, the Render CLI, and documented pairings with the OpenAI Agents API, Claude Managed Agents and Cursor Cloud Agents (Render docs: OpenAI Agents API, Render blog).

Render also lists what is coming: private networking to other Render services, more regions, SSH access and public URLs (Render blog). Treat those as roadmap while you plan. "APIs, defaults, and limits might change during the beta period," as the docs say.

Render bills active CPU rather than provisioned CPU, which suits agents. They spend most of their wall-clock time waiting for a model to answer, so a sandbox that idles between tool calls costs memory, not CPU.

Is an agent sandbox the same thing as a backend?

No. An agent sandbox runs untrusted, short-lived, generated code and gets thrown away. A backend runs reviewed code for months, holds your customers' data and must be reachable, observable and auditable. They need different isolation, different lifecycles and different controls, which is why the answer to "where should it run?" is often different for each.

The mistake I see most often is treating the sandbox as a place to run production. An agent builds a working app inside a sandbox, someone exposes a port, and six weeks later that sandbox is a customer-facing service with no backups.

The opposite mistake also happens: giving an agent kubectl on the production cluster because "it is just a quick script". OWASP lists both prompt injection and excessive agency among the top risks for LLM applications (OWASP LLM01, OWASP LLM06). The sandbox exists so generated code never touches the backend directly.

Where do Render's backend services and Postgres actually run?

Render services and Render Postgres run on Render's infrastructure, in one of five regions: Oregon, Ohio, Virginia, Frankfurt or Singapore (Render docs: regions). Render connects out to resources in your AWS VPC through PrivateLink, but its docs describe connections "initiated from your Render infrastructure to an external provider, but not the reverse" (Render docs: PrivateLink).

For many teams this is exactly what they want: no cloud account to manage, managed Postgres that scales up to 128 CPU and 1,024 GB of RAM, full-stack preview environments on Pro and above, and HIPAA-compliant workspaces on the Scale plan at $499 a month plus compute (Render pricing).

It stops fitting when the requirement is "in our account". The usual sources:

• Enterprise contracts that name the cloud account, region and VPC where customer data must live.
• Committed cloud spend (AWS Enterprise Discount Program, Google committed use, Azure MACC) or startup credits that only count when workloads run in your own account.
• Data gravity: the warehouse, the ML features or the document store already live in your AWS, GCP or Azure account, and egress through a link costs money and latency. Render charges $0.03 per GB of outbound bandwidth over a private link (Render pricing).
• Audit evidence that must come from your own cloud logs, IAM and cluster audit trail.

If none of these apply to you, Render is a strong choice and you can stop reading here.

How do Render, E2B, Daytona, AWS Nitro Sandboxes and Qovery compare?

Render, E2B, Daytona and AWS Nitro Sandboxes are execution sandboxes: places where agent-generated code runs isolated. Qovery is not a sandbox; it deploys and governs the backend and database in your own cloud account. Pick one tool from the first group for the agent's code and decide separately where the backend runs.

Sources: Render pricing, E2B pricing, E2B open source, Daytona pricing, AWS What's New, EKS User Guide.

A few notes the table cannot hold:

• E2B is the open-source option. Its core stack is Apache-2.0. "E2B Embed" puts the whole stack on one machine you operate; BYOC in your AWS, GCP or Azure account runs the same API (E2B). Hobby sessions last up to 1 hour, Pro sessions up to 24 hours (E2B pricing).
• Daytona is no longer open source. Its GitHub repository is now archived, so self-hosting means BYOC under Daytona's control plane (GitHub). It does sell GPU sandboxes, from $0.57 per hour for an RTX 4090 to $4.08 for a B300, preemptible (Daytona pricing).
• Nitro Sandboxes are a building block. You opt a pod in with runtimeClassName: isolated-sandbox, and AWS enforces the boundary with the Nitro hypervisor. It requires Kubernetes 1.36 or later (EKS User Guide). You still build the API your agents call, warm pools and cleanup. My colleague Romaric wrote the deep dive on Nitro Sandboxes vs Daytona and E2B.
• Render's advantage is proximity. A Render sandbox and a Render web service share a workspace and a bill. Once private networking ships, a sandbox will reach your Render Postgres without a public hop. No other hosted sandbox can offer that for a Render backend.

For a wider list, including Modal, Vercel Sandbox, Cloudflare and Northflank, see our comparison of the best ephemeral code execution environments for AI agents.

When is Render the better fit for agents plus a backend?

Render is the better fit when you already run your web services and Postgres on Render, no customer or regulator requires the stack in your own cloud account, Oregon is acceptable for sandboxes during the beta, and you value one vendor over control. In that situation, adding Render Sandboxes is the shortest path to giving agents a computer.

Concretely, pick Render when:

• Your team is small and has no one who wants to own a cloud account. Render's Pro plan is $25 a month plus compute (Render pricing), and you never see a VPC.
• Your agents mostly need scratch space, for example running tests on generated code, converting files or browsing, and do not need to sit next to private data.
• You want one place for logs and billing across sandboxes, Workflows, web services and Postgres.
• HIPAA on Render's Scale plan covers your compliance need, and your customers accept a vendor-hosted database.

I would not move an existing, healthy Render backend anywhere because agents arrived. If Render works for you today, Sandboxes make it work better.

When does a backend in your own cloud account fit better?

A backend in your own cloud account fits better when a contract, a regulator, a security review or your finance team says the data must live in an account you own, or when the systems your agents need to read already live there. In that case, keep the backend and database in your account and choose the sandbox separately.

The signals, in the order they usually show up:

1. A security questionnaire asks "which cloud account holds our data?" and the honest answer is "our vendor's".
2. Your largest customer wants a region Render does not offer, or wants the data in their own tenant.
3. You have credits or committed spend on AWS, GCP or Azure that only count in your own account.
4. Agents need governed access to production. That means a scoped token instead of kubectl, one that can deploy to staging, create a preview environment and read logs, with every action in an audit log.
5. The backend is growing into many services: APIs, workers, cron jobs, queues, a vector database, an internal admin. You want one environment model across all of them, cloned per pull request.

This is the job Qovery does. Qovery is an Agentic DevOps platform: the control plane is ours, and the data plane, meaning your cluster, services and databases, stays in your cloud account. Qovery never hosts your app. What you get:

• Kubernetes in your own AWS, GCP, Azure or Scaleway account, created and upgraded for you, or your existing EKS, GKE, AKS, Kapsule, k3s or on-premise cluster on Kubernetes 1.31 or later (Qovery docs: bring your own Kubernetes).
• Managed databases in your account, for example Amazon RDS through Blueprints, so the data never leaves it.
• A preview environment per pull request, a full clone of the stack, which is where agent-written changes should be tested before they merge.
• RBAC, audit logs and OPA-based policy tokens that limit what an agent can do, down to which environments and actions it can touch (Qovery blog: OPA policy tokens).
• Git-push deployments, Helm and Terraform or OpenTofu services, secrets manager integrations, cost visibility and Qovery Observe.

Qovery does not replace a sandbox. It does not give each agent session a disposable microVM. When your agents need one, use Render, E2B or Daytona as a hosted service, or Nitro Sandboxes on an EKS cluster you run. If you need the agent harness itself (not the untrusted code) to run inside your perimeter on a schedule or a trigger, Qovery Agent Tasks do that. They are not a per-session microVM for untrusted code.

One caveat on Nitro: Qovery-managed EKS clusters currently run Kubernetes up to 1.35, and Nitro Sandboxes need 1.36 or later. Today, that means running Nitro sandboxes on a separate EKS cluster you operate until managed clusters reach 1.36.

What does a sound architecture look like with both?

The pattern that works keeps three layers apart: the agent harness, the sandbox where generated code runs, and the backend that holds data. The sandbox never gets production credentials. The agent changes the backend only through Git and a deployment platform with scoped tokens, preview environments and an audit log.

In practice:

1. The agent harness (Claude Code, Cursor, Codex, the OpenAI Agents API or your own) plans the work.
2. The sandbox (Render, E2B, Daytona or Nitro) runs the generated code, the tests and the scratch work. Egress is restricted to the package registry, the model API and your staging API. Render's allowlist of HTTPS destinations does exactly this (Render docs).
3. The backend lives in your cloud account. The agent opens a pull request; the platform creates a preview environment with its own database; a human or a policy approves; the merge deploys.

How should you decide in five questions?

Answer five questions in order: does data have to live in your account, where does the backend run today, how sensitive is what the agent touches, who will operate infrastructure, and do you need GPUs in the sandbox.

1. Must the backend and database live in a cloud account you own? If yes, run them in your account (Qovery or DIY) and pick the sandbox separately. If no, go to 2.
2. Is the backend already on Render and healthy? If yes, add Render Sandboxes and keep everything in one place. If it is somewhere else, do not move the backend to get a sandbox.
3. Will generated code touch private data? If yes, prefer a sandbox in your own account (Nitro on EKS, or E2B or Daytona BYOC) with egress locked down. If not, any hosted sandbox works.
4. Who operates infrastructure? No platform engineer means hosted sandboxes plus a managed platform for the backend. A team that already runs EKS can take on Nitro.
5. Do agents need GPUs? Pick a sandbox vendor that sells them, like Daytona, because Nitro Sandboxes do not support GPU passthrough at launch.

For a broader view of when teams leave Render for their own cloud, see Leaving Render for your own AWS account and Railway vs Render vs your own cloud account.

How do I set up the backend side with Qovery from Claude Code or Cursor?

Install the Qovery Agent Skills once, and your coding agent can deploy the backend and a managed database into your own cloud account and create preview environments while you approve each step. The Qovery MCP Server operates what already exists and is read-only by default. Your sandbox provider stays whatever you picked above.

1. Install the skills for Claude Code, Cursor, Codex, OpenCode and Gemini CLI:

curl -fsSL https://skill.qovery.com/install.sh | bash

1. Or scope them to one repository:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

1. Add the Qovery MCP Server to Claude Code. It signs you in with OAuth and is read-only by default:

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

1. Only if you want the agent to make changes through MCP, add the write-enabled server. This also requires write access enabled in the Qovery Console:

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills include qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview and qovery-terraform. Then ask: "Deploy this API with a managed PostgreSQL to my GCP account with Qovery, and create a preview environment for every pull request." The agent asks you to approve each action. Swap GCP for AWS, Azure, Scaleway or your existing cluster.

Start with the AI agent quickstart or the Claude Code integration.