A Static Outbound IP for Railway
Railway has a built-in Static Outbound IPs feature for Pro plan customers, enabled per service with a toggle and a redeploy. It is the fastest fix and you should try it first. But read one sentence from Railway's own documentation before you promise the address to anybody: “There is no guarantee that the IPv4 addresses assigned to your service are dedicated. They may be shared with other customers.” That sentence decides whether it is enough for you.
Why the address moves by default
Railway schedules your service onto shared infrastructure and outbound traffic takes that infrastructure's address. Redeploys, restarts and scaling move the service, and the address moves with it. There is nothing stable to hand a partner.
Railway's own answer, and how to turn it on
Static Outbound IPs are available on the Pro plan, and Railway's documentation says Pro customers can enable them for any service they wish. In the dashboard: Settings → Networking → Enable Static IPs, review the assigned addresses, then redeploy. From the CLI:
railway outbound-network static-ip enable --service api
If you are on Pro and the far end simply needs the address to stop changing, turn this on and stop reading. It is included in the plan, it takes a minute, and there is nothing to run.
The sentence that decides it
Railway is unusually straight about the limitation, and it deserves to be quoted rather than paraphrased: “There is no guarantee that the IPv4 addresses assigned to your service are dedicated. They may be shared with other customers.”
That is fine for a great many integrations. A vendor that filters by source address usually wants stability, not exclusivity. Turn it on, file the addresses, move on.
It is not fine in three situations, and they are worth checking before you file anything:
- A security review asks whether the source address is exclusive to you. The honest answer is that Railway does not guarantee it. Banks, payment processors and enterprise procurement ask this.
- Reputation matters. A shared address carries whatever else is sent from it. If the far end scores sender reputation, you inherit strangers' behaviour.
- The far end allows a single address, not a range, and you need certainty that the one you filed is the one you will always use.
When an address you hold is the better trade
If any of those three apply, or if the same allow-list entry has to cover things outside Railway, attach a dedicated address to a small always-on box and route those specific calls through it.
What the far end sees is your address from 23.187.152.0/24, announced by AS396500 — exclusive to you with no “may be shared” caveat to explain to a reviewer, and the same address from Railway, from a VPS, or from your office.
Honest caveats:
- You are adding a hop and a machine you keep running. Railway's toggle adds neither.
- It covers named calls, not all egress from the service.
Verify the source address before you file it
Railway's dashboard shows the addresses assigned to your service. Confirm them from the running service anyway, because the feature needs a redeploy to take effect and a service you forgot to redeploy still leaves from the old address:
curl -4 https://api.ipify.org
Check it a second way (curl -4 https://ifconfig.co), and re-run after a redeploy. A mis-filed address fails as a total denial at the far end, not as a warning.
What this costs with us
A dedicated address is $20/month on TunnelNet Full, inbound and outbound on the same address, attached to a machine you already have. TunnelNet Business is $100/month for the same address with a written 8-working-hour response commitment (09:00–17:00 US Central, Monday to Friday), onboarding done with a person who verifies the source address from outside our network before you file it, and our measured uptime published — incidents included.
Plainly, because you are about to put a partner integration on this: we have no SLA and will not offer one until we have six months of measured history, 21 February 2027 at the earliest. A hub failure that withdraws routes takes about 25 seconds to recover, measured — and a hub that stays up while it stops forwarding is not failed over automatically at all. Railway will quote you better availability numbers than that, and they will be true. Weigh it against what the address itself is worth to you.
Static IP for your platform
The same question, answered for each platform it comes up on most. Every one of them leads with that platform's own native or free answer:
- AWS Lambda — VPC and NAT Gateway, and what that really costs
- Vercel — $100/month per project, and Vercel documents the IPs as shared
- Netlify Functions — no list exists — what to try before building anything
- Supabase Edge Functions — Supabase documents that there is no static egress IP
- Heroku — Private Spaces, proxy add-ons, or an address you hold
- Render — shared by default, genuinely dedicated on Pro
- GitHub Actions — larger runners, or the free self-hosted answer
- Zapier — included on Professional, absent on Free
And the general case, if your platform is not listed: