Egress

Every create compiles a network policy from three layers, strictest first:
  1. The platform floor, which no setting can open: private and internal ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 100.64.0.0/10, loopback, link-local including the cloud metadata address 169.254.169.254, multicast and reserved ranges, and their IPv6 equivalents), names such as localhost, *.local and *.internal, and the mail and DNS-over-TLS ports 25, 465, 587, 2525 and 853.
  2. Your plan’s limits. Paid plans allow the public internet by default; the free plan allows no public egress.
  3. The sandbox’s own policy: the E2B fields below on create, else your team’s egress settings (see Which policy applies).
Rules the gateway enforces when it compiles your policy:
  • A destination inside the platform floor is refused with 400, and so is a host name that resolves into it (this blocks DNS-rebinding tricks).
  • Host names in allow_out need public egress off (deny_out: ["0.0.0.0/0"] or allow_internet_access=false), as on E2B. Wildcard names and names that do not resolve are refused for now.
  • deny_out takes IPv4 addresses and CIDRs only.
  • Unknown keys inside network are refused, so a typo cannot silently drop part of a policy.
  • Per plan: up to 512 allow entries and 1,024 deny entries on paid plans (64 and 256 on the free plan), and at most 10 DNS servers.

Which policy applies

A new sandbox gets the first of these that exists, then the platform floor and your plan’s limits on top:
  1. The network and allow_internet_access fields of its create request.
  2. Its template’s policy (built-in templates have none).
  3. Your organization’s team egress settings: set them on the dashboard’s Network page (owners and admins), or with PUT /v1/network.
  4. Your plan’s default.
Ask the API which policy a sandbox runs with, and where it came from:
effective_policy.sh

Change a running sandbox

update_network replaces a running sandbox’s policy. It goes through the same floor and limits as a create. An update that does not mention allow_internet_access keeps the sandbox’s current setting.
The caller needs to be able to control the sandbox: an API key with sandboxes:use (and the sandbox on its list, if it has one), or a dashboard member or above.

Credentials without exposing them

The credential vault keeps API tokens out of sandboxes. Store a secret on the dashboard’s Credential vault page (owners and admins), then name it in a header rule for one host. The egress proxy adds the header to the sandbox’s HTTPS requests to that host; the sandbox, its environment and its disk never contain the value.
  • A header value must be exactly ${vault.<name>}, optionally after Bearer or Basic . Literal values are refused, so no credential ends up in a policy.
  • The first use binds the secret to that host and header. The vault page lists every binding and revokes one. Proxies cache a value for up to 60 seconds, so a rotation or revocation reaches running sandboxes within a minute.
  • The same rules work in the team egress settings, so every new sandbox gets them.
  • Secret names are lowercase letters, digits and _, up to 63 characters; values up to 8 KiB.
The vault is included in every plan at no charge.

Ingress

All traffic to a sandbox goes through the Anona gateway’s sandbox edge at https://<port>-<sandbox id>.sbx.compute.anonalabs.com: Single ports can also be made public, or shared with signed, expiring links; see Preview links. Sandbox URLs live on their own domain, so content served from a sandbox never shares cookies with the API or the dashboard.

DNS

Sandboxes resolve names through public resolvers (1.1.1.1 and 1.0.0.1), so they cannot resolve names inside Anona’s network.