Use cases

The original case. A bank, a payment processor, a carrier or an enterprise customer says “send us the IP you will call from and we will open the firewall”. On AWS Fargate, Heroku, Render, Vercel, Railway or a Kubernetes cluster you do not have one — you have a pool that changes.

Lease an address, put it on every machine that makes the call, and give the partner one entry. Adding a worker later is your decision instead of a change request that takes weeks.

- requests.get("https://partner.example.com/api")
+ session.get("https://partner.example.com/api")   # bound to 194.0.108.64

Or nothing at all, if you use a full tunnel in a container. See Docker.

GitHub Actions and GitLab CI runners come from enormous shared ranges that no security team will allowlist. A deploy job that has to reach a production database, an internal registry or a partner sandbox is stuck.

- name: Bring up the tunnel
  run: |
    sudo apt-get install -y wireguard-tools
    echo "${{ secrets.AIP_CONF }}" | sudo tee /etc/wireguard/aip0.conf > /dev/null
    sudo chmod 600 /etc/wireguard/aip0.conf
    sudo wg-quick up aip0
    curl -s https://api.ipify.org   # should print your leased address

Lambda, Cloud Functions and Cloud Run egress from the provider's pool. The usual answer is a VPC plus a NAT gateway plus an Elastic IP, which is real money and real configuration, per region, forever.

The alternative here is to put one small always-on box — or one Kubernetes pod — behind the tunnel and route the calls that need the identity through it as a proxy. See the egress-proxy pattern.

Machines in Frankfurt, Singapore and your own rack can all hold the same lease. They egress as one address, so the far side sees one client no matter which region handled the job.

The cost is honest and worth stating: traffic goes to Karaganda and back, one way. For a few allowlisted API calls a minute that is invisible. For a chatty protocol between continents it is not — and source routing exists so only the traffic that needs the identity pays it.

One machine per lease can also receive on the public address: a webhook endpoint, an SFTP drop a partner pushes to, a game or mail server. That machine is the lease's designated inbound peer, and it is designated because WireGuard routes an address to exactly one peer — two peers claiming it means the last one silently wins and the others lose their traffic.

Everything else on the lease still egresses as the address. So the normal arrangement is one inbound machine and any number of outbound ones.

# the address is on the tunnel interface; bind to it directly
sudo ss -lntp | grep 194.0.108.64

Set a PTR record for your address from the dashboard, or over the API. It is live in about a second, because it is a row in our own nameserver rather than a ticket to an upstream. Many mail and finance systems check it, and a missing or generic PTR breaks more integrations than people expect.

Sending bulk email is not on by default: outbound TCP 25, 465 and 587 are blocked on every lease until you ask. One customer sending from a cold address damages the reputation of the whole block, and every other customer on it pays for that. Tell us what you are sending and we will open it, or tell you honestly that it is not a fit.

Scraping consumer platforms, evading bans, and anything the acceptable use policy lists will get the lease suspended. A dedicated address is an identity — it works precisely because it is accountable.