A stable outbound IP, without a NAT gateway bill
Every multi-tenant PaaS runs into the same request eventually: a bank’s API, a payment processor, a partner integration — something on the other end wants a fixed IP address to allowlist before it’ll talk to your app. On a platform where hundreds of apps share a pool of outbound addresses, that means standing up a NAT gateway, often a paid add-on, sometimes its own separate product tier, just to get one address that stays put.
Why the problem doesn’t exist here
An app’s outbound connections leave from its own server’s public IP — because the server isn’t shared with anyone else’s app, there’s no pool to NAT through in the first place. No shared NAT pool, no extra charge for a stable address, no separate feature to enable. The IP only changes if the app itself actually moves to a different server — a real event you’d know about, not a silent platform-side reshuffle.
This isn’t a feature Railyard built to solve the NAT-gateway problem. It’s a structural consequence of the BYO-server model: the thing that makes a stable outbound IP expensive elsewhere (shared infrastructure) isn’t present here at all.
Where to actually find the address
The server’s own page shows its public IP directly — that’s the address to hand to whatever third-party service needs it allowlisted. If the app ever moves (a manual move, or an automatic failover), the IP changes with it, which is worth building into any runbook for a partner integration that depends on it: treat the outbound IP as tied to the server, not as a property of the app that follows it everywhere.
The adjacent problem this doesn’t solve
A stable outbound IP for talking out to third parties is a different problem from apps talking to each other privately — that’s what private networking is for: every app gets <name>.railyard.internal, resolved over an encrypted WireGuard mesh when apps are split across servers, so one app references another by name instead of by whatever public or private address it happens to have today. The two features solve genuinely different problems and don’t substitute for each other — outbound stability is about what a third party sees; private networking is about what your own apps see.
Full reference: Networking.