Updates

Updating by hand, the update notice, and optional one-click updates from the web app.

By hand

In the folder you cloned:

git pull
docker compose up -d --build

This gets the newest release and builds it (a few minutes). What each version changes, and anything to do when updating: Changelog. The server takes a backup before applying any database change. The admin sees on Server admin when a new version is out (checked against the project’s GitHub releases at most every 6 hours; UPDATE_CHECK=off in .env stops it).

Staying on one version

Check out a release’s tag instead of main, then build:

git fetch --tags
git checkout v1.2.0
docker compose up -d --build

Every release is a tag (the list). git pull and the one-click update don’t move a server that’s on a tag; git checkout main goes back to following releases.

One-click updates (optional)

Add COMPOSE_PROFILES=updater to .env (https,updater with Caddy) and run docker compose up -d. The admin can then press Update now on Server admin. While it runs (a few minutes, most of it building), every page of that browser tab shows a notice instead of errors, and says when the new version is up or why the update failed; reload the page then. Anyone else using the server keeps the page they’re on; during the moment it restarts, saving says the server can’t be reached. What’s new opens the Changelog. Without the helper, Server admin shows the two commands above when a newer version is out.

This starts a small helper that can control Docker on this machine, which is root-level access, and can write to the folder you cloned. It only ever runs git pull there (as the folder’s owner) and rebuilds and restarts the services that are running, and the server itself can only leave it a request. Turn it on only if you’re comfortable with that. A release that adds a service or changes the helper itself says so in its notes: run docker compose up -d once by hand for it. Updating is a web app feature; the mobile app doesn’t do it.

How it works: Running an instance.