v2.1.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.

v2.0.4

Security

• postgres:17.11 was rebuilt upstream; the pin moved from sha256:f4c66b820c6f… to sha256:d74eeac9a635…. 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.

v2.0.3

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 README's Testing section describes the workflows as they are. It still listed the freshness check inside Deployment Verification after that check moved to its own workflow.
• 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.
• Checked daily, as the security policy already said. This template's schedule was weekly while its SECURITY.md said the pins are re-resolved daily, and nothing recorded a reason for the difference. It now runs daily like the rest of the fleet.

v2.0.2

Changed

• requarks/wiki:2.5.314 moved to requarks/wiki:2.5.315. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.

Security

• postgres:17.11 was rebuilt upstream; the pin moved from sha256:67f41722b7a8… to sha256:f4c66b820c6f…. Same version, same tag, a rebuilt base image — the usual shape of a security fix in a base layer.
• traefik:3.7 was rebuilt upstream; the pin moved from sha256:f86a2cab1b5c… 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.

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 2.5.314 -> 2.5.315

Verdict: SAFE TO APPLY — a two-fix security patch on the 2.5.x line, no companion-service version change, no schema or variable impact.

Breaking changes

• none found in the notes

Variables

• none

Data and dependencies

• none. The relevant entries are both fixed-version security fixes: 2df962c "prevent manage:users users from editing manage:system users" (fixes GHSA-45cp-v5ph-2jhm) and 1161ddc "prevent user-provided v-slot content" (fixes GHSA-98c8-px3r-68c6). Neither mentions the database, migrations, ports, or paths. The 3.0.0-beta/alpha entries in the notes are unrelated pre-releases explicitly marked "Not for production use" and do not apply to this 2.5.x update.

Before applying

• Update the compose file's pinned digest/tag for requarks/wiki from 2.5.314 to 2.5.315 (and WIKIJS_IMAGE_VERSION in .env if overridden there).
• Take the routine precaution of a Postgres dump before any image bump, per this repo's own backups service, even though nothing in the notes requires it.
• No manual migration steps, no .env edits required.

Notes read

• v2.5.315 (2026-09-21) — read in full, the two bug-fix entries are the only content relevant to this upgrade.
• 3.0.0-beta.583, 3.0.0-beta.561, 3.0.0-beta.554, 3.0.0-beta.550, 3.0.0-beta.543, 3.0.0-beta.537, 3.0.0-alpha.530 — read but out of scope: these are pre-release entries for the unreleased 3.x line, not part of the 2.5.314 → 2.5.315 range, and explicitly marked not for production use.
• No UPGRADING / BREAKING_CHANGES / CHANGELOG document was supplied for this range; none was consulted beyond the release notes above.

v2.0.1

Changed

• postgres:17 moved to postgres:17.11. 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.

v2.0.0

Changed

• PostgreSQL 14 → 17, which is a migration and not a restart. PostgreSQL 14
  reaches end of life on 12 November 2026. A data directory belongs to one
  major, so the new server refuses the old one's files and docker compose up -d is not the upgrade path here. ./wikijs-upgrade-postgres.sh dumps the
  database with the old server's own pg_dump, refuses to continue unless that
  dump reads back as a valid archive, removes only the PostgreSQL data volume,
  starts 17 alone, loads the dump, and brings the stack back up. ./update.sh
  calls it when a release moves the major; --dry-run on either says what would
  happen. Take your own copy of the dump it leaves behind: once the old
  volume is removed it is the only one. PostgreSQL 17 is supported until
  November 2029.

Added

• The upgrade drill runs the migration. Where a release changes the
  PostgreSQL major, CI no longer restarts the stack on the previous release's
  volumes - it writes a row into the previous release's database, runs
  ./wikijs-upgrade-postgres.sh, and fails the build unless that row reads back
  from the new server. A migration nobody has run is a migration nobody should
  ship.

Upgrading

This release changes the PostgreSQL major, so docker compose up -d is not the upgrade path. The new server refuses the data directory the old one wrote and exits before Wiki.js ever connects.

Run ./update.sh, which crosses to this tag and calls the migration for you, or run ./wikijs-upgrade-postgres.sh yourself after checking out v2.0.0. Either way, --dry-run first says what would happen without touching anything.

The migration dumps the database with the old server's own pg_dump, refuses to continue unless that dump reads back as a real archive, removes only the PostgreSQL data volume, starts 17 alone, loads the dump, and brings the rest of the stack up. Take your own copy of the dump it leaves behind: from the moment the old volume is removed, it is the only copy. Your .env and every other volume are untouched.

A fresh deployment needs none of this: docker compose up -d starts on PostgreSQL 17.

Proven, not asserted

The upgrade drill in CI ran this migration before the release was cut: v1.7.0 came up on PostgreSQL 14, a row was written to it, the migration dumped 5031 bytes, removed the old data directory, started 17 and loaded the dump, and the row read back from the new server. The ordinary HTTPS smoke test and backup-validity check then passed on the migrated stack.

PostgreSQL 14 reaches end of life on 12 November 2026. PostgreSQL 17 is supported until November 2029.

Full history in CHANGELOG.md.

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

Fixed

• A backup killed halfway no longer keeps the name a finished one has. The
  dump is written to <name>.partial and renamed only once it has succeeded.
  The loop already renamed a failed dump to .failed, but that branch only
  runs if the shell survives to reach it — a container stopped mid-dump does
  not, and left a truncated file under exactly the name a restore picks.
• PostgreSQL is given sixty seconds to shut down. Dockers default is ten
  and then SIGKILL, which can cut a checkpoint in half and leave the next start
  doing crash recovery.

Both changes went out across the fleet on 4 September. This repository was
missed because the rollout ran over the checkouts on one machine rather than
over the list of repositories, and this one was not among them. The
conformance check now runs against GitHub for exactly that reason.

Upgrading

git pull (or ./update.sh), then docker compose up -d. The database
container is recreated to pick up the new stop_grace_period; nothing else
changes. Any .partial file left behind by an interrupted backup is a
truncated dump and is safe to delete.

Full history in CHANGELOG.md.

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.