Upgrading
klatch update
That takes a backup (before anything else changes, mode 600, recording the version you are on), pulls the new hub image, refreshes the compose file and the agent recipe, rebuilds the agent image only if its recipe changed, restarts, and waits until the hub answers. Your database, data folder and .env are kept. Database changes run by themselves on start and only ever add.
- A specific version:
klatch update --version 1.2.0. - Skip the automatic backup:
klatch update --no-backup(not recommended; it also meansklatch rollbackhas nothing to restore). - Running
install.shagain on an existing install runs the sameklatch update(backup first), to the version you pass orlatest. - The agent image is rebuilt whenever
runner/Dockerfilechanges (its hash is stored on the image), even though the tag stays the same.
Agents that are mid-turn when Klatch restarts are marked interrupted and their work goes back to the queue. Branches and drafts stay.
Going back
Every klatch update takes a backup in /opt/klatch/backups before it changes anything, and remembers it. To undo the last update:
klatch rollback # asks first; restores that backup (data, .env, compose.yml, runner recipe) and pins the previous version
The data you had before the rollback is kept in /opt/klatch/data.before-restore-*. Anything written after the update is lost by a rollback, since an older hub cannot read a database written by a newer one. To restore an older backup by hand, use klatch restore <file>.
Backups
klatch backup # /opt/klatch/backups/klatch-backup-<time>.tgz
klatch restore <file> # asks first; keeps the old data aside
The file holds a consistent copy of the database (taken while the hub runs), the data folder (repo mirrors, uploaded files), your .env and the encryption key. Treat it like a password file. Copy it off the server on a schedule, for example with a cron job and rsync.
To move Klatch to a new server: install it there, run klatch restore with your latest backup, then deactivate the license on the old one.