v1.1.0 — backups that report failure

Fixed

A failed database dump no longer produces a silent, corrupt backup. The old loop piped the dump into gzip and only checked gzip's exit status, so a dump that failed halfway (database down, wrong password, disk full) still left a small .gz that looked like a backup. The loop now runs with pipefail, logs Database backup OK: <file> (<bytes> bytes) or Database backup FAILED per cycle, keeps a failed dump as <file>.failed for diagnosis, and prunes only its own files. Retention 0 disables pruning instead of deleting everything.

Added

CI now waits for the first backup cycle and proves the produced archive is readable and carries a real dump header (plus a readable tar.gz for the data backup where the stack has one).

Upgrading

git pull and docker compose up -d (only the backups container is recreated). Existing backup files are untouched and keep their names. Point your monitoring at the backups container log: a FAILED line is the signal.

Full details in CHANGELOG.md.

v1.0.0 — fleet standard: Zabbix 7.0 LTS, untracked credentials, CI verification

First semver release, and a security-significant one. Read the upgrade section before pulling into an existing deployment.

What changed

• Credentials are no longer in git. This repository used to ship a tracked .env with a generated-looking database password. If you deployed without changing it, rotate ZABBIX_DB_PASSWORD now. Going forward .env is gitignored, .env.example documents every value with generation commands, and compose fails fast when a required secret is unset.
• Zabbix 6.4.6 → 7.0.30 LTS (server, web, agent2 move together). The 6.4 line has been end-of-life since 2024-12-31 with no security updates; 7.0 is the LTS line supported until 2029.
• Traefik 3.2 → 3.7. Traefik 3.2's Docker client cannot talk to Docker Engine 29: the docker provider fails in a retry loop and the stack silently serves 404s on current hosts.
• All five images pinned by tag@sha256:digest as interpolation defaults in the compose file's x-images block — git pull alone delivers the tested version combination, and .env carries only secrets and deliberate overrides.
• CI now proves the configuration works. Every push and a weekly cron run linters, Trivy scans, a freshness check (digest drift, LTS-line currency via endoflife.date, Traefik release lag), and a full docker compose up that requires the zabbix-server healthcheck and a working web API (apiinfo.version) through Traefik.

How to upgrade an existing deployment

1. Back up the database first (pg_dump); there is no downgrade path other than restoring it.
2. Keep your existing .env (it is untracked now) and git pull.
3. docker compose -f zabbix-traefik-letsencrypt-docker-compose.yml -p zabbix pull && docker compose -f zabbix-traefik-letsencrypt-docker-compose.yml -p zabbix up -d — the server migrates the database schema from 6.4 to 7.0 automatically on first start. Expect a longer first boot on large databases.
4. Delete any *_IMAGE_TAG lines from your .env to switch to repo-managed versions, and rotate the database password if it came from the old tracked file.

Fresh deployments: copy .env.example to .env, fill in the required values, docker compose up -d.

Validated before release: server healthy on 7.0.30, apiinfo.version answers through Traefik, backup cycle produces gunzip-tested dumps, and the same checks run in CI on every push.

Full changelog: https://github.com/heyvaldemar/zabbix-traefik-letsencrypt-docker-compose/blob/main/CHANGELOG.md