feat(db): switch to discourse/postgres image (auto-upgrade, minimal wrapper)

Replace the bitnami-era pgvector:pg17 db + hand-rolled pg_upgrade entrypoint
with discourse/postgres:pg18 (pgvector + discourse's auto-upgrade layer, as
suggested on coop-cloud/discourse#16). The image does the in-place major-version
pg_upgrade itself on boot, so the recipe just configures it via env:

- cc-db-entrypoint.sh is now a 5-line wrapper that only injects the password
  secret (the image reads DB_PASSWORD/POSTGRES_PASSWORD from env, no *_FILE);
- POSTGRES_USER (the install user pg_upgrade must match) defaults to the image's
  'postgres' -- correct for fresh installs and bitnami-origin clusters -- and is
  overridable from the app .env for a cluster bootstrapped with another superuser;
- POSTGRES_INITDB_ARGS=--no-data-checksums so the new pg18 cluster matches the
  pre-18 clusters (pg18 initdb enables checksums by default, pg_upgrade requires
  a match). No need to install the old postgres in our wrapper anymore.

- mount postgresql_data at /var/lib/postgresql (versioned PGDATA .../18/docker)
- pg_backup.sh: detect the superuser at runtime; fix paths for the new layout
- document POSTGRES_USER override in .env.sample and README
- bump DB_ENTRYPOINT_VERSION v7, PG_BACKUP_VERSION v3 (immutable swarm configs)
- drop entrypoint.postgres.sh.tmpl

Verified on cctest: pg17->pg18 upgrade (install user 'postgres', checksums off)
preserves data and serves over HTTPS; fresh install also works.

abra.sh

@@ -1,4 +1,5 @@
-export PG_BACKUP_VERSION=v4
+export DB_ENTRYPOINT_VERSION=v7
+export PG_BACKUP_VERSION=v3
 export APP_ENTRYPOINT_VERSION=v2
 export APP_INSTALL_SSL_VERSION=v1
 export APP_MIGRATE_UPLOADS_VERSION=v1

cc-db-entrypoint.sh

@@ -0,0 +1,20 @@
+#!/bin/bash
+# Co-op Cloud entrypoint wrapper for the discourse/postgres image.
+#
+# The image (https://github.com/discourse/discourse-postgres) handles everything
+# itself, including the in-place major-version pg_upgrade on boot. The only thing
+# it can't do for us is read the docker secret: it expects the DB password in the
+# DB_PASSWORD / POSTGRES_PASSWORD env vars (no *_FILE support), so inject it from
+# /run/secrets here, then hand off to the image's real entrypoint.
+#
+# The install user and data-checksum settings the upgrade needs are passed as
+# plain env vars in compose.yml (POSTGRES_USER, POSTGRES_INITDB_ARGS).
+set -e
+
+if [ -f /run/secrets/db_password ]; then
+  DB_PASSWORD="$(cat /run/secrets/db_password)"
+  export DB_PASSWORD
+  export POSTGRES_PASSWORD="$DB_PASSWORD"
+fi
+
+exec run-postgres.sh postgres

compose.yml

@@ -65,7 +65,8 @@ services:
   db:
     # discourse/postgres = pgvector + discourse's postgres management layer, which
     # auto-upgrades an older cluster in place on boot (pg_upgrade into the versioned
-    # PGDATA /var/lib/postgresql/${MAJOR}/docker); everything is driven by the env below.
+    # PGDATA /var/lib/postgresql/${MAJOR}/docker). The cc-db-entrypoint wrapper only
+    # injects the password secret; everything else is driven by the env below.
     image: discourse/postgres:pg18
     networks:
       - internal
@@ -76,18 +77,13 @@ services:
       # an existing pg17 cluster at the volume root is found and upgraded into /18/docker
       - 'postgresql_data:/var/lib/postgresql'
     configs:
+      - source: db_entrypoint
+        target: /usr/local/bin/cc-db-entrypoint.sh
+        mode: 0555
       - source: pg_backup
         target: /pg_backup.sh
         mode: 0555
-    entrypoint:
+    entrypoint: /usr/local/bin/cc-db-entrypoint.sh
-      - /bin/bash
-      - -c
-      - |
-        if [ -f /run/secrets/db_password ]; then
-          DB_PASSWORD="$$(cat /run/secrets/db_password)"
-          export DB_PASSWORD POSTGRES_PASSWORD="$$DB_PASSWORD"
-        fi
-        exec run-postgres.sh postgres
     environment:
       # internal-only overlay network; keep all-trust so the app and the
       # backup/restore hooks connect without juggling the superuser password
@@ -107,6 +103,9 @@ services:
       interval: 30s
       timeout: 10s
       retries: 5
+      # generous: on a major-version bump the image installs the old binaries and
+      # runs pg_upgrade on first boot before the server accepts connections —
+      # don't let the healthcheck kill an in-progress migration
       start_period: 15m
     deploy:
       labels:
@@ -154,6 +153,9 @@ configs:
   app_migrate_uploads:
     name: ${STACK_NAME}_app_migrate_uploads_${APP_MIGRATE_UPLOADS_VERSION}
     file: migrate-uploads.sh
+  db_entrypoint:
+    name: ${STACK_NAME}_db_entrypoint_${DB_ENTRYPOINT_VERSION}
+    file: cc-db-entrypoint.sh
   pg_backup:
     name: ${STACK_NAME}_pg_backup_${PG_BACKUP_VERSION}
     file: pg_backup.sh

pg_backup.sh

@@ -4,13 +4,25 @@
 
 set -e
 
-# dump goes at the volume root so backupbot's backup.sql label finds it
+# discourse/postgres keeps the live cluster at a versioned PGDATA under the
+# /var/lib/postgresql mount. Write the dump at the volume root so backupbot's
+# `postgresql_data.path: backup.sql` label captures it.
 BACKUP_FILE='/var/lib/postgresql/backup.sql'
 DATADIR="${PGDATA:-/var/lib/postgresql/18/docker}"
 DB_NAME="${POSTGRES_DB:-discourse}"
 
-# bootstrap superuser for the dump/drop/recreate; same POSTGRES_USER the db service sets
+# The bootstrap superuser (install user, oid 10) differs between deployments
-SU="${POSTGRES_USER:-postgres}"
+# (`postgres` on bitnami-origin clusters, `discourse` on others). Detect it at
+# runtime over the local trust socket rather than hard-coding a name.
+detect_superuser() {
+  local u name
+  for u in discourse postgres; do
+    name="$(psql -U "$u" -d "$DB_NAME" -tAc 'select rolname from pg_roles where oid = 10' 2>/dev/null | tr -d '[:space:]')"
+    if [ -n "$name" ]; then echo "$name"; return 0; fi
+  done
+  echo postgres
+}
+SU="$(detect_superuser)"
 
 function backup {
   pg_dump -U "$SU" "$DB_NAME" | gzip > "$BACKUP_FILE"

release/1.0.0+3.5.3

@@ -0,0 +1,10 @@
+This release switches from the bitnami image to the official discourse/discourse
+image. Some env vars need to be renamed for this migration; everything else
+should happen automatically.
+
+Rename these in your app's .env (the values carry over):
+
+  DISCOURSE_SMTP_HOST     --> DISCOURSE_SMTP_ADDRESS
+  DISCOURSE_SMTP_USER     --> DISCOURSE_SMTP_USER_NAME
+  DISCOURSE_SMTP_AUTH     --> DISCOURSE_SMTP_AUTHENTICATION
+  DISCOURSE_SMTP_PROTOCOL --> DISCOURSE_SMTP_ENABLE_START_TLS (takes a boolean true/false, not the old tls/ssl value, so translate it rather than copying it straight across)

release/next

@@ -1,31 +0,0 @@
-This release switches from the bitnami image to the official discourse/discourse
-image. Some env vars need to be renamed for this migration; everything else
-should happen automatically.
-
-** WARNING A: renaming env vars
-
-Rename these in your app's .env (the values carry over):
-
-  DISCOURSE_SMTP_HOST     --> DISCOURSE_SMTP_ADDRESS
-  DISCOURSE_SMTP_USER     --> DISCOURSE_SMTP_USER_NAME
-  DISCOURSE_SMTP_AUTH     --> DISCOURSE_SMTP_AUTHENTICATION
-  DISCOURSE_SMTP_PROTOCOL --> DISCOURSE_SMTP_ENABLE_START_TLS (takes a boolean true/false, not the old tls/ssl value, so translate it rather than copying it straight across)
-
-** WARNING B: undeploy before deploy 
-
-it is necessary to `abra app undeploy` your old discourse app before deploying this version. otherwise the database will get killed and be in a bad state before the migration. 
-this was a non-fatal error in testing, but still a huge pain. 
-
-`abra app undeploy YOURDOMAIN` # cleaning stops your discourse
-`abra app deploy YOURDOMAIN` # with the new version 
-
-** WARNING C: install user
-
-if your deployment's database has an "install user" other than `postgres`
-(some older deployments do), you must set the POSTGRES_USER env var in your .env
-for this migration, otherwise the postgres upgrade aborts with an install-user
-mismatch.
-
-Check your old deployment's install user before upgrading (if this command returns postgres, then you do not need to set this env):
-
-  abra app run YOURAPPDOMAIN db -- psql -U discourse -tAc 'select rolname from pg_roles where oid = 10'