Egress IPs

Amp’s servers connect to some services that you run or control. If one of those services accepts connections only from known IP addresses, add Amp’s server IP addresses to its allowlist.

Server IP Addresses

Amp’s servers connect from these IPv4 addresses:

34.27.63.54
35.194.5.71
35.192.100.192
34.61.145.182
34.46.222.39
34.136.50.179
34.122.195.118
34.10.59.143
136.113.83.135
34.121.168.15
34.31.146.103
35.254.58.39
34.132.205.130
34.9.76.20
34.42.36.229
23.236.56.82

The same list is at https://ampcode.com/docs/egress-ips/server.txt, with one address per line, so a script can fetch it.

When You Need Them

Allow these addresses on a service that restricts access by IP address when Amp’s servers connect to it:

  • Model routing. Amp runs inference on its own servers, so requests through your model routing connections come from these addresses. This includes Amazon Bedrock, Google Cloud Agent Platform, Microsoft Foundry, and Custom URL connections, e.g., an AWS IAM policy with an aws:SourceIp condition. Check Access also connects from these addresses.
  • Private or internal remote MCP servers. Amp’s servers connect to the remote MCP definitions saved on ampcode.com.
  • GitLab self-managed instances. Amp’s servers call your instance’s API to check it, connect accounts, refresh OAuth tokens, install Push Updates webhooks, and follow subscriptions. See GitLab network requirements.

When You Don’t Need Them

These connections do not come from the server IP addresses:

  • Orbs. Commands in an Amp-hosted orb, e.g., git clone, connect from the orb host’s addresses, which change. To let an orb reach a service that allows only known addresses, connect the orb to your network with Tailscale.
  • Self-hosted orbs and runners. They connect out to Amp, and Amp never connects into your network. See What Leaves Your Network for the hostnames they need to reach.