How to give sandboxes a static outbound IP address
Run runtime address reserve; from then on every sandbox of your account sends from that one IPv4 address, for $5 per 30-day month.
On Runtime one reservation covers every sandbox of the account, on every port, for $5 per 30-day month, prorated to funded time; a dedicated IPv6 address is included (pricing checked 25 September 2026, network products). No NAT gateway to build and no proxy to run: a database, an API provider or a firewall can admit exactly you, and no other account sends from the address while you hold it.
Reserve it
Terminalruntime address reserve# 203.0.113.50runtime address reserve --ipv6TypeScriptimport { Runtime } from "withruntime";const runtime = new Runtime();const ip = await runtime.addresses.reserve();console.log(ip.address, ip.funded, ip.fundedUntil);Pythonfrom withruntime import Runtimeruntime = Runtime()ip = runtime.addresses.reserve()print(ip["address"], ip["funded"], ip["fundedUntil"])An MCP agent uses runtime_address_reserve, runtime_address_list and
runtime_address_release. Add the address to your provider's allow-list, and
check it from a sandbox:
Terminalruntime sandbox run -- curl -sS https://api.ipify.orgWhat it costs and what you get
| Item | Detail |
|---|---|
| Dedicated IPv4 | $5 per 30-day month, prorated to funded time |
| Dedicated IPv6 | Included, with --ipv6 |
| How many | One IPv4 and one IPv6 per account |
| Which sandboxes use it | Every sandbox of the account, on every port |
| Rate | Fixed in the reservation's quote; rateMicros and rateUnit show it |
| Who else sends from it | Nobody, while you hold it |
| After release | It rests 30 days before any other account can have it |
Funding, and what happens when it lapses
funded says whether traffic is paid for now. fundedUntil is the last
funded-through time; it may be in the past, and it is null when no meter exists.
If funding expires, because the balance ran out or a key's daily limit blocks the renewal, traffic from your sandboxes stops while the reservation remains yours. Runtime never falls back to a shared address, so a partner's firewall never sees you from an address it did not approve. The unpaid interval is never charged. When renewal is blocked, check the balance, spending limits and the key's permissions.
Mistakes and how Runtime handles them
- Releasing before updating allow-lists.
runtime address release <addressId>sends your sandboxes back to the shared addresses at once. Remove the address from partners' allow-lists first; it then rests 30 days before another account can be given it. - Expecting one address per sandbox. The address belongs to the account, so every sandbox shares it, whichever key or agent created the sandbox.
- A trial account. The answer is
payment_required(402) until the account adds credit. - None free. Addresses are added as accounts need them. If none is free, the
answer is
no_capacity(503): write to support (errors). - Treating the address as a secret. An allow-list narrows who can connect; the service still needs its own password or key. Store that key as a secret the sandbox never sees.
Allow-lists in both directions
A dedicated address controls how the outside world sees your sandboxes. The sandbox's own network rules control where they may go. Used together, a sandbox can reach only your partner's API, and the partner accepts only your address.
For traffic that must not cross the internet at all, a WireGuard tunnel joins your own network to your sandboxes instead, at the same $5 per 30-day month.
Related
- Dedicated outbound addresses in the networking guide.
- Pricing: what a sandbox costs to run.
- Egress control.
Facts on this page were checked on 25 September 2026.