v1.8.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.

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.

v1.8.5

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.

v1.8.4

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.
• mariadb:11.4 was rebuilt upstream; the pin moved from sha256:65ad406b90f2… to sha256:70cc072b29b4…. 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.

v1.8.3

Security

• mariadb:11.4 was rebuilt upstream; the pin moved from sha256:80494b981069… to sha256:65ad406b90f2…. 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.

v1.8.2

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.8.1

Security

• mariadb:11.4 was rebuilt upstream; the pin moved from sha256:611a2fcc5fa7… to sha256:80494b981069…. 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.

v1.8.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.

v1.7.0

Fixed

• A backup interrupted halfway no longer looks like a good one. The loop
  already renamed a failed dump to .failed so nothing would restore from it,
  but that rename only runs if the shell lives long enough to reach it. Stop
  the container mid-dump and it does not: the truncated file keeps the name a
  finished backup would have, and it is the newest one, which is exactly what
  the restore script and the end-to-end test pick. Every backup is now written
  to <name>.partial and renamed only after the dump succeeds, so the real
  name never exists unless the file behind it is complete. Verified by killing
  a dump in flight: before, the restore path selected a file that failed
  gzip -t; after, it finds nothing to select.

v1.6.0

Added

• A shutdown grace period for MariaDB. Docker stops a container with
  SIGTERM and ten seconds, then SIGKILL. That default is not always enough:
  PostgreSQL has a checkpoint to write, MariaDB has InnoDB to flush, and Redis
  saves its dataset on the way out. Killed halfway, the next start does crash
  recovery, and a Redis holding another application's file locks leaves them
  behind for a person to clear by hand. Sixty seconds now, overridable per
  service with <PREFIX>_STOP_GRACE_PERIOD in .env. The backup sidecar is
  deliberately left alone: its failure mode is a truncated dump file, which a
  longer grace period does not fix.

v1.5.0

Added

• Per-image version overrides. Every pin in the x-images block is
  now ${<PREFIX>_IMAGE_TAG:-repo:${<PREFIX>_IMAGE_VERSION:-tag@sha256:digest}}.
  Set <PREFIX>_IMAGE_VERSION in .env to run a different version of one
  image while every other pin stays as tested (Compose pulls that tag
  without a digest), or <PREFIX>_IMAGE_TAG to replace the whole
  reference as before. A deployment that sets neither is unchanged. The
  freshness job, the Trivy matrix and the fleet digest automation resolve
  the nested default before reading a pin. Needs Docker Compose v2.5 or
  newer (2022): v2.0 to v2.4 leave the inner ${...} unexpanded and
  docker compose up fails with an invalid reference instead of
  deploying something unexpected.

Upgrading

git pull (or ./update.sh). A deployment that sets no _IMAGE_VERSION or _IMAGE_TAG variable renders exactly the same image references as before, so docker compose up -d recreates nothing. Requires Docker Compose v2.5 or newer.

Full history in CHANGELOG.md.