v1.9.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.8.7

Security

• postgres:16 was rebuilt upstream; the pin moved from sha256:a3b7f434b2dc… to sha256:1a6ab3f5345e…. 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.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

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

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

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

Changed

• docmost/docmost:0.95.0 moved to docmost/docmost:0.96.0. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.

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.

What upstream changed

Read by fleet triage from the upstream release notes (or the commits between the tags) against this compose file, before the bump was applied.

Upstream changes 0.95.0 -> 0.96.0

Verdict: NEEDS ATTENTION — the notes call out unspecified security fixes and a new server-side encryption module, but give no operational detail, so a plain "safe" cannot be certified.

Breaking changes

• none found in the notes. No section labels anything as breaking, and no migration guide is referenced.

Variables

• none found in the notes as renamed, removed, or newly required. The compose file's REDIS_URL: redis://redis:6379 (no credentials, no TLS) is unaffected by the parsing fixes below, but flagging them for completeness:
  • fix: handle empty password, missing port, and TLS in Redis URL parsing by @michidk in #2021
  • fix: pass tls to redis in throttle module by @Philipinho in #2415
  • fix: use ACL username and decode credentials in Redis URL parsing by @Philipinho in #2434
    These only matter to a deployment whose REDIS_URL carries a password/ACL user or rediss:// — this template's does not.

Data and dependencies

• feat(server): add global encryption module (AES-256-GCM) by @Philipinho in #2400 — the notes do not say what this encrypts, whether it needs a new secret/env var, or whether it touches existing stored data. Not enough information in the notes to say this is safe or requires action; check the app's own config/docs by hand before or right after upgrade.
• feat: collab hocuspocus v4 upgrade by @Philipinho in #2351 — internal websocket-collab dependency bump; notes give no compatibility caveat.
• chore: upgrade to node 26 and pnpm 11 by @Philipinho in #2342 — internal to the image build; no host-facing effect stated.
• ## Security — This release includes security fixes, and upgrading is recommended. We are also publishing security advisories for vulnerabilities addressed in previous releases. — no CVEs, affected versions, or details given in this note; the advisories are referenced but not included here.
• No changed ports, paths, or database version requirement mentioned. No irreversible migration mentioned.

Before applying

• Take a backup before upgrading (the compose file's backups service already runs pg_dump + data tar; trigger/verify a fresh one, or run one manually, before touching the pin) — standard precaution given the notes are silent on migration reversibility.
• After upgrade, check the app's admin/settings area (or its docs) for anything related to the new AES-256-GCM encryption module (#2400), since the release notes don't specify whether it is opt-in or requires a new secret.
• Read the referenced security advisories directly on the docmost/docmost GitHub Security tab — this note only tells you they exist, not what they cover.
• No .env or compose edits are required to apply this bump; only the DOCMOST_IMAGE_VERSION/digest pin in the compose file's x-images block changes.

Notes read

• v0.96.0 (2026-09-08) — the only release notes provided, covering the 0.95.0...0.96.0 range in full (per the linked "Full Changelog" comparison).

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.