On July 3, 2026, Railway's changelog announced that static outbound IPs and IPv6 controls had landed in its CLI — a new railway outbound-network command that lets you enable a stable egress address for a service without touching the dashboard. It is a genuinely useful feature, shipped well. It is also, like every version of this feature on every hosted platform, gated: static outbound IPs on Railway are a Pro-plan capability. The address your app presents to the outside world is a product you buy.
Here is the thing the changelog does not say: on a server you own, that same property costs almost nothing and requires no feature launch. A Hetzner Cloud primary IPv4 is €0.50 a month — IPv6 is free — and it is yours as a persistent, independently managed resource for as long as you keep paying for the box. "Rounding error" is meant literally: not a separate SKU, not a plan gate, not a metered proxy — an address that comes with the machine, at a price that disappears next to the server itself.
At a glance, what a stable outbound IPv4 costs in 2026:
| Where your app runs | What you pay for a stable egress IP | The gate |
|---|---|---|
| Railway | Pro plan required ($20/month workspace) | Plan tier |
| Render | Extra monthly fee per dedicated IP set | Pro workspace + add-on |
| Heroku | $5–$1,599/month (QuotaGuard Static) | Third-party proxy add-on, metered per request |
| Fly.io | ~$3.60/month per machine | Per-machine hourly charge |
| A Hetzner box you own | €0.50/month (IPv4), €0 (IPv6) | None — it's a property of the machine |
The rest of this post unpacks why that address matters at all, what Railway actually shipped, what each platform charges for the same bits, and how a fleet you own hands its address to a bank's allowlist form without a line item.
The Allowlist Problem: Your Outbound Address Is an Identity
Plenty of teams never think about their egress IP until the day a third party asks for it. The asks are always the same shape:
- Payment providers and banks. Many financial APIs — bank integrations, some payment gateways, most anything touching regulated money movement — require you to register the source IPs your requests will come from. No registered IP, no API access.
- Partner firewalls. An enterprise customer's security team will happily open port 443 to your integration — as soon as you tell them which addresses to open it for. "Our platform's shared NAT pool" is not an answer their change-request form accepts.
- SMTP relays. Mail infrastructure is allowlist-and-reputation all the way down. Relays, on-premises Exchange servers, and strict corporate mail gateways frequently accept connections only from named addresses.
- Databases in another cloud. A managed Postgres in RDS or Cloud SQL with a locked-down security group needs to know your app's source address. Opening it to
0.0.0.0/0is how incidents start.
Railway's own changelog names the same list — the feature exists for "when something outside Railway allowlists traffic by source address, like a payment provider, a partner's firewall, or a database in another cloud."
The reason this is a problem on a hosted PaaS is architectural. Multi-tenant platforms put outbound traffic behind shared NAT pools whose addresses are anonymous, shared with other customers, and subject to change as the platform scales. That is the right design for the platform — and it means your app has no stable identity on the wire. Egress identity becomes something the platform must build, gate, and sell back to you. Hence the add-on.
What Railway Actually Shipped in July 2026
Credit where due: Railway's implementation is more complete than most. The July 3 changelog entry ("The peaceful way to ship software, static outbound IPs and IPv6 in the CLI") moves controls that previously existed only as dashboard toggles into the CLI:
railway outbound-network statusshows current static IP assignments and IPv6 configuration for a service and environment.railway outbound-network static-ip enable | disablemanages the IPv4 addresses, with high-availability status reporting; changes apply on the next deploy.railway outbound-network ipv6 enable | disablestages environment-level IPv6 configuration.- Everything takes the standard
--service/--environment/--projectselectors and a--jsonflag — a nice touch for scripts and, notably, for agents operating the platform.
The constraints, from Railway's documentation, are where the hosted-platform shape shows through:
- Pro plan only. Static outbound IPs are a Pro-tier capability ($20/month per workspace, which includes $20 of usage credit).
- Per-service, IPv4-only, outbound-only. Addresses are assigned per service, cannot receive inbound traffic, and there is no static-IPv6 equivalent.
- Possibly shared. The docs note assigned IPv4 addresses may be shared among customers rather than exclusively dedicated — fine for most allowlists, worth knowing for reputation-sensitive traffic.
- Region-bound. Move the service to another region and you get different addresses — and another round of allowlist paperwork with every third party that registered the old ones.
- HA migration. Legacy single-IP services are being migrated to a high-availability mode with three load-balanced IPs, mandatory as of July 13, 2026. Three addresses to register instead of one, in exchange for a more resilient egress path.
None of this is a criticism of the engineering. It is an observation about the product physics: on a multi-tenant platform, a stable egress address is a feature with a roadmap, a plan gate, and edge cases — because the default is anonymity.
The Egress Tax, Platform by Platform
The at-a-glance table above hides the interesting details. Here is what the gate actually is on each platform.
Railway ties the capability to the Pro plan. If you are on Pro anyway, the marginal cost is zero; if the allowlist requirement is the only thing pushing you off Hobby, the effective price of an IP address is the plan delta.
Render gives every service shared, region-wide outbound IP ranges by default — good enough for coarse allowlists, shared with every other Render customer in the region. Truly dedicated egress requires a Pro workspace plus a dedicated IP set: three IPv4 addresses exclusive to your workspace, billed as "an additional monthly fee for each IP set," with a default cap of four sets per workspace, one set per region-environment combination, and no way to move a set between regions after creation.
Heroku never shipped native static IPs at all. The ecosystem answer is proxy add-ons like QuotaGuard Static, which route your outbound traffic through an HTTP or SOCKS5 proxy with fixed addresses — and meter it per request. The tiers tell the story: $5/month buys 5,000 requests, $19 buys 20,000, $89 buys 250,000, and the unlimited tier is $1,599/month. An app making one allowlisted API call per second — about 2.6 million requests a month — has blown past the $219 one-million-request tier and lands on the $399 plan; sustain a few calls per second and you are shopping in the $659–$1,199 range. The allowlist itself was free; the route to it is metered.
Fly.io is the most honest of the hosted options: a static egress IP costs $0.005 per hour, about $3.60/month, per machine, covering both IPv4 and IPv6. Reasonable — until you multiply by a fleet. Ten machines that all need to present a registered address is $36/month, forty is $144/month, for a property that costs a server owner one flat €0.50.
The pattern across all four: the price is never really the number. It is the shape of the charge — a plan gate, a per-set fee, a per-request meter, a per-machine multiplier — that turns a fixed property of networking into a scaling line item.
On a Box You Own, Egress Identity Is a Property, Not a Product
A server you rent from Hetzner, OVH, or any dedicated-hosting provider has a public IPv4 address as a basic property. On Hetzner Cloud it is a primary IP: €0.50/month for IPv4, free for IPv6, manageable as an independent resource — you can create it separately, keep it while replacing the server behind it, and reassign it. On Hetzner's dedicated servers, the IPv4 is simply included. Every packet your machine sends leaves with that address. There is nothing to enable.
For a single box, that is the whole story: the bank's allowlist form gets one address, and that address is yours until you delete it.
For a Kubernetes fleet — say, a Cluster-API-provisioned set of Hetzner machines — there are two clean patterns:
- Register the node addresses. Each node's primary IP is stable for the node's lifetime. For a small, mostly static fleet, handing the third party your three node IPs (or the small CIDR they live in) is exactly equivalent to what Railway's three-IP HA set gives you — except the addresses are yours, and adding a node is €0.50, not a plan upgrade.
- Run an egress gateway. For fleets that scale nodes up and down, route allowlisted traffic through one stable point: a small NAT/SNAT gateway node (or an egress-gateway feature of your CNI — Cilium ships this) whose single primary IP is the fleet's registered identity. Nodes churn; the address the bank sees never changes.
The worked total for a three-node fleet with an egress gateway: three primary IPv4s plus one for the gateway is €2/month, flat, regardless of how many services run on the fleet, how many requests they make, or what plan tier anyone is on. The equivalent posture on the hosted platforms is a $20/month plan gate (Railway), an add-on fee per IP set (Render), $3.60 × N machines (Fly.io), or a request meter that can reach four digits (Heroku).
The deeper point is not the euros. It is that on owned infrastructure, egress identity is not a feature anyone had to ship. It cannot be gated, deprecated, migrated, or re-tiered, because it is just how networks work when you are not behind someone else's NAT.
Where the Managed Model Has a Point
An honest comparison names the cases where the add-on is the right call.
- Tiny volumes. If your allowlisted traffic is 5,000 requests a month — a nightly reconciliation job hitting a bank API — QuotaGuard's $5 tier costs less than any server. Below roughly the price of one small VPS (~€4–5/month), the metered proxy wins on pure cost, and there is nothing to operate.
- IP reputation is now your job. Owning addresses means owning their history. For SMTP especially, a fresh IP must be warmed up, kept off blocklists, and monitored. Platforms and mail-relay vendors amortize that work across customers; you do not get to.
- HA of the egress path is your job too. Railway's mandatory three-IP high-availability migration exists because a single egress address is a single point of failure. If you run one NAT gateway node, you have re-created that SPOF and it is yours to make redundant — a second gateway and a failover route are not hard, but they are not zero either.
- The paperwork cuts both ways. Allowlist updates are slow at banks. A platform that keeps your addresses stable across its own infrastructure churn is doing real work; on your own fleet, that discipline (don't casually delete the primary IP; treat registered addresses as pets) is a process you must enforce.
The sensitivity line is easy to state: the metered add-on wins at trivial volumes; the plan gate wins if you were on that plan anyway; and everything above that — steady traffic, multiple services, more than a couple of machines — tips toward the flat €0.50 property, with the caveat that reputation and egress-path redundancy move onto your plate.
The Address Is the Cheapest Part of Owning Your Platform
Railway's July 2026 release is a good feature on a well-run platform, and the CLI treatment — JSON output, scriptable enable/disable — is exactly how this control should look. But it is also a clean specimen of a general law: on a hosted PaaS, every property of the underlying network eventually returns as a product. Static egress was Railway's July; observability surfaces, private networking, and IPv6 each had their own changelog day. On machines you own, those aren't launches. They're defaults.
If a third party's allowlist form is what finally makes you price out owning your platform, the math is refreshingly short: the address is €0.50 of the bill. The real question is whether you want the rest of the stack — deploys, TLS, scaling — to come with the same no-line-item property.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, where the egress address your integrations register is simply your machine's own. Star the repo on GitHub or deploy your first app today.
Sources:
- Railway changelog — July 3, 2026: static outbound IPs and IPv6 in the CLI
- Railway docs — Static Outbound IPs
- Railway pricing
- Render docs — Static outbound IP addresses
- Render docs — Dedicated IPs
- QuotaGuard Static IPs — Heroku add-on pricing
- Fly.io pricing — IP addresses and static egress IPs
- Hetzner Cloud docs — Primary IPs



