Network rules

By default, a sandbox can reach any public IP on the internet. The platform always blocks egress to private, link-local, and loopback ranges regardless of your allow rules. Use network rules to narrow the allowlist further.

Rules control what a sandbox may reach. To see what it actually reached over HTTP and HTTPS to public addresses on ports 80 and 443 — every such connection, allowed or blocked — use the network log.

Allow specific destinations

allowOut / allow_out accepts a mix of CIDRs and domain patterns. Combine it with denyOut: ["0.0.0.0/0"] to build a strict allowlist - deny everything, then add exceptions. Do not rely on allowOut without denyOut to keep other egress open: it can also block destinations that are not on the list, so list every host the workload needs.

const sandbox = await Sandbox.create({
  name: "restricted",
  network: {
    allowOut: [
      "1.1.1.1/32", "8.8.8.8/32", // the sandbox's DNS resolvers
      "api.openai.com", "*.github.com", "140.82.112.0/20",
    ],
    denyOut: ["0.0.0.0/0"],
  },
})

from superserve import Sandbox, NetworkConfig

sandbox = Sandbox.create(
    name="restricted",
    network=NetworkConfig(
        allow_out=[
            "1.1.1.1/32", "8.8.8.8/32",  # the sandbox's DNS resolvers
            "api.openai.com", "*.github.com", "140.82.112.0/20",
        ],
        deny_out=["0.0.0.0/0"],
    ),
)

A deny-all rule also blocks DNS. Sandboxes resolve names through 1.1.1.1 and 8.8.8.8, so an allowlist that contains domain rules, or whose workload looks up hostnames, must let the sandbox reach at least one of them or nothing resolves - not even the domains you allowed. The examples allow both so a resolver outage doesn’t take DNS down with it. An allowlist made only of IPs and CIDRs has no such need and is tighter without them: DNS is an outbound channel like any other, and an allowed resolver can carry data in queries for a domain no rule permits. Domain rules are matched on the connection, not on the lookup, so allowing api.openai.com does not by itself let the sandbox look it up.

Rule format

Field	Accepts	Notes
`allowOut` / `allow_out`	IPs, CIDRs + domains	Domains support wildcards (`.example.com`). A wildcard matches subdomains at any depth but not the bare domain — `.example.com` does not match `example.com`; list both if you need the apex. A bare IP is stored and applied as a single-host prefix: `1.1.1.1` reads back as `1.1.1.1/32`.
`denyOut` / `deny_out`	IPs and CIDRs only	Use `0.0.0.0/0` to deny the entire internet and rely on `allowOut` for exceptions. Domains are not accepted here.

Allow rules take precedence over deny rules when they overlap.

Update rules on a running sandbox

Networking can be updated after creation - changes apply immediately to new connections. The sandbox must be active; updating network on a paused sandbox returns a ConflictError. Resume it first, or set the rules at creation so they follow the sandbox through every pause and resume.

await sandbox.update({
  network: {
    allowOut: ["1.1.1.1/32", "8.8.8.8/32", "api.anthropic.com", "api.openai.com"],
    denyOut: ["0.0.0.0/0"],
  },
})

sandbox.update(
    network=NetworkConfig(
        allow_out=["1.1.1.1/32", "8.8.8.8/32", "api.anthropic.com", "api.openai.com"],
        deny_out=["0.0.0.0/0"],
    ),
)

Rules only filter traffic the sandbox itself initiates. The SDK reaches the sandbox through the platform rather than through its network, so commands and file operations keep working under a deny-all policy.

Get Started

Sandbox

Secrets & env vars

Templates

Commands

Filesystem

Storage

Errors

Allow specific destinations

Rule format

Update rules on a running sandbox

​Allow specific destinations

​Rule format

​Update rules on a running sandbox

Allow specific destinations

Rule format

Update rules on a running sandbox