How to Reset PostgreSQL Password Inside Docker Container

Resetting a PostgreSQL password inside a Docker container is a bit different from a normal installation, because you’re working through docker exec rather than a local shell, and the common instinct to just delete and recreate the container can wipe out your data if you’re not careful about volumes.

The Problem

You’ve lost or forgotten the password for a PostgreSQL user running inside a container, and you need to reset it without losing the existing database contents. Trying to connect fails with:

psql: error: connection to server failed: FATAL: password authentication failed for user "postgres"

and simply removing the container and starting a fresh one only works if you’re fine losing all existing data — which usually isn’t the case.

Why It Happens

This isn’t really a “bug” scenario so much as a normal operational need, but it trips people up in Docker specifically because:

• The POSTGRES_PASSWORD environment variable only sets the password the very first time the container initializes its data directory — changing it in docker-compose.yml and restarting the container does nothing if a data volume already exists
• People aren’t always sure whether resetting the password requires deleting the volume (it doesn’t), leading to unnecessary data loss
• The reset process requires running commands as the postgres superuser from inside the container, which is a different workflow than resetting a password on a local install

The Fix

First, get a shell inside the running PostgreSQL container:

docker exec -it your-postgres-container bash

From inside the container, connect to PostgreSQL as the superuser using psql, without needing a password since local socket connections from within the container are typically trusted by default:

psql -U postgres

Once connected, reset the password for the user in question with a standard SQL command:

ALTER USER postgres WITH PASSWORD 'your-new-password';

Replace postgres with the actual username if you’re resetting a different role, and exit with \q when done.

If you can’t get into psql at all (for example, if authentication is misconfigured and even local trust connections are being rejected), you can temporarily relax authentication by editing pg_hba.conf inside the container to allow trust authentication, reset the password, then revert the change:

docker exec -it your-postgres-container bash -c "sed -i 's/scram-sha-256/trust/' /var/lib/postgresql/data/pg_hba.conf"
docker restart your-postgres-container

After resetting the password through psql, revert pg_hba.conf back to its original authentication method and restart the container again, so you’re not left with a database that accepts unauthenticated connections.

Finally, update any connection strings, .env files, or docker-compose.yml environment variables that reference the old password, so your application doesn’t keep trying to authenticate with credentials that no longer work.

Still Not Working?

If none of the above works because you genuinely can’t get any kind of shell or database access into the container, and the data itself isn’t critical, the last resort is removing the container and its associated volume to start fresh with a new POSTGRES_PASSWORD:

docker compose down -v

Be aware that the -v flag deletes the named volumes along with the containers, which permanently removes all data — only use this if you’ve confirmed you don’t need to preserve what’s currently in the database.

If the data does matter but you still can’t authenticate through any normal path, consider backing up the data directory itself before making any destructive changes. Copying the volume’s contents to a safe location first means that even if a reset attempt goes wrong, you still have a fallback to restore from, rather than being forced to choose between “reset and lose everything” and “stay locked out indefinitely.”

Finally, if you manage this container through an orchestration tool like Docker Swarm or Kubernetes rather than plain Docker Compose, be aware that some of the manual steps above (like editing pg_hba.conf directly inside the container) may not persist across a pod or service restart if the configuration isn’t stored in a persistent volume. In those environments, it’s usually cleaner to update the password through a proper secrets management workflow and trigger a controlled rolling restart, rather than exec-ing into a running container and hoping the change survives the next scheduling event.