a month ago
Project ID: 31ea39d8-9878-471a-9f56-327a6a199fc6
Environment: production
PostgreSQL Service ID: f0ea6889-d7ca-4754-a60a-e92bbedb2be4
Issue: PostgreSQL private networking (postgres.railway.internal:5432) is not accepting connections, despite the container showing as running with normal CPU/memory metrics (~400MB memory usage).
Symptoms:
All application services fail to connect with:
connection to server at "postgres.railway.internal" (fd12:2ebd:b579:1:2000:b2:eae8:d41f), port 5432 failed: Connection refusedpg_isreadyreturns "no response" for the private networking addressPostgreSQL deployment status shows SUCCESS
Container metrics show ~400MB memory, active CPU usage
Volume is healthy (11GB/50GB used)
Timeline:
~16:23 UTC (2026-02-16): PostgreSQL container was stopped (logs show "Stopping Container") after a flood of duplicate key errors
Multiple redeploys and restarts attempted via CLI - all show SUCCESS but connections still fail
Private networking appears to be broken while the container itself is running
What we've tried:
railway redeploy --service Postgres(SUCCESS, no change)railway restart --service Postgres(no change)Redeploying dependent services (all crash on DB connection)
Configuration:
Image:
ghcr.io/railwayapp-templates/postgres-ssl:17Region: US West (California)
Volume: 50GB at
/var/lib/postgresql/dataPrivate networking DNS:
postgres.railway.internal
Request: Please help figure out why private networking is not routing to the PostgreSQL container. The container appears to be running but is not reachable via the internal DNS/IP addresses.
3 Replies
a month ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • 27 days ago
a month ago
i have the same issue, only the PSQL image version is 15
a month ago
re-generating PSQL password worked for me in 2 environments. Its weird becuase ive checked before that password in PSQL service variables and in backend variable (which is of course referencing PSQL variable) are the same. And backend was redeployed many times, so it must ahve picked it up correctly