Supabase template fails with invalid_password after updating POSTGRES_PASSWORD in .env (Volumes not recreating via UI)

[rossanodr]

Template Name

Supabase

Relevant Logs of the Error

[error] Postgrex.Protocol (#PID<0.5529.0>) failed to connect: ** (Postgrex.Error) FATAL 28P01 (invalid_password) password authentication failed for user "supabase_admin"

(Note: This error loops continuously in the Logflare/Analytics container, preventing other dependent containers from transitioning from "created" to "running").

Steps to Reproduce the Error

1. Deploy the Supabase template normally.
2. Wait for the initial deployment to finish successfully.
3. Stop the project in the Dokploy dashboard.
4. Go to Environment settings and update the POSTGRES_PASSWORD (and other related secrets).
5. Start/Deploy the project again.
6. Error occurs: The analytics container (and others) crash with invalid_password because the Postgres database retained the initial password from the first boot.
7. Attempted Workaround: Stop the project and delete the database volume via the "Advanced/Volumes" tab in the Dokploy UI to force a fresh Postgres initialization.
8. Deploy again.
9. Error persists: The volume is not properly recreated, or the underlying data persists on the host.

Expected behavior: > Updating .env variables and redeploying should either gracefully update the services, OR if a user manually deletes a volume via the UI to start fresh, the underlying physical folders should be wiped so the next deploy can initialize a clean database with the new passwords.

Actual behavior: > The database retains the initial password regardless of .env changes. Deleting the volume via the Dokploy UI does not actually wipe the physical data directory on the host, making it impossible to update passwords or do a clean reset without SSH-ing into the server to run rm -rf on the hidden bind mount folders.

Question for maintainers: How are we supposed to securely update database passwords or reset the database if updating the .env fails and the UI volume deletion doesn't clear the host directory?

Environment Information

Operating System: Linux (Ubuntu/Debian)
Dokploy version: v0.29.1
VPS Provider: Hostinger
Template Version: Supabase 1.25.04
Browser: Chrome

When does this error occur?

After successful deployment

Additional Context

No response

Will you send a PR to fix it?

Yes

[dosubot]

Hi @rossanodr! I'm Dosu and I’m helping the templates team.

This is a well-documented issue that affects all PostgreSQL-based compose templates in Dokploy, not just Supabase. There are two separate problems at play here:

1. POSTGRES_PASSWORD only applies on first initialization. This is standard PostgreSQL Docker behavior — the password environment variable is only used when the data directory is empty and the database is being created for the first time. Changing it in .env after the database already exists has no effect on the actual PostgreSQL user credentials [1].

2. Bind mount directories are not cleared by UI volume deletion. The Supabase template stores PostgreSQL data in a relative bind mount at ../files/volumes/db/data/ [2]. Dokploy's docker compose down --volumes only removes named volumes (like db-config), not bind mount directories on the host [3] [4]. This is why deleting the volume via the UI doesn't actually wipe the database.

Workaround — Option A (update password in-place):

# Exec into the running Postgres container and update the password
docker exec -it $(docker ps -q -f name=db) \
  psql -U supabase_admin -c "ALTER USER supabase_admin WITH PASSWORD '<your_new_password>';"

Then restart the project so all dependent services reconnect with the new credential [1] [5].

Workaround — Option B (full reset via SSH):
SSH into the server and manually remove the bind mount data directory. The path will be inside the compose project directory, something like:

# Find and remove the PostgreSQL data directory
rm -rf /path/to/compose/project/files/volumes/db/data

Then redeploy — PostgreSQL will re-initialize from scratch using the new POSTGRES_PASSWORD value.

Both of these require CLI access, as there's currently no UI mechanism to rotate database credentials or clean up bind mount directories after deployment [6].

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.