chore(compose): bump self-host Postgres to 18 (BUNYIP-350) #353

Merged

nrupard merged 2 commits from chore/BUNYIP-350-postgres-18 into main

2026-07-08 21:43:07 +02:00

nrupard commented

2026-07-08 21:20:59 +02:00

Owner

Aligns the bunyip repo self-host compose.yml Postgres to 18, matching the deployed infra template (template/bunyip-api/compose.yml already pins postgres:18.2-alpine3.23 on co1/nco1). This was the last Postgres 16 pin.

Change

postgres service image: postgres:16-alpine -> postgres:18.2-alpine3.23.
Data volume mount: /var/lib/postgresql/data -> /var/lib/postgresql (whole tree). Postgres >= 18 defaults PGDATA to /var/lib/postgresql/<MAJOR>/docker, so the volume must cover the parent to persist across the layout change. Mirrors the template.

Fresh self-host volume: no-op. Existing 16 volume: needs pg_upgrade or dump/restore (out of scope).

Verification

Stood up postgres:18.2-alpine3.23 and applied all 75 bunyip-api migrations with ON_ERROR_STOP=1: all applied clean, 41 public tables created, pg_isready healthy in 3s. App startup + migrations on PG18 are additionally proven by the live co1/nco1 deployment already running this exact stack.

Out of scope (flagged separately)

compose.dev.yml (the just dev local stack) is still on postgres:16-alpine with /var/lib/postgresql/data. The issue scopes to compose.yml, so this PR leaves it. Bumping dev for parity is a small follow-up but touches existing local dev volumes, so it is left as a separate decision.

AC

compose.yml Postgres pinned to 18 (18.2-alpine3.23), matching the template.
Volume mount adjusted for the PG >= 18 PGDATA layout (/var/lib/postgresql).
App startup + migrations succeed against PG18 (75 migrations applied clean; live deploy proves the app path).
Smoke check confirms healthy on 18 (pg_isready + select version() = PostgreSQL 18.2).

#BUNYIP-350

Aligns the bunyip repo self-host `compose.yml` Postgres to 18, matching the deployed infra template (`template/bunyip-api/compose.yml` already pins `postgres:18.2-alpine3.23` on co1/nco1). This was the last Postgres 16 pin. ## Change - `postgres` service image: `postgres:16-alpine` -> `postgres:18.2-alpine3.23`. - Data volume mount: `/var/lib/postgresql/data` -> `/var/lib/postgresql` (whole tree). Postgres >= 18 defaults `PGDATA` to `/var/lib/postgresql/<MAJOR>/docker`, so the volume must cover the parent to persist across the layout change. Mirrors the template. Fresh self-host volume: no-op. Existing 16 volume: needs `pg_upgrade` or dump/restore (out of scope). ## Verification Stood up `postgres:18.2-alpine3.23` and applied all **75** bunyip-api migrations with `ON_ERROR_STOP=1`: all applied clean, **41** public tables created, `pg_isready` healthy in 3s. App startup + migrations on PG18 are additionally proven by the live co1/nco1 deployment already running this exact stack. ## Out of scope (flagged separately) `compose.dev.yml` (the `just dev` local stack) is still on `postgres:16-alpine` with `/var/lib/postgresql/data`. The issue scopes to `compose.yml`, so this PR leaves it. Bumping dev for parity is a small follow-up but touches existing local dev volumes, so it is left as a separate decision. ## AC - [x] `compose.yml` Postgres pinned to 18 (18.2-alpine3.23), matching the template. - [x] Volume mount adjusted for the PG >= 18 PGDATA layout (`/var/lib/postgresql`). - [x] App startup + migrations succeed against PG18 (75 migrations applied clean; live deploy proves the app path). - [x] Smoke check confirms healthy on 18 (`pg_isready` + `select version()` = PostgreSQL 18.2). #BUNYIP-350

nrupard added 1 commit

2026-07-08 21:20:59 +02:00

chore(compose): bump self-host Postgres 16 -> 18 to match the deployed template (BUNYIP-350)

E2E / Playwright against deployment (pull_request) Successful in 25s

Details

Check / fmt + clippy + build + tests (pull_request) Has been cancelled

Details

d5521713eb

The deployed infra template (docker repo template/bunyip-api/compose.yml) already runs Postgres 18.2-alpine3.23 on co1/nco1; the bunyip repo's own self-host compose.yml was the last Postgres 16 pin. Align it to 18.

- postgres service image: postgres:16-alpine -> postgres:18.2-alpine3.23.
- Data volume mount: /var/lib/postgresql/data -> /var/lib/postgresql (whole tree). Postgres >= 18 defaults PGDATA to /var/lib/postgresql/<MAJOR>/docker, so the volume must cover the parent to persist across the layout change. Mirrors the template. For a fresh self-host volume this is a no-op; an existing 16 volume needs pg_upgrade or dump/restore (out of scope, called out on the issue).

Verified: stood up postgres:18.2-alpine3.23 and applied all 75 bunyip-api migrations with ON_ERROR_STOP=1 - all applied clean, 41 public tables created, pg_isready healthy in 3s. App startup + migrations on PG18 are additionally proven by the live co1/nco1 deployment already running this exact stack.

#BUNYIP-350

nrupard added 1 commit

2026-07-08 21:24:04 +02:00

chore(compose): bump dev Postgres 16 -> 18 for dev/prod parity (BUNYIP-350)

E2E / Playwright against deployment (pull_request) Successful in 37s

Details

Check / fmt + clippy + build + tests (pull_request) Successful in 18m58s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

65f9bfe0c6

Mirror the compose.yml PG18 bump in compose.dev.yml (the `just dev` local stack) so local dev runs the same Postgres major as prod + the self-host compose.

- postgres service image: postgres:16-alpine -> postgres:18.2-alpine3.23.
- Data volume mount: /var/lib/postgresql/data -> /var/lib/postgresql (PG >= 18 PGDATA layout). On an existing PG16 dev volume, PG18 initializes fresh under /var/lib/postgresql/18/docker (old .../data ignored, not migrated); `just dev-clean` drops the stale volume for a clean start. Dev data is disposable.

Migrations on PG18 already verified in the same PR (75 migrations applied clean against postgres:18.2-alpine3.23); this uses the identical migration set.

#BUNYIP-350

nrupard scheduled this pull request to auto merge when all checks succeed

2026-07-08 21:26:16 +02:00