Subject: Postgres password variable desync — no "Regenerate" option found in current UI (postgres-ssl template)

Question

這段你可以直接複製貼去 Railway 支援（[station.railway.com](https://station.railway.com) 或 Dashboard 右上角 Agent/客服）：

---

**Subject: Postgres password variable desync — no "Regenerate" option found in current UI (postgres-ssl template)**

Project: `okr-system`, Environment: `production`, Service: `Postgres` (template: `railwayapp-templates/postgres-ssl`), dependent service: `okr-api`.

We needed to rotate our Postgres role password for security reasons (the previous credentials had been exposed). While doing so we ran into the following:

1. We ran `ALTER USER postgres WITH PASSWORD '<new_password>'` directly against the database via `railway connect Postgres`. This succeeded (`ALTER ROLE`).
2. We then tried to manually update the `PGPASSWORD` and `POSTGRES_PASSWORD` service variables in the dashboard to match. After deploying, the edited value appeared to revert back to the old one — we're not fully sure whether this is a UI issue (edit not persisted) or the actual database role password being reconciled back by the platform.
3. Following [this known-issue thread](https://station.railway.com/questions/postgres-password-desync-web-service-c-a1b53775), we looked for the recommended "Regenerate" button under Database > Config, but in our current dashboard version that tab shows the same content as the Data tab (Deployment Online / Required Variables / Database Connection status only) — no Regenerate action is present.
4. Our dependent service (`okr-api`)'s `DATABASE_URL` is stored as a literal connection string, not a `${{ Postgres.DATABASE_URL }}` reference variable, so it won't auto-sync with any change made on the Postgres service side.

Could you help us:

- Confirm the current, actual password state of the `postgres` role on this service (whether it matches the dashboard's `PGPASSWORD`/`POSTGRES_PASSWORD` values right now), and
- Advise the correct, safe procedure to rotate this password going forward so that the database role, the service variables, and `okr-api`'s `DATABASE_URL` all end up consistent — ideally without downtime for the currently-running `okr-api` service.

Everything is currently online and healthy; this isn't an active outage, just a rotation we want to complete correctly.

---