21 days ago
I need to rotate the credential of a production Postgres service because it was exposed outside Railway. I want to use the managed Regenerate action, but the docs do not specify its exact mechanics, and I do not want to cause an outage or leave the database and the variables out of sync.
Project: glorious-radiance
Environment: production
Service: Postgres (Railway postgres-ssl template, PostgreSQL 18, one replica, volume attached, Public Access NOT enabled)
Consumers: one web service and one cron service, both connecting over the private network
Could you please confirm:
- Does Regenerate change the actual PostgreSQL role password inside the database (for example via ALTER ROLE), or only the Railway variables?
- Which Railway variables are updated automatically (for example POSTGRES_PASSWORD, PGPASSWORD, DATABASE_URL, DATABASE_PUBLIC_URL)?
- Does the PostgreSQL service restart or redeploy as part of Regenerate?
- Are existing database sessions terminated, or do they stay open until they disconnect?
- Must the web and cron services be redeployed manually afterwards, and is a plain "Redeploy" of the existing deployment enough?
- Do reference variables (for example ${{Postgres.DATABASE_URL}}) in dependent services update automatically, and when do they take effect?
- If the database role password and the connection variables ever become unsynchronised, what is the recommended recovery procedure? I have seen reports of authentication failures (28P01) over the private network after Regenerate while local-socket logins still worked, and I would like to know whether that is a known behaviour.
- Is the new password displayed, copied or logged anywhere during or after regeneration (dashboard, activity feed, deployment logs, database logs)?
- Our cron DATABASE_URL references mismatch.DATABASE_URL, while web DATABASE_URL references Postgres.DATABASE_URL. Are these references resolved transitively when cron deploys? Does web need to be redeployed before cron after database password regeneration?
If any step is not supported or has known edge cases for this template version, please say so.
Thanks,
Ben
1 Replies
Status changed to Awaiting Railway Response Railway • 21 days ago
21 days ago
Regenerate changes the actual role password inside PostgreSQL (an ALTER USER, run over the network, with an in-container fallback if that login fails) and then writes the new value to POSTGRES_PASSWORD. Variables built from it, such as PGPASSWORD, DATABASE_URL and DATABASE_PUBLIC_URL on the template, resolve from that value. The Postgres service is then redeployed so its own environment carries the new password.
Existing sessions are not explicitly terminated, but any new connection with the old password fails, so connection pools reconnecting will hit authentication errors until the consumers pick up the new value.
Dependent services are not redeployed automatically. Reference variables resolve at deploy time, so web and cron each need a redeploy after the regenerate finishes, and a plain Redeploy is enough because it renders variables fresh. References resolve transitively, so cron's chain through mismatch resolves to the new value on its own deploy; there is no required order between web and cron.
The password is not written to deployment or database logs by the regenerate process. It remains viewable to project members in the database's Config tab under Connection and in the Variables tab, as before.
If the role password and variables ever diverge (for example a manual ALTER USER or a hand-edited variable), set the variable back to the password the database actually holds, redeploy the services that use it, then Regenerate again. A private-network 28P01 while socket logins still work is that same mismatch: socket logins don't check the password the variable holds.
Status changed to Awaiting User Response Railway • 21 days ago
14 days ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • 14 days ago