a month ago
Hello Railway Team,
We are experiencing a networking issue after the recent US region incident.
Our backend service (FlexyBank) and PostgreSQL service are both in the same Railway project, same production environment, and both are deployed in the US East (Virginia) region.
The backend container has:
RAILWAY_PRIVATE_DOMAIN=flexybank.railway.internal
However, from inside the running backend container, the following command returns no result:
getent hosts postgres.railway.internal
When we change DATABASE_URL to the PostgreSQL private URL:
postgresql://...@postgres.railway.internal:5432/railway
our deployment fails during the Prisma pre-deploy migration with:
P1001: Can't reach database server at postgres.railway.internal:5432
The backend only works when using the public proxy URL:
postgresql://...@switchback.proxy.rlwy.net:20543/railway
Before the recent Railway incident, the application was extremely fast. Since the incident, all database-backed requests became significantly slower (3-4 seconds response times), and it appears that private networking between the backend and PostgreSQL may no longer be functioning correctly.
Could you please check:
- Private DNS resolution for
postgres.railway.internal - Private networking connectivity between our backend and PostgreSQL services
- Whether our services were affected by the recent US region incident
- Whether our backend is being forced to use the public proxy instead of the internal network
Thank you very much for your assistance.
3 Replies
a month ago
This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.
Status changed to Open Railway • about 1 month ago
a month ago
Verify that the database service matches exactly as in your connection string.
in railway dashboard, the database service is not named as postgres or postgresql.
you need to update your DATABSE_URL to use correct internal domain name.
also check that no isolation rules are blocking the connection.
can you share error logs from the backend container when the connection failed?