Egress
Every create compiles a network policy from three layers, strictest first:- 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 address169.254.169.254, multicast and reserved ranges, and their IPv6 equivalents), names such aslocalhost,*.localand*.internal, and the mail and DNS-over-TLS ports 25, 465, 587, 2525 and 853. - Your plan’s limits. Paid plans allow the public internet by default; the free plan allows no public egress.
- The sandbox’s own policy: the E2B fields below on create, else your team’s egress settings (see Which policy applies).
- 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_outneed public egress off (deny_out: ["0.0.0.0/0"]orallow_internet_access=false), as on E2B. Wildcard names and names that do not resolve are refused for now. deny_outtakes IPv4 addresses and CIDRs only.- Unknown keys inside
networkare 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:- The
networkandallow_internet_accessfields of its create request. - Its template’s policy (built-in templates have none).
- Your organization’s team egress settings: set them on the dashboard’s Network page (owners and admins), or with
PUT /v1/network. - Your plan’s default.
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.
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 afterBearerorBasic. 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.
Ingress
All traffic to a sandbox goes through the Anona gateway’s sandbox edge athttps://<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.