2 months ago
Attached is the braindump from Claude, which has been trying to help me troubleshoot the issue.
0 Replies
2 months ago
Hey, since the issue is with the database, have you checked that it can at least be connected to via the public network, the easiest way to check this is to go to the database's Database tab.
Furthermore, have you tried redeploying your Postgres database? Additionally, If you opted for the IPv4 private networking feature flag, I have seen some private network related errors that were caused by this feature flag, so you mostly want to opt out it in this case. You can check if you have opted in at https://railway.com/account/feature-flags. You may have to redeploy your services afterwards once you have opted out of the feature flag.
-# I will go to bed now, so expect delayed responses from me.
2 months ago
As an alternative approach, especially if the n8n instance is new and doesn't have any workflows yet, you can deploy the entire n8n template again after confirming that you don't have the IPv4 feature flag.
That worked! Here's what Claude Sonnet 4.5 (with the MCP server for Railway, deployed) had to say, attached as a .txt file.
Status changed to Solved brody • about 2 months ago