v2.0.7

Fixed

• A restore onto a new server brought Nextcloud back unable to reach its own database. The installer creates a dedicated database account (oc_<admin>) with a random password and writes it into config.php; pg_dump saves the data, not the server's accounts. On a rebuilt host the empty stack's installer creates that account again with a different password, the restore brings back the old config.php, and every request answers 500 with password authentication failed for user "oc_admin". Restores on the same host never showed it, because there the account already had the right password; a weekly restore onto a machine that had never run the stack did. Both restore scripts now bring the database in line with config.php after they run, as the installer would: the account exists, takes the password config.php holds, and owns the database.

v2.0.6

Fixed

• The restore scripts had never been run by CI, and could not have been.
  They carried the database name, user and backup directory as literals, found
  their containers with a name filter that misses them under any -p but the
  default. The data restore ran docker exec -it, which refuses to start
  without a terminal, and cleared the directory with rm -rf dir/*, which
  leaves every dotfile of the newer state in place. Both scripts now take every
  path, name and credential from the running backups container, accept the
  backup file name as an argument, stop the application while they work and
  start it again whatever happens, and CI runs them: a marker written after a
  backup must be gone once that backup is restored, for the database and for
  the application data.

v2.0.5

Fixed

• Background jobs stopped after a host reboot. The nextcloud-cron sidecar had no restart policy, so after a reboot or a crash the web interface came back and the cron runner did not: file scans, cleanup and notifications stopped without an error anywhere. It now restarts like every other service.

Changed

• The freshness check has its own workflow, Pin Freshness. It ran inside Deployment Verification, whose badge is the one at the top of this README. Across the fleet, nine red runs in ten were a pin one version behind - which the fleet's triage moves within the day - and a reader cannot tell that from a stack that does not boot. The badge now says whether the stack boots. The job itself is unchanged.

v2.0.4

Security

• traefik:3.7 was rebuilt upstream; the pin moved from sha256:1c32e7c36820… to sha256:24841fe2de73…. Same version, same tag, a rebuilt base image — the usual shape of a security fix in a base layer.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

v2.0.3

Security

• nextcloud:35.0.0 was rebuilt upstream; the pin moved from sha256:c341e809df59… to sha256:23c101539e29…. Same version, same tag, a rebuilt base image — the usual shape of a security fix in a base layer.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

v2.0.2

Security

• redis:7.4 was rebuilt upstream; the pin moved from sha256:71da9275c5f3… to sha256:c6eabf748fc7…. Same version, same tag, a rebuilt base image — the usual shape of a security fix in a base layer.
• postgres:16 was rebuilt upstream; the pin moved from sha256:f1c3376c26f2… to sha256:a3b7f434b2dc…. Same version, same tag, a rebuilt base image — the usual shape of a security fix in a base layer.
• nextcloud:35.0.0 was rebuilt upstream; the pin moved from sha256:3e9f6eaa5dc8… to sha256:c341e809df59…. Same version, same tag, a rebuilt base image — the usual shape of a security fix in a base layer.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

v2.0.1

Security

• traefik:3.7 was rebuilt upstream; the pin moved from sha256:f86a2cab1b5c… to sha256:1c32e7c36820…. Same version, same tag, a rebuilt base image — the usual shape of a security fix in a base layer.
• nextcloud:35.0.0 was rebuilt upstream; the pin moved from sha256:901b85afe28d… to sha256:3e9f6eaa5dc8…. Same version, same tag, a rebuilt base image — the usual shape of a security fix in a base layer.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

v2.0.0

Changed

• Nextcloud 35. A major upstream release, and a one-way one.

  First boot of the new image runs occ upgrade on the database, and there
  is no path back to 34 once it completes. That is the whole of the
  disruption, and it is why this is a major here rather than a minor. The
  backups service in this stack takes the database and data volumes; confirm
  a recent one exists before pulling this on a live deployment, because that
  backup is the only way back.

  What was checked rather than assumed: Nextcloud's own system requirements for
  35 list PostgreSQL 14 through 18, so the postgres:16 this template pins is
  inside the supported window and does not move. PHP lives inside the official
  image and is not this template's concern. 34 to 35 is one major step, which
  is the only kind of step Nextcloud supports. The upstream review could not
  read release notes for the range and said so rather than guessing; the deploy
  job booted the stack on nextcloud:35.0.0 and answered over HTTPS before
  this landed.

  After the upgrade, Settings → Administration → Overview may ask for
  occ db:add-missing-indices or occ maintenance:repair. Run what it asks
  for.

Upgrading

git pull (or ./update.sh), then docker compose up -d. This time the database is migrated in place on first boot and there is no way back to 34. Confirm a recent backup exists under the backups service before pulling this on a live deployment. .env is untouched.

This release was cut after the deploy job booted the whole stack on nextcloud:35.0.0 on the pull request and answered over HTTPS, and after Nextcloud's own system requirements for 35 were checked for the PostgreSQL this template pins.

Full history in CHANGELOG.md.

v1.7.1

A correctness fix to the backup loop, and it is worth reading even if the symptom never reached you.

The archive is read back before it is called a backup

The library tarball was renamed into place on tar's exit code alone. That code has never been a statement about whether the file it produced opens, and the gap is not theoretical: an archive truncated after tar had already exited still carries exit status 0. The old condition promoted it, logged Data backup OK, and pruned older archives around it.

Measured in the image this sidecar actually runs, rather than argued from the manual:

case	tar's exit code	old condition	with the read-back
a good archive	0	promoted	promoted
destination blocked by a directory	2	refused	refused
archive truncated after tar exited	0	promoted	refused

One tar -tzf between the write and the rename now decides it.

What is deliberately not changed

The database dump. It is written as pg_dump \| gzip > f.partial under set -o pipefail, where a failure at either end of the pipe — including a full disk — already fails the pipeline and nothing is renamed. Adding gzip -t there would be noise, not safety.

How it was found

A rule was added to fleet-ops asserting this property across every repository, after one loop turned out to be missing it. Eighteen were, all with the same shape, all fixed in the same batch.

Upgrading

./update.sh

No variables changed, no data touched, no manual step.

v1.7.0

Added

• update.sh: move between release tags on purpose. It updates to the latest release (a combination this repository's CI has booted and smoke-tested), refuses to cross a major version unattended, refuses to run over local changes, and names any new required variable before anything has moved. --dry-run says what would happen.

Upgrading

git pull (or ./update.sh). Nothing running changes: this release adds or extends the update script and touches no image pin.

Full history in CHANGELOG.md.