How updates work
This section is for the person who runs a Hatamoto server. Hatamoto can keep itself current: it checks for new releases every few hours, installs the ones your settings allow, checks that each new version starts and answers, and goes back to the previous version on its own when it does not.
The guides walk you through the everyday tasks: seeing what the updater is doing, installing an update now, holding updates back, and rolling back. The reference pages describe every command, setting, file and check in detail. In short: run the shipped Docker image or systemd unit, keep HATAMOTO_DATA on a writable volume, and leave HATAMOTO_UPDATES at its default. To publish a release yourself, see Release process. To compare the keys your install trusts with the published ones, see Signing keys and fingerprints.
Guides
- Overview
Get a working picture of how your server finds, checks, installs and, if needed, undoes a new Hatamoto release.
- Check and apply
See whether a new Hatamoto release is waiting, find out what installing it would do, and install it now from the server or the admin.
- Pin or turn off
Stay on one release line, delay updates, pick the hours they may install, or switch automatic updates to notify only or off.
- Backups and rollback
Take your own backup before an update, go back to the previous version by hand, and get a site running again when it will not start.
- Upgrading self-hosted
Move your own server to a newer Hatamoto version with Docker or systemd, keep your data and secret safe, and confirm the new version runs.
- Verify a download
Check that a Hatamoto binary or Docker image is the one we built and signed, before you run it, with the GitHub CLI, sha256sum and openssl.
Reference
- Manual update CLI
Every hatamoto update command, flag, output line and refusal, including installs from local files on a server with no internet access.
- Update agent
Every setting, default, check and status of the part of the server that looks for, downloads and prepares new releases.
- Supervisor
How the process that runs your server picks a version, checks every switch, rolls back on its own and records what it did.
- Trust and signing
The two signing keys behind every update, each check a new release must pass before it runs, and what a leaked key could and could not do.
- Signing keys
The public keys Hatamoto trusts, their fingerprints and where to check them, and what happens when a key is rotated or leaks.
- Upgrade rules
The database rules that make going back a version safe, how major versions differ, and how long each release line gets fixes.