Skip to content

Upgrades

Upgrades track the :latest image tag:

podman pull registry.marvin8.zone/marvin8/xique:latest
systemctl --user restart xique-pod

That is the whole procedure. Everything below is what happens and what to check.

Before you upgrade

Take a backup. Upgrades run schema migrations, and migrations only move forward — the one situation a backup cannot paper over is a migration bug, so the safe pattern is back up, upgrade, and restore only if something goes wrong.

What happens on restart

  • The worker opens the database and applies any pending schema migrations (an ordered, integer schema_version ladder). This is the single migration owner.
  • The web process verifies the schema version on every start and refuses to serve while the database is behind. Right after an upgrade you may see a few web restarts until the worker has migrated — the same settling behaviour as first boot, over in seconds.
  • Both processes then run the new image against the old data. Recommendations recompute on the worker's next cycle; the ledger is never touched by upgrades.

Checking on it

systemctl --user status xique-pod
journalctl --user -u xique-web -u xique-worker -f

A healthy upgrade shows the worker logging its migration step (if any) and web coming up to serve.

Rollbacks

Release tags are published alongside :latest, so you can pin back:

podman pull registry.marvin8.zone/marvin8/xique:0.1.0
# edit ~/.config/containers/systemd/xique-web.container and
# xique-worker.container to reference the tag, then:
systemctl --user daemon-reload
systemctl --user restart xique-pod

One caveat: because migrations are forward-only, rolling back across a release that migrated the schema leaves the database ahead of what the old image expects. The web process will refuse to serve. Roll the database back with it: restore the backup you took before upgrading.