3 months ago
My Postgres HA cluster (project: peos-production) is rejecting the password stored in its own environment variables — POSTGRES_PASSWORD, PGPASSWORD, and DATABASE_URL all show the same value, but authentication fails even connecting from inside the database's own container via its internal hostname (postgres.railway.internal), using the exact password shown by echo $PGPASSWORD in that same container. This started sometime around [today's date] — I'm not certain whether it began before or after I attempted a manual password change via the Variables tab (since the automatic 'regenerate password' button returned 'Password reset is not supported for Postgres HA clusters'). This is currently causing a full production outage — no application can authenticate to the database at all.
2 Replies
3 months ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 3 months ago
3 months ago
You can try to do it manually, by selecting the HA node, then go to the console tab
, from there you can run psql, then use the command ALTER ROLE postgres WITH PASSWORD '<PASSWORD>';. Use the password to update the POSTGRES_PASSWORD/PGPASSWORD variable on the original postgres node you created the HA cluster from
. Then redeploy all related services.
darseen
You can try to do it manually, by selecting the HA node, then go to the console tab , from there you can run `psql`, then use the command `ALTER ROLE postgres WITH PASSWORD '<PASSWORD>';`. Use the password to update the `POSTGRES_PASSWORD`/`PGPASSWORD` variable on the original postgres node you created the HA cluster from . Then redeploy all related services.
3 months ago
I copied the raw psql command directly from your dashboard's Connect panel (Public Network tab), pasted it verbatim into my terminal with no modifications, using the password exactly as shown in your UI. It still fails with 'password authentication failed for user postgres.' This is your own auto-generated command with your own currently-displayed credentials, failing against your own database. This confirms the issue is server-side — the password Railway's UI shows does not match what the Postgres engine is actually enforcing. Please escalate this, as our production database is currently completely inaccessible and our application has been down since this password rotation began.