4 months 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 refused pg_isreadyreturns "no response" for the private networking address- PostgreSQL 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:17 - Region: US West (California)
- Volume: 50GB at
/var/lib/postgresql/data - Private 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
4 months 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 • 4 months ago
4 months ago
i have the same issue, only the PSQL image version is 15
4 months 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