v1.7.0

Added

• Traefik's timeouts on the HTTPS entry point can be set from .env.
  TRAEFIK_READ_TIMEOUT, TRAEFIK_WRITE_TIMEOUT and TRAEFIK_IDLE_TIMEOUT
  default to Traefik's own values (60s, 0s, 180s), so nothing changes unless
  you set them. Traefik reads its static configuration from one source, here
  the command in the compose file, and an override file can only replace that
  command whole; a variable is the way to tune it and keep taking updates.
  The same change was asked for in the Keycloak template, and every template in the fleet gets it at once.

v1.6.4

Fixed

• The restore merged instead of restoring, and CI never ran it. It
  unpacked the archive over the live data, and tar does not delete, so files
  created after the backup survived the restore. The end-to-end test did the
  clearing itself, which is how it passed while the shipped script merged. The
  script also carried the compose project, the backup directory and both
  backup names as literals. It now takes every path and name from the running
  backups container, accepts the timestamp as an argument, stops every service
  that writes what it restores, clears what the archive holds while keeping
  what the archive leaves out on purpose, and starts the services again
  whatever happens. CI runs it.

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

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

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.

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

Changed

• update.sh names any new required variable before it moves. An update can add a required variable; docker compose up used to stop on it after the checkout, with the tree already on the new tag. The script now lists the variables that appeared in .env.example since your version and refuses, before anything has moved, when a required one is not in your .env. Names only, never values.

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

Added

• tests/e2e-backup-restore.sh — scenarios against the live stack,
  run by CI on every push: the required-variable guard fires, a backup
  set is produced, the archive is readable, the database copy passes PRAGMA integrity_check, a cycle that cannot
  write its archive is reported as FAILED, restore genuinely
  replaces the data (the application is stopped, the baseline database copy is put back, and a row inserted after the baseline is gone), and pruning removes only old files.

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.1 — first-start backup cycle

Patch release: no image or configuration changes beyond the backup loop.

A database file that does not exist yet (the application creates it on first start, later than the first backup cycle on a fresh install) is now skipped with a note instead of being reported as a failed backup. Existing deployments are unaffected; git pull and docker compose up -d recreate only the backups container.

Full details in CHANGELOG.md.

v1.3.0 — backups for the inventory database and uploaded attachments

Added

A backups service for the inventory database and uploaded attachments. On a loop it takes a consistent online copy of each SQLite database through Python's sqlite3 backup API — no application stop — and a tar.gz of the rest of the data directory (live database files excluded, the copies are the consistent ones), logs OK or FAILED per artefact (a failed archive is kept as .failed), and prunes only its own files. Schedule knobs have defaults listed in .env.example.

homebox-restore-data.sh — interactive restore of a backup set: stops the application, unpacks the data archive, restores each database copy, starts the application.

CI waits for the first backup cycle and proves the archives are readable and the database copy passes PRAGMA integrity_check.

Upgrading

git pull and docker compose up -d — the new service starts alongside the existing ones; nothing else changes. Backups live in a named volume on the same host: bind-mount the backups path to a directory your off-host backup solution covers.

Full details in CHANGELOG.md.