Use cases

Every one of these is the same shape: something on the far side identifies you by address, and your platform will not give you a fixed one.

A partner allowlists your IP

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.

what changes in your code

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

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

CI runners that need a stable identity

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.

GitHub Actions

- 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
Use a full tunnel config in CI. The runner is disposable, there is no SSH session to protect, and nothing needs binding. Store the file as an encrypted secret — it contains a private key, and anyone holding it can egress as you until you revoke that peer, which you can do from your dashboard at any moment.

Serverless and platforms with no fixed egress

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.

If you are weighing that against building the gateway yourself, egress gateways compared covers Istio, Cilium, Calico and cloud NAT side by side, with what each costs to keep running.

Workers in several regions, one identity

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. Latency gives the figure for every region rather than leaving you to guess at it.

Receiving connections on your own address

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.

on the inbound machine

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

This is the case where the routing mode is not a free choice. A reply to somebody on the internet leaves with the leased address as its source, and the machine has to know to send that back down the tunnel rather than out of its own default route — where its provider would drop it for carrying a source that is not theirs. Deciding by source is what Source routing does, and it is a Linux facility: Windows has none, and macOS none in its routing table.

So: on Linux use Source routing and the machine keeps its own default route. On macOS or Windows the only option is a Full tunnel, which works but sends everything else the machine does through us as well — fine for a staging front end, worth thinking about for a game server, whose players would each be paying our round trip twice. Named destinations cannot receive at all: that mode tells your own client to drop anything whose source is not on the list, and a stranger connecting to you never is.

Reverse DNS you control

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.

What it is not for

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.