v1.9.2

Security

• postgres:15 was rebuilt upstream; the pin moved from sha256:dfbbb0ad8cab… to sha256:724292da1f2e…. 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.9.1

Fixed

• CI had never run the restore script. It carried the database name, user
  and backup directory as literals, wrong for any .env that sets them
  differently, and found its containers with a name filter that misses them
  under any -p but the default. It now takes every path, name and credential
  from the running backups container, accepts the backup file name as an
  argument, stops the application while it works and starts it again whatever
  happens, and CI runs it: a marker written after a backup must be gone once
  that backup is restored.

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

Changed

• Zabbix 7.0.30 moved to 7.0.31 across the server, web and agent images, with
  fresh digests. The freshness check found the lag and could not fix it on its
  own, and the reason turned out not to be the one first written here: the check
  reports is behind its line: pinned 7.0.30, latest in 7.0 is 7.0.31, and the
  triage that acts on these alarms read one other wording of that sentence.
  Measured across the fleet afterwards, fifty-one alarms matched that wording and
  fifty-one did not, every Traefik pin among them. The parsing was fixed in
  fleet-ops, so the next lag here moves on its own.

  Asked of the registry rather than of release notes, the three images differ
  from their predecessors in one field each — ZBX_VERSION 7.0.30 -> 7.0.31
  — and in nothing else: same user, entrypoint, command, ports, volumes and
  healthcheck. 7.0 stays the pinned line, which is supported until 2027.

v1.8.1

Security

• postgres:15 was rebuilt upstream; the pin moved from sha256:9b1d34adbce1… to sha256:dfbbb0ad8cab…. 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 PostgreSQL. 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.

v1.4.0

Security

• Container hardening. Every service runs with
  security_opt: no-new-privileges:true (no privilege escalation via
  setuid binaries even if a process escapes its initial capability
  set). Infrastructure containers (the reverse proxy, databases,
  caches, backups) drop every Linux capability and add back only what
  their entrypoints need (bind :80/:443, chown a data directory, drop to
  the service user). Application containers keep the default capability
  set: upstream images assume it, and a wrong guess there is a boot loop
  in production, not a hardening win. CI boots the stack under these
  settings on every push.

Upgrading

git pull and docker compose up -d (or ./update.sh). Containers are recreated once with the new security settings; data volumes are untouched.

Full history in CHANGELOG.md.

v1.3.0 — resource limits you can tune from .env

Added

Resource limits on every service, as .env-overridable defaults. Each service now carries memory and CPU limits plus reservations (<SERVICE>_MEMORY_LIMIT, _CPU_LIMIT, _MEMORY_RESERVATION, _CPU_RESERVATION; the knobs and their defaults are listed in .env.example). Set any of them in .env and the override survives every git pull.

The defaults are what CI boots the stack under, so they are known to be enough for a fresh install. Under real load, a service that is OOM-killed shows OOMKilled=true in docker inspect — raise its _MEMORY_LIMIT and recreate.

Upgrading

git pull and docker compose up -d (containers are recreated with the new limits). If you already run on a small host and a service gets killed, set a higher limit in .env before recreating.

Full details in CHANGELOG.md.