Render Sandboxes

Render Sandboxes is in beta. Each sandbox is a disposable Linux microVM: create it, run code, retrieve results, and terminate it. Code inside can use any language. Use render-workflows to orchestrate long-running jobs and render-deploy to host an app.

Sandboxes automatically suspend after 15 minutes of inactivity by default. A command or file transfer wakes a sandbox suspended within the last 30 days; status polling alone does not. Its continuous runtime limit resets after suspension/resume. See lifecycle and recovery for bounds and failure handling.

A workspace can have multiple sandbox groups; the first sandbox automatically creates a default group if needed. Snapshots restore only within their group. Runtime snapshots are the default and recommended for faster restores; use filesystem snapshots when you specifically need files only or a different compute plan. See snapshots.

Choose the client and workspace

Use SDK 1.5.0 (Python or TypeScript) or CLI 2.32.0, matching the project's installed version. The SDK caller needs RENDER_API_KEY and RENDER_WORKSPACE_ID; never put the Render API key inside the sandbox. Confirm the intended workspace and group before creating resources. An empty group list is valid on first use.

• SDK patterns: complete Python/TypeScript examples, file transfer, and cleanup.
• Create options: retrieve current SDK parameters/CLI flags and choose the settings the task needs.
• CLI operations: read before suggesting shell commands; check installed --help when versions differ. Quote host-shell variables. Snapshot capture is asynchronous: use --wait for availability before restoring.
• Environment and access: egress, secrets, custom images, plans, limits, and pricing.

Minimal SDK example