It looked like a small networking change
DigitalOcean is pushing VPC outbound (egress) traffic away from “just the Droplet public / Reserved IP” toward a dedicated service — VPC NAT Gateway. The idea is sound: keep backends private, send internet-bound traffic through a managed NAT with one static public egress IP. It is closer to AWS-style NAT Gateways and cleaner for partner firewall allowlists.
On paper the cutover is a couple of evenings. In practice we did not get stuck on DigitalOcean — we got stuck on the IP whitelist of a large U.S. payment gateway. A “simple” IP switch took about two weeks.
How it used to work
Classic Droplet setup:
- a Reserved IP (floating) as the familiar “allowlisted” address;
- outbound calls to payments / banks / webhooks often came from that same (or the primary public) IP;
- the gateway console held one or two IPs for years — and it worked.
Replace a Droplet, reattach the Reserved IP, partners still see the same egress. Comfortable.
What changes with NAT Gateway
With a NAT Gateway, outbound traffic goes through a separate managed service, not “from the Droplet NIC the old way”. The gateway gets its own static public egress IP for the lifetime of the resource.
The nuance that bitten us:
- you cannot simply attach an old Droplet Reserved IP onto the NAT Gateway like a classic floating IP move;
- you may set an address at create time (including BYOIP), but that is not the same UX as “move Reserved IP to the new droplet”;
- in the typical path, enabling NAT means a new egress IP — and every external allowlist must be updated.
# simplified path
VPC private Droplets --> NAT Gateway (static egress IP) --> Internet / Payment API
# often before:
Droplet (+ Reserved IP) --> Payment API
Why a “simple switch” took two weeks
On the DigitalOcean side, routing via NAT is relatively quick: create the gateway, set the VPC default route, check curl ifconfig.me from the Droplet — you see the new IP. Then the outside world begins.
- The new egress IP must be added to the payment API whitelist.
- The payment gateway is a fairly large U.S. player (I deliberately omit the name). Adding an IP is slow: tickets, queues, “security review”, escalations.
- In parallel we hit another blocking layer (filter/ACL/fraud contour on top of a plain IP list) — until that was cleared, traffic still failed in places even after “the IP was supposedly added”.
- Result: infra cutover ready, payments not. Waiting on vendor support.
New Year’s night and three weeks of email
The human part hurt most. All of New Year’s night, the week before the holidays, and about two more weeks after went into correspondence with the payment support team. From our side: IPs, logs, sample requests, error screenshots. From theirs: canned replies — “we forwarded this to the right team”, “please wait”, “please confirm you are using the correct endpoint”. They could not really do much — the lever sits in an internal security/ops queue, not with the L1 agent in the chat.
Two weeks for the business is not a “network migration”. It is payment downtime or degradation caused by someone else’s whitelist SLA, while your NAT has been green for days.
What I would do differently
- Provision a second egress IP early and submit it to the whitelist weeks before cutover (dual-run).
- Ask the payment vendor explicitly: IP ACL only, or also ASN/geo/WAF layers.
- Do not schedule a NAT migration into a holiday window — enterprise support goes dark.
- Keep a rollback egress path until the new IP is proven with a real payment, not just
ping. - Put a business deadline in every ticket — otherwise you live on “we are working on it” forever.
Takeaway
DigitalOcean’s VPC NAT Gateway is a sane evolution: outbound through a dedicated service with a static egress IP, closer to “grown-up” cloud networking. Old Reserved IPs do not magically move onto that path, so partners see a new address. Our “simple” switch stalled on a slow whitelist plus an extra block at a large U.S. payment gateway — and stretched into two weeks of emails, including New Year’s night. Lesson: treat egress migrations as vendor/compliance projects, not as an evening of iptables.