Improve database configuration and volume management in Docker setup

[iam-deepaknagaraj]

Ticket

https://community.openproject.org/projects/docker/work_packages/73743/activity

What are you trying to accomplish?

Improve the Docker Compose developer/operator experience for the bundled openproject-docker-compose setup by:

1. Proxy service – Compose was attempting to pull openproject/proxy from a registry even though that image is only produced by the local ./proxy build, which led to pull errors (e.g. “pull access denied” / “repository does not exist”) on docker compose up depending on Compose version and pull policy.
2. PostgreSQL credentials – Document and align POSTGRES_PASSWORD with DATABASE_URL, and default DATABASE_URL in docker-compose.yml to derive from POSTGRES_PASSWORD when DATABASE_URL is unset, so the app and db service stay in sync.
3. Volume configuration in .env.example – Replace misleading PGDATA / OPDATA values that looked like in-container paths but were interpreted as bind-mount sources (e.g. /var/lib/postgresql/data), which reused existing clusters and caused persistent “password authentication failed for user postgres” when the password in .env did not match the already-initialized database. The example now uses named volumes (pgdata, opdata) and short comments explaining the semantics.

Screenshots

N/A (configuration and documentation only).

What approach did you choose and why?

• pull_policy: build on proxy – Tells Compose to build from ./proxy and not pull openproject/proxy from a registry. Minimal change; matches how the image is actually produced.
• DATABASE_URL default with ${POSTGRES_PASSWORD} – Single source of truth for the default password when users omit an explicit DATABASE_URL, reducing drift between db and app containers.
• .env.example with POSTGRES_PASSWORD, PGDATA=pgdata, OPDATA=opdata – Matches common Compose usage, avoids accidental bind mounts to host paths, and documents that POSTGRES_PASSWORD only applies on first database initialization.

Tradeoffs: Users who intentionally used bind mounts to host paths must set PGDATA / OPDATA explicitly to those paths; the sample no longer encodes that pattern.

Alternatives considered: Renaming env vars (e.g. POSTGRES_DATA_VOLUME) would be clearer but diverges further from upstream naming and existing docs; skipped for a smaller, reviewable change.

Follow-up (optional, separate change): Align README.md sections that still assume /var/openproject/assets on the host with the new named-volume default in .env.example.