• Docs
  • Changelog
Sign in
Get started
    • Home
    • Your first deploy
    • Free instances
    • Platform features by plan
    • Use with coding agents
    • FAQ
    • Templates
      • Migrate from…
        • Heroku
        • Railway
    • Compute plans
    • SandboxesBeta
      • Service types
        • Which to use?
        • Static sites
        • Web services
        • Private services
        • Background workers
        • Cron jobs
        • Workflows
        • Multi-service architectures
      • Data storage
        • Render Postgres
        • Render Key Value (Redis®-compatible)
        • Persistent disks
    • How deploys work
    • Supported languages
    • Git providers (GitHub, etc.)
    • Build pipeline
    • Deploy hooks
    • Monorepo support
    • Troubleshooting deploys
      • Previewing changes
        • Single-service previews
        • Preview environments (multi-service)
      • Docker deploys
        • Overview
        • Deploy a registered image
        • Using secrets
      • Runtime
        • Native runtimes
        • Environment variables & secrets
        • Default environment variables
    • Intro to sandboxes
    • Limits
      • How to…
        • Create & configure sandboxes
        • Execute commands
        • Manage files
        • Manage snapshots
      • Use with…
        • Claude Managed Agents
        • Cursor Cloud Agents
        • OpenAI Agents API
      • SDK/CLI reference
        • TypeScript SDK
        • Python SDK
        • CLI commands
    • Intro to workflows
    • Tutorial
    • Limits & pricing
      • How to…
        • Define tasks
        • Define flowsNew
        • Trigger runs
        • Develop locally
      • SDK reference
        • TypeScript SDK
        • Python SDK
      • Example workflows
        • TypeScript examples
        • Python examples
    • Overview
    • Create & connect
    • Database credentials
    • Extensions
    • Version upgrades
    • Logical replication
    • Legacy instance types
      • Database recovery
        • Recovery & backups
        • High availability
      • Database performance
        • Read replicas
        • Connection pooling
        • Admin apps
        • Repacking tables
        • Troubleshooting performance
    • Regions
    • Inbound IP rules
    • Edge caching
    • WebSockets
    • TLS certificates
      • Custom domains
        • Overview
        • Cloudflare
        • Namecheap
        • Other DNS providers
      • Internal traffic
        • Private network
        • Private links
      • Outbound traffic
        • Default IP ranges
        • Dedicated IP addresses
        • Outbound bandwidth
        • Handling network changes
      • Static site config
        • Custom response headers
        • Redirects & rewrites
    • The Render Dashboard
    • SSH / Shell access
    • Projects & environments
      • Service actions
        • Scaling
        • Rollbacks
        • Maintenance mode
        • One-off jobs
      • Infrastructure as code
        • Blueprints overview
        • render.yaml reference
        • Terraform provider
    • In-dashboard metrics
    • Health checks
    • Uptime best practices
      • Logging
        • In-dashboard logs
        • Log streams (syslog/HTTPS)
      • OpenTelemetry (OTel) metrics
        • Provider setup
        • Metrics reference
      • Notifications
        • Webhooks
        • Email / Slack
    • MCP Server
      • Render CLI
        • Overview
        • Command reference
      • REST API
        • Overview
        • API reference
      • Third-party connections
        • OIDC support
        • Datadog
    • Workspaces, members, & roles
    • Login settings
    • Audit logs
      • Organizations
        • Overview
        • SAML SSO
    • DDoS protection
    • Platform maintenance
      • Compliance
        • Overview
        • HIPAA (US health data)
        • HIPAA best practices
        • Shared responsibility model
        • Pentest policy
    • Heroku vs Render
    • Vercel vs Render

Managing Sandbox Snapshots

Capture a sandbox's state and restore it into other sandboxes.

Render Sandboxes is in public beta.

APIs, defaults, and limits might change during the beta period.

After you create a sandbox, you can capture its state in a snapshot. You can restore from a snapshot to create new sandboxes with the same prepared filesystem or resume a process from a saved state.

Snapshots are useful for reusing installed packages, preparing environments for agents, and saving progress before a sandbox terminates.

A sandbox must be actively running to capture a snapshot. Creating a snapshot does not terminate the sandbox.

Kinds of snapshots

Render supports two kinds of sandbox snapshots:

KindDescription

Runtime snapshot

Captures the writable filesystem, along with memory and CPU state.

Use this to resume running processes from their captured state in a new sandbox.

Restoring from a runtime snapshot requires the exact same compute plan as the source sandbox.

Filesystem snapshot

Captures the writable filesystem only.

Use this to reuse files and installed packages in a new sandbox, without preserving running processes.

Restoring from a filesystem snapshot supports any compute plan.

Capturing a snapshot

The following example captures a filesystem snapshot and waits until it's available. Replace sbx-abc123 with your sandbox's ID:

The command prints the snapshot's ID and details after capture completes.

Call snapshots.create with the source sandbox's ID and the snapshot options.

Call snapshots.create with the source sandbox's ID and the snapshot options as keyword parameters.

Call snapshots.create with the source sandbox's ID and the snapshot options as keyword parameters.

To capture a runtime snapshot instead, set the kind to runtime or omit the kind option.

The wait option waits up to five minutes for capture to complete. If you omit it, creation returns before the snapshot is available. If the wait times out, capture continues. Check the snapshot's current status before starting another capture.

Restoring from a snapshot

Restore from a snapshot by providing its ID when you create a sandbox. Each restore creates a new sandbox, preserving the snapshot for reuse.

Snapshots always belong to the same sandbox group as their source sandbox. Provide that group's ID when restoring. You can restore from a snapshot only into another sandbox in the same group.

Replace snp-abc123 with the ID returned by snapshot creation and sbg-abc123 with its sandbox group ID. You can find group IDs with render sandbox-groups list:

These examples wait until the restored sandbox is running and set a five-minute runtime timeout. You can then execute commands or manage files inside it.

Restored state and configuration

Restoring from a snapshot preserves some aspects of the source sandbox, while other settings come from the new create request or their defaults. See Configuring sandbox behavior for how to provide these settings with the CLI or SDKs.

PropertyPreserved?Notes

Filesystem

☑️

Running processes

☑️

Runtime snapshots only.

Compute plan

☑️

Preserved by default. Filesystem snapshots support choosing a different plan.

Network policy

☑️

Inherits the source sandbox's network policy, including allowlist rules. Provide a network policy when creating the restored sandbox to override it.

Environment variables

➖

New commands use newly provided variables. Resumed processes retain their environment.

Runtime timeout

☑️

Inherits the source sandbox's runtime timeout, including if disabled. The runtime timeout restarts when the sandbox is restored. Provide a runtime timeout when creating the restored sandbox to override it.

Idle timeout

☑️

Inherits the source sandbox's idle timeout, including if disabled. Provide an idle timeout when creating the restored sandbox to override it.

Restoring by name

You can name a snapshot when you capture it, then restore from it by name instead of ID:

Replace sbg-abc123 with the group ID of the source sandbox (sbx-abc123):

The --from flag accepts either a snapshot name or ID. Do not combine it with --snapshot-id.

Names are case-sensitive and scoped to a sandbox group. If you reuse a name, restoring by that name uses the most recently available snapshot with that name in the selected sandbox group.

A snapshot's name must be between 1 and 64 characters and cannot begin with snp-.

Retrieving snapshot details

You can retrieve a snapshot to check its status, capture error, expiration time, and other details:

Lookup, listing, and deletion methods all require the snapshot's sandbox group ID.

Snapshot status

A snapshot has one of the following statuses:

StatusMeaning

creating

Capture is in progress. New sandboxes cannot yet be restored from the snapshot.

available

Capture succeeded. New sandboxes can now be restored from the snapshot.

failed

Capture failed. Check the snapshot's error field for details.

Waiting for an existing snapshot

If you captured a snapshot without waiting, you can wait for it to become available with the following approaches:

Use render sandboxes snapshots get to check the snapshot's status:

To wait in a script, call this command in a polling loop while the status is creating, pausing between checks. Stop when the status is available or failed. Add --output json to read the status programmatically.

The SDK methods wait up to five minutes by default and raise an error if capture fails or the wait times out.

Snapshot expiration

By default, snapshots expire 30 days after capture. This expiration time does not change if you use the snapshot to restore a sandbox.

Check expiresAt (TypeScript) or expires_at (Python) for an individual snapshot's expiration time. The CLI displays this value in snapshot details.

You can set an expiration time when capturing a snapshot with either SDK. The following example sets it to 24 hours from now:

The expiration time must be in the future. After a snapshot expires, you can no longer retrieve it or restore from it. Sandboxes already restored from an expired snapshot are unaffected.

Listing snapshots

List snapshots in a sandbox group to find their IDs and statuses. The following example lists snapshots that are available to restore from:

Results are ordered newest first. Omit the status filter to include snapshots with any status. Deleted and expired snapshots are excluded.

The SDKs return one page at a time. Use the cursor from the last entry (TypeScript) or next_cursor (Python) to retrieve additional pages. For pagination options, see the TypeScript and Python references.

Deleting a snapshot

Delete a snapshot when you no longer need to restore from it:

Without --confirm, the command previews the deletion and makes no changes.

You cannot delete a snapshot while its status is creating. Deletion prevents future restores and does not affect sandboxes already restored from the snapshot.

Managing Sandbox Snapshots
  • Kinds of snapshots
  • Capturing a snapshot
  • Restoring from a snapshot
    • Restored state and configuration
    • Restoring by name
  • Retrieving snapshot details
    • Snapshot status
    • Waiting for an existing snapshot
  • Snapshot expiration
  • Listing snapshots
  • Deleting a snapshot
All Systems Operational
© Render Inc. All rights reserved.