Restoring a Render sandbox snapshot allows unrestricted outbound traffic by default

A restricted Render sandbox can be restored from a snapshot with unrestricted outbound networking unless its restrictions are supplied again. Superpower Daily’s review of four documentation snapshots finds this default applies to both runtime and filesystem restores. Even when a restore preserves running processes, it does not inherit the source sandbox’s network policy or timeout configuration.

The distinction comes from what restoration creates: a new sandbox, not a continuation of the original sandbox’s entire configuration. Render’s Managing Sandbox Snapshots documentation separates saved state from settings taken from the new creation request or their defaults. For anyone reusing a prepared environment for an agent, recovering its files or processes is therefore a separate task from restoring its intended operating restrictions.

Our question was narrow: across idle resumption and the two snapshot-restoration paths, which network restrictions, environment variables, processes and timeouts are documented to persist? We classified four supplied Render documentation snapshots retrieved on November 5, 2026, at 16:32:10.314 UTC, cross-checked against their readable live pages. The sample covered snapshot management, sandbox configuration, the TypeScript SDK and sandbox limits. We separated explicit preservation, required reapplication, documented resets and unresolved guarantees rather than assigning a single preservation score. No code was executed or network enforcement tested. All four pages describe a public beta whose APIs, defaults and limits may change.

The restore request supplies the network boundary

Neither snapshot type carries over the source network policy. Without a replacement policy, the restored sandbox uses allow-all, meaning it can send outbound traffic to any destination using any protocol. The relevant choice happens when creating the restored sandbox, even if the source environment had already been restricted.

The replacement can block all outbound traffic or allow only specified HTTPS destinations. Creating and Configuring Sandboxes explains that an allowlist blocks both unlisted destinations and protocols other than HTTPS. Its hostname rules also matter: an exact hostname does not include its subdomains. Reapplying a policy therefore means supplying the intended rules, not merely choosing a broadly restrictive label.

Timeouts follow the same new-configuration boundary. A snapshot restore defaults to a 24-hour continuous runtime limit and suspension after 15 idle minutes. A source sandbox’s shorter, longer or disabled timeouts do not carry over. Developers must supply custom settings again; uninterrupted indefinite operation requires disabling both timeouts. These settings control different outcomes: the runtime limit terminates the sandbox, while the idle limit suspends it.

A resumed process keeps its own environment

Environment variables—the named values supplied to configure commands—do not fit a simple preserved-or-reset verdict. Render says new commands use newly provided variables, while processes resumed from a runtime snapshot retain their captured environment. A single restored sandbox can therefore contain resumed work using its earlier environment and newly launched commands using the environment supplied for the restore. Supplying new variables should not be treated as replacing the values already held by resumed processes.

That creation-time injection is distinct from environment files or shell startup scripts retained on disk. A filesystem snapshot preserves files, but not the running processes that used them. Its recovery path therefore starts commands afresh rather than continuing a captured process with its existing environment.

The Sandboxes SDK for TypeScript exposes environment, network policy, runtime timeout and idle timeout as separate creation inputs. It also says environment-variable values are not returned in sandbox details. A successful details request is consequently not a way to inspect the injected values used to configure new commands.

Idle resumption is not another snapshot restore

Idle resumption operates on the existing sandbox. Commands and file transfers automatically resume it, and Render explicitly says the filesystem is preserved during suspension. The snapshot restore table’s resets should not be applied to this different recovery path.

What the idle-resumption documentation establishes

• The runtime countdown resets after suspension and resumption. This does not establish a reset of the configured duration to the 24-hour default.
• Commands and file transfers reset idle timing; status checks do not.
• Preservation of network restrictions, creation-time variables, running processes and custom timeout durations is not explicitly guaranteed in the sample. That absence does not prove they are lost.

Background work introduces a separate operational limit. Once the command that launched a background process finishes, that process does not keep the sandbox active. Render advises disabling idle suspension when background processes need to continue without interruption. This concerns whether work is interrupted at all, not whether captured process state can later be recovered.

Recovery still needs capacity—and clearer guarantees

Limits for Render Sandboxes documents a 30-day resumability period for suspended sandboxes and requires available capacity in their sandbox group. At the group’s concurrency limit, resume requests fail with HTTP 429. Snapshot restores must stay in the source snapshot’s group. These are availability constraints, separate from which state or settings survive: a documented recovery path still depends on meeting its prerequisites.

Snapshots have their own recovery window. They expire by default 30 days after capture, and restoring one does not restart that clock. Developers can set an expiration time when capturing a snapshot with either SDK. An expired snapshot cannot be restored, although sandboxes already created from it remain unaffected. This is distinct from the 30-day period for resuming an idle sandbox: one deadline governs reuse of a saved snapshot, while the other governs resumption of the existing environment.