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

Changed

• b3log/siyuan:v3.8.4 moved to b3log/siyuan:v3.8.5. 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 v3.8.4 -> v3.8.5

Verdict: SAFE TO APPLY — no breaking changes, no variable or command-line changes, and no companion-service version requirement is named in the notes.

Breaking changes

• none found in the notes

Variables

• none. The compose file's command: ['serve', ...] and SIYUAN_ACCESS_AUTH_CODE handling (noted in the compose comment as a v3.8-line breaking change already accounted for) are unaffected — nothing in the v3.8.5 notes touches CLI invocation or the access-code variable.

Data and dependencies

• none. No database engine, no migration, no port or path change is mentioned. The only fix touching stored data is asset cleanup, covered below.

Before applying

• Take the routine precaution given the asset-cleanup fixes: "Unreferenced asset cleanup deletes assets referenced in HTML or by URLs with fragments" and "Unreferenced asset cleanup deletes assets of documents that fail to load" are bugfixes for destructive prior behavior — confirm the backups service has produced a recent successful data archive (check its logs for "Data backup OK") before upgrading, in case any workspace was already affected by the old bug.
• No manual migration command, config edit, or forced backup step is required beyond that standing precaution.

Notes read

• v3.8.5 (2026-09-22) — full release notes, plus the preceding beta/alpha pre-releases (v3.8.5-beta.1 through beta.5, alpha.4, alpha.5) which are cumulative subsets of the same content and contain no additional breaking items.
• CHANGELOG.md — not usable: it only points to app/changelogs/ in the upstream repo, no content was included here.

v1.6.2

Changed

• b3log/siyuan:v3.8.3 moved to b3log/siyuan:v3.8.4. 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.

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.
• b3log/siyuan:v3.8.2 moved to b3log/siyuan:v3.8.3 (automated: 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). 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, a cycle that cannot
  write its archive is reported as FAILED, restore genuinely
  replaces the data (the application is stopped, the baseline archive is unpacked over the data directory, and a file created 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.0 — backups for the whole workspace

Added

A backups service for the whole workspace. 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.

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

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

v1.1.0 — unattended updates with update.sh

Added

update.sh — unattended updates to the newest tagged release, and nothing else. A tag is cut only after CI has booted the pinned images and passed the smoke tests, so "update to the latest tag" means "update to a combination a machine has already run" — the guarantee a floating latest can never give.

• refuses to cross a major version on its own (--allow-major after you read the notes)
• refuses a checkout with local modifications (your customization belongs in .env, which updates never touch)
• --dry-run shows what would be applied

Put it on a timer for hands-off minor/patch updates:

17 5 * * *  /opt/siyuan-docker-compose/update.sh >> /var/log/siyuan-docker-compose-update.log 2>&1

It is deliberately a host-side script and not a container in the stack: an in-stack updater needs the Docker socket and turns "someone pushed to a repo" into "someone deployed to your machine" with no operator in the loop.

Full details in CHANGELOG.md.