Skip to content

fix(deploy): mount the Postgres 18 volume where the image expects it - #1397

Merged
iammukeshm merged 1 commit into
fullstackhero:mainfrom
marcelo-maciel:fix/compose-postgres18-mount
Sep 26, 2026
Merged

iammukeshm merged 1 commit into
fullstackhero:mainfrom
marcelo-maciel:fix/compose-postgres18-mount

Conversation

@marcelo-maciel

@marcelo-maciel marcelo-maciel commented Sep 25, 2026 •

Copy link
Copy Markdown
Contributor

docker compose up from deploy/docker never gets past Postgres on a fresh machine. The compose file runs postgres:18-alpine with the data volume mounted at /var/lib/postgresql/data, and the 18+ images refuse that layout outright, even on an empty volume:

Counter to that, there appears to be PostgreSQL data in:
  /var/lib/postgresql/data (unused mount/volume)
...
The suggested container configuration for 18+ is to place a single mount
at /var/lib/postgresql

The container restarts in a loop, so migrator and api (which wait on postgres: service_healthy) never start. It has been this way since the image moved to 18 in 52f87d7f (2026-06-04). I hit it while walking the full stack for the i18n PRs.

Change

  • deploy/docker/docker-compose.yml: mount pg_data at /var/lib/postgresql, which is what the 18+ images expect (they keep PGDATA in /var/lib/postgresql/18/docker). One comment explains why.
  • deploy/docker/postgres-init/01-create-databases.sql: the header comment named the old path.

Nothing else changes: same image, same volume name, same init script.

Verified

Fresh volume, Postgres service only, under a separate compose project so no other stack was touched:

  • origin/main: unhealthy, restarting, with the log above.
  • This branch: healthy. The init script ran (pg_trgm, pgcrypto, uuid-ossp are present in fsh), and the data directory is /var/lib/postgresql/18.

I also ran the whole compose stack with this mount (migrator, API, both front-ends), and it came up.

Existing volumes

An existing pg_data volume does not carry over through this change, and it could not before it either: a volume created by Postgres 17 or earlier has to be dumped and restored (or pg_upgraded) to run on 18, whatever the mount point. With this change, an old volume mounted at the new path is not read, and Postgres initializes a fresh cluster under 18/docker next to the old files. Nothing is deleted, but the database starts empty. Anyone upgrading should take the backup the README already describes before pulling this.

Docs

The changelog entry is in fullstackhero/docs#252.

postgres:18 keeps PGDATA under /var/lib/postgresql/18/docker and refuses a mount at /var/lib/postgresql/data even on an empty volume, so docker compose up restart-looped Postgres and never started the migrator or the API on a fresh machine.
@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

@iammukeshm

Copy link
Copy Markdown
Member

Thanks, verified — the 18+ image rejects the old mount even on an empty volume. Merging. We'll call out the empty-volume-on-upgrade note in the v10 release notes.

@iammukeshm
iammukeshm merged commit c6ccb81 into fullstackhero:main Sep 26, 2026
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants