OwnStack

Repair after import

If your deploys (or release tasks) start failing with password authentication failed for user "postgres" right after a database restore, you've hit the most common post-import foot-gun. This page is the fix.

What's broken

pg_dumpall (the cluster-wide variant of pg_dump) includes role globals — including each role's password. When you restore that dump, Postgres replays the source cluster's ALTER ROLE postgres WITH PASSWORD '...', overriding whatever password dokku originally set.

Meanwhile, dokku's DATABASE_URL for the app still carries dokku's original randomly-generated password. The role now authenticates with the source's password; the app keeps presenting dokku's old password; every connection fails.

The fix

Align the role's password to whatever DATABASE_URL claims. One ALTER ROLE statement does it.

  1. Read the current DATABASE_URL: 
    $ ssh dokku@<stack-ip> config:get <app> DATABASE_URL
postgresql://postgres:<PASSWORD>@dokku-postgres-<SERVICE>:5432/<DB>
  2. Extract <PASSWORD> and <SERVICE> from the URL — between postgres: and @ for the password; between dokku-postgres- and :5432 for the service name.
  3. Pipe the ALTER ROLE into the service: 
    $ printf "ALTER ROLE postgres WITH PASSWORD '<PASSWORD>';\n\\q\n" | \
    ssh dokku@<stack-ip> postgres:connect <SERVICE>
ALTER ROLE
    The output should be exactly ALTER ROLE. Anything else means the alter didn't apply — stop and investigate.
  4. Retry the deploy. Release tasks now authenticate against the role with the matching password.

Why not just run ownstack db repair?

The current ownstack db repair aligns the role to dokku's service DSN (dokku's own stored password). For the dump-import case, the service DSN itself is sometimes already in sync with DATABASE_URL, but the import desync'd the actual role password — so db repair may not see anything wrong, or may re-set the role to a value that still doesn't match the URL.

The manual ALTER ROLE above is precise: it sets the role to exactly what DATABASE_URL claims, which is what the app uses.

(See control-plane#289 — we're working on a safer redo.)

Don't do these instead

Don'tWhy
ownstack config:set DATABASE_URL=... with a different passwordDokku rebuilds DATABASE_URL from link metadata on every restart, so your override gets clobbered. The link is the source of truth.
dokku postgres:reset-passwordGenerates a brand-new random password on the service side, doesn't update the role inside the container or the app's DATABASE_URL. Three things now disagree instead of two.
postgres:unlink + postgres:linkThis refreshes DATABASE_URL from the service DSN, but doesn't touch the role's password. Fixes nothing.
Use pg_dump, not pg_dumpall, when you can

Per-database dumps (pg_dump) don't include role globals, so they don't cause this drift on restore. Only use pg_dumpall when you actually need cluster-wide state (multi-db apps, custom roles).