chore: merge upstream main into the upgrade branch

The branch predated the official-image migration (coop-cloud/discourse#16), so its
merge-base was 0.8.1+3.5.0 and the PR's file list re-showed that migration's changes
as if this PR introduced them. The branch TREE already matched upstream; only its
history lacked those commits. Recording the merge leaves the PR's diff as what it
actually changes: app 3.5.3 -> 2026.7.1 and redis 7.4-alpine -> 8.10-alpine.

Conflict in compose.yml resolved in favour of the branch (both sides edited the same
image lines; the branch already carries upstream's official-image switch plus the
version bumps). Resulting tree is byte-identical to the pre-merge branch tree.

.env.sample

@@ -21,3 +21,9 @@ DISCOURSE_DEVELOPER_EMAILS=admin@example.com
 #SECRET_SMTP_PASSWORD_VERSION=v1
 
 SECRET_DB_PASSWORD_VERSION=v1
+
+# Postgres bootstrap superuser (the cluster's "install user"). Defaults to
+# `postgres`, which matches fresh installs and bitnami-origin clusters. Only set
+# this if you are upgrading a cluster that was bootstrapped with a different
+# superuser (e.g. `discourse`) — a postgres major upgrade fails unless it matches.
+#POSTGRES_USER=postgres

README.md

@@ -43,6 +43,22 @@ override) so it works behind the reverse proxy.
 abra app run YOURAPPDOMAIN app discourse admin create
 ```
 
+## Postgres major version upgrades
+
+Handled automatically by the [`discourse/postgres`] image (pgvector + an
+auto-upgrade layer). On deploy it finds an older cluster, installs the old
+binaries and runs `pg_upgrade` into the new versioned data directory. No manual
+dump/restore needed.
+
+`pg_upgrade` must run as the old cluster's bootstrap superuser (its "install
+user"). The recipe uses `POSTGRES_USER`, which defaults to `postgres` — the right
+value for fresh installs and for clusters that came from the old bitnami recipe.
+If your cluster was bootstrapped with a different superuser (e.g. `discourse`),
+set `POSTGRES_USER` in the app `.env` before upgrading, otherwise `pg_upgrade`
+will refuse with an install-user mismatch.
+
+[`discourse/postgres`]: https://github.com/discourse/discourse-postgres
+
 ## Migrating from the previous (bitnami) recipe
 
 The official image stores uploads under `/shared` rather than bitnami's

abra.sh

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

cc-db-entrypoint.sh

@@ -1,35 +0,0 @@
-#!/bin/bash
-# Co-op Cloud wrapper around pgautoupgrade's entrypoint.
-#
-# pgautoupgrade runs pg_upgrade assuming the old cluster's bootstrap superuser
-# (the "install user", oid 10) equals $POSTGRES_USER. That is not always true
-# (e.g. a cluster bootstrapped with the default "postgres" superuser and a
-# separate "discourse" app role), and a mismatch makes pg_upgrade's consistency
-# check fail (pgautoupgrade issue #115). When a major-version upgrade is pending,
-# detect the old cluster's real install user and run the upgrade as that user;
-# pgautoupgrade handles everything else (old binaries, initdb, pg_upgrade).
-set -e
-
-if [ -s "$PGDATA/PG_VERSION" ]; then
-  OLD_VERSION="$(cat "$PGDATA/PG_VERSION")"
-  TARGET_VERSION="${PGTARGET%%.*}"
-
-  if [ -n "$OLD_VERSION" ] && [ -n "$TARGET_VERSION" ] && [ "$OLD_VERSION" != "$TARGET_VERSION" ]; then
-    # query the old cluster in single-user mode (no socket/auth needed) with
-    # pgautoupgrade's bundled old-version binaries
-    OLD_POSTGRES="/usr/local-pg${OLD_VERSION}/bin/postgres"
-    if [ -x "$OLD_POSTGRES" ]; then
-      INSTALL_USER="$(echo 'select rolname from pg_authid where oid = 10;' \
-        | gosu postgres "$OLD_POSTGRES" --single -D "$PGDATA" template1 2>/dev/null \
-        | sed -n 's/.*rolname = "\([^"]*\)".*/\1/p' | head -n1)"
-      if [ -n "$INSTALL_USER" ]; then
-        echo "cc-db-entrypoint: old cluster (pg$OLD_VERSION) install user is '$INSTALL_USER'; running the pg$TARGET_VERSION upgrade as that user"
-        export POSTGRES_USER="$INSTALL_USER"
-      else
-        echo "cc-db-entrypoint: WARNING could not detect old install user; letting pgautoupgrade use POSTGRES_USER=$POSTGRES_USER"
-      fi
-    fi
-  fi
-fi
-
-exec /usr/local/bin/docker-entrypoint.sh "$@"

compose.yml

@@ -3,7 +3,7 @@ version: "3.8"
 
 services:
   app:
-    image: discourse/discourse:3.5.3
+    image: discourse/discourse:2026.7.1
     networks:
       - proxy
       - internal
@@ -63,39 +63,51 @@ services:
       start_period: 25m
 
   db:
-    image: pgautoupgrade/pgautoupgrade:17-trixie
+    # 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.
+    image: discourse/postgres:pg18
     networks:
       - internal
     secrets:
       - db_password
     volumes:
-      - 'postgresql_data:/var/lib/postgresql/data'
+      # the image expects the whole cluster tree mounted here (not the data subdir);
+      # 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: /usr/local/bin/cc-db-entrypoint.sh
-    # overriding entrypoint drops the image's default CMD, so restore it; the
-    # wrapper passes "$@" through and pgautoupgrade keys its logic on $1=postgres
-    command: postgres
+    entrypoint:
+      - /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
       - POSTGRES_HOST_AUTH_METHOD=trust
-      - POSTGRES_USER=discourse
       - POSTGRES_DB=discourse
-      - POSTGRES_PASSWORD_FILE=/run/secrets/db_password
-      - PGTARGET=17
+      - DB_USER=discourse
+      # pg_upgrade runs as this role and initdb's the new cluster with it; it must
+      # match the OLD cluster's bootstrap superuser (oid 10). The image default
+      # `postgres` matches fresh installs and bitnami-origin clusters. Override in
+      # the app .env (POSTGRES_USER=...) only for a cluster bootstrapped differently.
+      - POSTGRES_USER=${POSTGRES_USER:-postgres}
+      # pg18's initdb enables data checksums by default, but pg13-17 clusters here
+      # have them off and pg_upgrade requires a match -> initialise without them.
+      - POSTGRES_INITDB_ARGS=--no-data-checksums
     healthcheck:
       test: "pg_isready -U discourse -d discourse"
       interval: 30s
       timeout: 10s
       retries: 5
-      # generous: pgautoupgrade may run an in-place pg_upgrade on deploy before
-      # the server accepts connections — don't let the healthcheck kill an
-      # in-progress migration
-      start_period: 10m
+      start_period: 15m
     deploy:
       labels:
         backupbot.backup: "true"
@@ -104,7 +116,7 @@ services:
         backupbot.restore.post-hook: "/pg_backup.sh restore"
 
   redis:
-    image: redis:7.4-alpine
+    image: redis:8.10-alpine
     networks:
       - internal
     volumes:
@@ -142,9 +154,6 @@ 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

@@ -1,44 +1,47 @@
 #!/bin/bash
 
-# Postgres backup/restore hook for the discourse `db` service.
+# Postgres backup/restore hook for the discourse `db` service (discourse/postgres image).
 
 set -e
 
-BACKUP_FILE='/var/lib/postgresql/data/backup.sql'
-export PGPASSWORD=$(cat "${POSTGRES_PASSWORD_FILE:-/run/secrets/db_password}")
-DB_USER="${POSTGRES_USER:-discourse}"
+# dump goes at the volume root so backupbot's backup.sql label finds 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
+SU="${POSTGRES_USER:-postgres}"
+
 function backup {
-  pg_dump -U "$DB_USER" "$DB_NAME" | gzip > "$BACKUP_FILE"
+  pg_dump -U "$SU" "$DB_NAME" | gzip > "$BACKUP_FILE"
 }
 
 function restore {
-  cd /var/lib/postgresql/data/
+  cd "$DATADIR"
 
   # Block all non-local connections so the running discourse app + sidekiq cannot reconnect and
   # interfere with the drop/recreate/reimport. Restored on exit.
   restore_hba() {
     cat pg_hba.conf.bak > pg_hba.conf
     rm -f pg_hba.conf.bak
-    su postgres -c 'pg_ctl reload'
+    su postgres -c "pg_ctl -D '$DATADIR' reload"
   }
   cp pg_hba.conf pg_hba.conf.bak
   echo 'local all all trust' > pg_hba.conf
-  su postgres -c 'pg_ctl reload'
+  su postgres -c "pg_ctl -D '$DATADIR' reload"
   trap restore_hba EXIT INT TERM
 
   # terminate any lingering local sessions before recreate
   # see https://stackoverflow.com/questions/5108876/kill-a-postgresql-session-connection
-  psql -U "$DB_USER" -d postgres -c \
+  psql -U "$SU" -d postgres -c \
     "SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname='${DB_NAME}' AND pid<>pg_backend_pid();"
 
   # drop database and then recreate it
-  psql -U "$DB_USER" -d postgres -c "DROP DATABASE ${DB_NAME} WITH (FORCE);"
-  createdb -U "$DB_USER" "$DB_NAME"
+  psql -U "$SU" -d postgres -c "DROP DATABASE ${DB_NAME} WITH (FORCE);"
+  createdb -U "$SU" "$DB_NAME"
 
-  # reimport data 
-  gunzip -c "$BACKUP_FILE" | psql -U "$DB_USER" -d "$DB_NAME" -1 -v ON_ERROR_STOP=1 -f -
+  # reimport data
+  gunzip -c "$BACKUP_FILE" | psql -U "$SU" -d "$DB_NAME" -1 -v ON_ERROR_STOP=1 -f -
 }
 
 $@

release/1.0.0+3.5.3

@@ -1,10 +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.
-
-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

@@ -0,0 +1,31 @@
+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'