Inbound IP rules are not available on railway currently. But you can deploy an Nginx service infront of your db, expose it via TCP, and manage the allow-list manually in the Nginx config as a workaround.

Thanks @darseen . If you can give me detailed instructions on how to do this in railway, I'd be happy to mark this as the accepted solution! Thank you!

I will make an Nginx template that handles this, to make it easier for you. It shouldn't take long. I will write here when it's done.

I spent some time testing and trying to build out that Nginx template to manage the database IP allow-list, but I ran into a hard platform limitation.

Unfortunately, IP allow-listing for TCP traffic isn't currently possible on Railway.

When you expose a service via a public TCP port, Railway routes that traffic through their internal load balancers. This means the Nginx container never sees your actual public IP, it only sees Railway's internal network IPs.

Ah that makes sense. Doesn't Railway set headers to include the original IP? Could we use those, or could these be spoofed? Thanks so much for trying.

Because database connections are raw TCP streams (layer 4), we can't rely on HTTP (layer 7) headers like X-Forwarded-For to grab the real IP. You're welcome though.

It's worth mentioning that the industry standard way to fix this for TCP is the "PROXY protocol", but Railway doesn't currently support injecting that on their public TCP endpoints.

OK, thank you for all your work on this; I just marked the answer is approved. I hope Railway adds this feature down the line. Do you think using an external service for the database (Neon) would add noticeable latency to the service (compared to putting everything inside Railway's private network)? If not, it seems worth trying.

You're welcome! As for the latency, yes, it will add some latency, but whether it is noticeable depends on region alignment and how your code queries the database. And since IP-whitelisting is crucial for you, I think it's worth the trade off.

I forgot to mention that egress costs will increase as well. So, I suggest you take that into consideration, and see if it's feasable to host the db using an external service like Neon.

After all, if IP-whitelisting is your top priority, these are the trade offs that you need to consider.

That's correct. Headers like X-Forwarded-For only apply to HTTP traffic through our edge proxy. The TCP proxy operates at Layer 4, so database connections over it don't carry HTTP headers, and there's no mechanism to retrieve the original client IP. IP allowlisting for TCP proxy is a known feature request that we're tracking.

If you want my advice; I suggest you host your db on Railway, remove public TCP connection for the database, and rely only on internal connection. As for development, you can set up a development database locally. You can dump data from your production db, and restore to your local development one. I have a template to back up your database using its internal URL. It will download a dump file to your machine that you can use to restore to your local dev db.

Thanks @chandrika . Is there anywhere public you're tracking the request that I can keep bookmarked? This is the only feature stopping me from moving my apps over from render, so when it happens I'd love to know!

And thanks for the advice and help @darseen

You can track and upvote feature requests on our public roadmap here: https://station.railway.com/roadmap

We are also tracking this thread against the request, so it is likely you would be notified here if we added the feature as well.

One more question if I may - does the Railway API allow me to create/delete a TCP proxy from Python? If so, I think my solution here will be to use a public TCP Proxy, but only very briefly open it when I need it and then close it as soon as I'm done - is that doable? The GraphQL docs do have TCPProxy mentioned there, so it looks doable, but it's my first time using GraphQL so I still need to do some digging. If I figure it out before someone answers, I'll post the code to do it here. Thanks again!