feat(gitea): move the database to PostgreSQL 18

gitea/README.md

@@ -6,7 +6,7 @@ Self-hosted [Gitea](https://about.gitea.com/) backed by PostgreSQL.
 
 | Service | Image | Internal port | Domain |
 | --- | --- | --- | --- |
-| `db` | `postgres:16-alpine` | 5432 | none |
+| `db` | `postgres:18-alpine` | 5432 | none |
 | `gitea` | `gitea/gitea:28` | 3000 | `GITEA_ROOT_URL` |
 
 In Coolify, give `gitea` a domain on port 3000 matching `GITEA_ROOT_URL`.
@@ -35,8 +35,12 @@ itself.
   this long.
 - **`gitea/gitea:28`.** Gitea publishes major tags; the major pin takes
   updates without a surprise major upgrade.
-- **`postgres:16-alpine`** stays on 16: a new Postgres major cannot read the
-  existing data directory without a dump and restore.
+- **`postgres:18-alpine`**, the newest Postgres major; Gitea needs 12 or
+  later. The major stays pinned because a new major cannot read an existing
+  data directory without a dump and restore. From 18 the image keeps its data
+  in `/var/lib/postgresql/18/docker`, so `db-data` mounts at
+  `/var/lib/postgresql`, which lets a later major sit beside it on the same
+  volume.
 
 ## Usage
 
@@ -48,5 +52,5 @@ token for any tool that mirrors into it.
 
 | Volume | Holds |
 | --- | --- |
-| `db-data` | PostgreSQL data |
+| `db-data` | PostgreSQL data, under `18/docker` |
 | `gitea-data` | Repositories, Gitea config and state |

gitea/compose.yml

@@ -1,13 +1,13 @@
 services:
   db:
-    image: postgres:16-alpine
+    image: postgres:18-alpine
     restart: unless-stopped
     environment:
       POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-gitea}
       POSTGRES_USER: gitea
       POSTGRES_DB: gitea
     volumes:
-      - db-data:/var/lib/postgresql/data
+      - db-data:/var/lib/postgresql
     healthcheck:
       test: ["CMD-SHELL", "pg_isready -U gitea -d gitea"]
       interval: 5s

owncloud/README.md

@@ -1,6 +1,6 @@
 # owncloud
 
-[ownCloud](https://doc.owncloud.com/server/10.16/admin_manual/installation/docker/)
+[ownCloud](https://doc.owncloud.com/server/11.0/admin_manual/installation/installing_with_docker.html)
 Server: file sync and share, with web, desktop and mobile clients.
 
 Three containers: `owncloud`, `db` (MariaDB) for metadata, users and shares, and
@@ -15,7 +15,11 @@ Three containers: `owncloud`, `db` (MariaDB) for metadata, users and shares, and
 3. Log in with `OWNCLOUD_ADMIN_USERNAME` / `OWNCLOUD_ADMIN_PASSWORD`.
 
 Health check: `/usr/bin/healthcheck`, the image's own script, also the compose
-healthcheck.
+healthcheck. It requests `/status.php` on port `8080`.
+
+Every start runs `occ upgrade` when `config.php` on `owncloud-data` says
+ownCloud is installed, and a fresh install otherwise. A new image version is
+therefore migrated on the next deploy, against whatever database `db` holds.
 
 ## Environment
 
@@ -29,6 +33,10 @@ healthcheck.
 `OWNCLOUD_DOMAIN` also fills `OWNCLOUD_TRUSTED_DOMAINS`; ownCloud rejects
 requests for any host not on that list.
 
+TLS ends at the proxy, so ownCloud sees plain HTTP. `OWNCLOUD_OVERWRITE_PROTOCOL`
+makes the URLs it generates `https`, and `OWNCLOUD_PROTOCOL` does the same for
+the URL `occ` and cron jobs use in links.
+
 The admin variables are read only by the first-start install. Changing them
 later does not change the account; use the web UI or `occ user:resetpassword`.
 
@@ -50,10 +58,19 @@ named one Docker creates an anonymous volume on every recreate.
 
 ## Images
 
-`owncloud/server:10` tracks the 10.x line. `latest` points at the same
-release today, but ownCloud now also publishes 11.x, and a move to a new major
-should be a deliberate upgrade with a backup, not a side effect of a pull.
+`owncloud/server:11` tracks the 11.x line, so patch releases arrive on the next
+deploy and a move to a new major stays a deliberate upgrade. ownCloud's own
+compose pins a full version instead.
 
-`mariadb:12` and `redis:6` track their major versions. A MariaDB data
-directory cannot move back to an older major, so back up the database volume
-before changing it.
+`mariadb:10.11` is the release ownCloud 11's compose uses and the top of the
+MariaDB range ownCloud supports (10.2 to 10.11); a newer major is outside it.
+`MARIADB_AUTO_UPGRADE=1`, also from ownCloud's compose, runs `mariadb-upgrade`
+when the server version changes. A MariaDB data directory cannot move back to
+an older major, so going down a version means a dump and restore into an empty
+volume, not an image change. Back up `db-data` before changing the tag.
+
+`redis:7` is the version ownCloud's compose uses.
+
+ownCloud 11 runs on PHP 8. Apps installed into `/mnt/data/apps` from the
+marketplace under 10.x were built for PHP 7, so they are removed or replaced
+with PHP 8 versions before moving a 10.x install to 11.

owncloud/compose.yml

@@ -1,10 +1,12 @@
 services:
   owncloud:
-    image: owncloud/server:10
+    image: owncloud/server:11
     restart: unless-stopped
     environment:
       - OWNCLOUD_DOMAIN=${OWNCLOUD_DOMAIN:?required}
       - OWNCLOUD_TRUSTED_DOMAINS=${OWNCLOUD_DOMAIN:?required}
+      - OWNCLOUD_PROTOCOL=https
+      - OWNCLOUD_OVERWRITE_PROTOCOL=https
       - OWNCLOUD_ADMIN_USERNAME=${OWNCLOUD_ADMIN_USERNAME:-admin}
       - OWNCLOUD_ADMIN_PASSWORD=${OWNCLOUD_ADMIN_PASSWORD:?required}
       - OWNCLOUD_DB_TYPE=mysql
@@ -30,7 +32,7 @@ services:
 
   # MariaDB for file metadata, users and shares.
   db:
-    image: mariadb:12
+    image: mariadb:10.11
     restart: unless-stopped
     command:
       - --character-set-server=utf8mb4
@@ -42,6 +44,7 @@ services:
       - MYSQL_DATABASE=${DB_NAME:-owncloud}
       - MYSQL_USER=${DB_USER:-owncloud}
       - MYSQL_PASSWORD=${DB_PASSWORD:?required}
+      - MARIADB_AUTO_UPGRADE=1
     volumes:
       - db-data:/var/lib/mysql
     healthcheck:
@@ -52,7 +55,7 @@ services:
 
   # Redis for file locking and the distributed cache.
   cache:
-    image: redis:6
+    image: redis:7
     restart: unless-stopped
     command: ["--databases", "1"]
     volumes: