ALTER ROLE postgres WITH PASSWORD 'SomeStrongPassword!';
I then updated my Node app DB config to use:
user: postgres
database: postgres
host: Postgres container / mapped host port
password: postgres!
However, the app still logs:
text
ERROR: Error in getTrendingVisa: password authentication failed for user "postgres"
ERROR: Error in getAllVisa: password authentication failed for user "postgres"
So it looks like the password change is not being honored (or not used correctly) for the Node connection, even though the role password was altered.
Questions
What is the correct way to define and persist the password for the postgres user in the official postgres:16 Docker image so that a Node.js app in another container (or on the host) can authenticate reliably?
Given that this container was already initialized and then I did a manual restore with psql, is it safe to just rely on ALTER ROLE postgres WITH PASSWORD 'postgres';, or should I recreate the container with POSTGRES_USER / POSTGRES_PASSWORD env vars and a fresh volume?
Are there any pg_hba.conf / authentication or networking gotchas in this scenario (container‑to‑container vs host‑to‑container) that could explain why the Node app still gets password authentication failed while the role password was explicitly changed?
If needed, I can also share my Node DB connection config and the exact docker run / docker-compose definition for postgres_container_v2.
A container image is just a template to give you a software that can run in an isolated way in a container. The “postgres:16” official Docker image contains Postgres so how that stores passwords depends on how Postgres stores passwords. If you resotred the data of Postgres, either the data required to acces postgres was corrupted or the restored data didn’t contain the password you expected.
Regarding your questions:
The image descriptions shows how you can store persistent data outside the container properly. Depending on the postgres version, the PGDATA path can be different, but if you used mounted folders and didn’t store data on the container’s filesystem, you did right: https://hub.docker.com/_/postgres
Containers can be created, deleted, recreated and it will not affect data as long as you used volumes or bind mounted folders as I mentioned in point 1. So no, you don’t need to use environment variables to create a new user or modify an existing user. That is used only when the postgres database is first initialized. So it is not just tht you can use ALTER ROLE, but you need to entirely rely on any native Postgres solution, including ALTER ROLE.
As far as I remember, the pg_hba.conf is stored in the same folder where other database files. So if you mounted a folder or volume I mentioned in point 1 and 2, that should have been restored as well. If it was corrupted in any way or not in a state you expect it to be, I think you need to fix that manually. The pga_hba.conf can control how and where you can access the db from, but it is not changed when the data dir is not empty. It is in an “IF” block based on a DATABASE_ALREADY_EXISTS variable: postgres/16/trixie/docker-entrypoint.sh at 2925b19f45ceeb8ab8488eec226f2736abf297e1 · docker-library/postgres · GitHub
You can also see in the container logs whether initialization was “skipped” or not.
You can share that if you suspect you did something wrong like mounting something incorrectly. But if you found all the existing data in the container, except the password didn’t work, I assume your mount was correct..
Since the volume mounting and data persistence appear to be working correctly, I focused next on the Postgres-level configuration. I verified that pg_hba.conf is using scram-sha-256, and I also reset the role password from inside the container using ALTER ROLE, but the authentication issue still persists.
At this point, could you suggest what additional areas or configurations I should check next to further narrow down the root cause?