How to let a cloud coding agent through your IP allowlist

Many databases and internal APIs only accept connections from IP addresses on an allowlist. A cloud coding agent runs in a sandbox whose address you don't control, so when it tries to run a migration or call your staging API, the connection is refused. To let it in, the agent's traffic has to come from a fixed address that you can put on the list.

This guide shows what a cloud agent's traffic looks like from the outside, which agents publish fixed egress IPs, how to set one up in Replicas, and when a VPN, bastion host, or private network is the better fit. Every claim about another vendor links to that vendor's own page. We checked them on November 7, 2026.

How we tested

An AI agent working in a Replicas workspace ran the tests and wrote this guide on November 7, 2026, and a person on our team reviewed it before it went live. The tests ran in four workspaces in our own organization. We already had a static egress IP turned on there, with one database host in its routed destinations, and we didn't change any organization settings for the tests. We also left our static IP address out of this page.

Why the agent's requests get refused

From three of the workspaces, we sent 54 requests to ipify, a service that replies with the address a request came from. They came from 8 different addresses, and the address often changed from one request to the next inside the same workspace. Seven of the eight showed up in more than one workspace, so the addresses belong to a pool that many sandboxes share. Adding them to your allowlist wouldn't work for long, and it would also let in traffic from sandboxes that aren't yours. GitHub gives the same advice for its hosted runners, and doesn't recommend allowlisting their IP ranges for internal resources.

Then we sent 65 requests through the workspaces' static egress tunnel. All 61 that got a response came from one address, the static IP in our organization's settings. Our routed destination is a database, not ipify, so we sent these requests out the tunnel's network interface directly. That's the same path the workspace gives a host in its routed destinations, as its routing table showed. Here is one run of the commands in our first workspace:

The first route is our database host, which is in Routed destinations, and the second is api.ipify.org, which isn't. We hid our static IP, the database host, and the last two parts of each sandbox address. The four requests that got no response were sent in one workspace's first 30 seconds. We couldn't make that happen again in 22 more requests to that workspace and a fourth one, but it's a good reason to let an agent retry its first connection.

Which cloud coding agents publish fixed egress IPs

"Shared" in this table means everyone who uses that vendor's cloud agents sends traffic from the same addresses, so an allowlist entry for them trusts all of those customers, not only you. In alphabetical order:

A shared list belongs to everyone on that vendor, so keep a password or token on anything you open to it. OpenAI's page says its list doesn't replace request authentication.

Set up a static IP in Replicas

Static egress is available on paid Team and Enterprise plans. An organization admin turns it on, and it then applies to every workspace in the organization.

1. Open Organization → Settings → Security and turn on Use a static IP. When provisioning finishes, the IP address shows in the same section.
2. Add that address to the allowlist on your database, API, or firewall.
3. Under Routed destinations, list the hosts that need the static IP, one per line. Each line can be an exact hostname, an IPv4 address, or an IPv4 CIDR range. Wildcards aren't supported, and a hostname needs an IPv4 address. If your database host is IPv6-only, list its IPv4 connection pooler instead.
4. Start a new workspace, or wake a sleeping one. Workspaces pick up the list when they're created or next wake.
5. Have the agent connect to the service. If it's refused, check that the host resolves to IPv4 with getent ahostsv4 <host>, and that the workspace started after you saved the list.

This screenshot comes from a test organization on our local development server, with an example address from the range reserved for documentation.

Hostnames are resolved inside the workspace and resolved again every minute, so a database whose address moves keeps working. Everything not on the list leaves directly, DNS included. If the tunnel stops, requests to listed hosts leave from a sandbox address, which your allowlist refuses. The static egress docs cover the rest.

Shared or dedicated IP

The main weakness of static egress in Replicas is that the IP is shared by default. Other Replicas organizations that turn on static egress leave from the same address. That keeps out the rest of the internet, but not other Replicas customers.

Turn on Route all traffic only when a vendor or firewall needs every request from your workspaces to come from one address, or when the hosts that need it are too many to list. It sends package installs and browser traffic through the exit too, so those gigabytes are billed and slower.

Speed is the other cost. Traffic to a routed host goes from the workspace to the exit in Oregon (us-west-2), then on to your service, so the extra time depends on how far your service is from Oregon. Our database is on the US east coast. These are the medians we measured:

For the database, we timed a TCP handshake to the host directly, and a select 1 on an open connection through the static IP.

An agent that runs one migration won't notice. An agent that runs thousands of queries one at a time will, so route only the hosts that need the IP, and keep connections open.

Other ways to reach a private service

An IP allowlist suits a managed database or a SaaS API that offers nothing else. When the service is inside your own network, one of these may fit better:

An allowlist only checks where traffic comes from, so also give the agent a database user or API token limited to what it needs. Then a mistake stays inside what that user can do. Our security page covers how Replicas isolates workspaces, and you can ask for a dedicated IP from the Enterprise page.