Skip to Content
OperationsUpgrade

Upgrade

Upgrades are deliberate: a backup, a binary swap, a controlled restart. Schema migrations run automatically on the next serve.

Procedure

  1. Back up.

    hiveloom backup create --output /var/backups/hiveloom-$(date +%F).tar.gz

    See Backup & restore for what the archive contains and where to store it.

  2. Stop the service.

    sudo systemctl stop hiveloom

  3. Replace the binary. Either via the install script:

    curl -fsSL https://bin.hiveloom.cloud/install.sh | bash -s -- --version 0.3.0

    …or via the in-place upgrade subcommand:

    sudo hiveloom upgrade --version 0.3.0

    hiveloom upgrade --check tells you whether a newer release is available before committing.

  4. Restart and migrate.

    sudo systemctl start hiveloom

    Migrations run on first serve after the swap. They are forward- compatible inside a major version. Cross-major upgrades will note any manual step in the release notes.

  5. Verify.

    hiveloom health
hiveloom status

    Both should be green. If health reports 503, see the troubleshooting table below or Troubleshooting.

Rollback

If the new binary regresses on something you depend on:

sudo systemctl stop hiveloom
sudo hiveloom rollback
sudo systemctl start hiveloom
hiveloom health

rollback swaps back to the previous binary saved by the most recent upgrade. It does not undo schema migrations: if the new schema is incompatible with the old binary, restore the pre-upgrade backup instead:

sudo systemctl stop hiveloom
hiveloom backup restore --input /var/backups/hiveloom-pre-upgrade.tar.gz
sudo systemctl start hiveloom

Time budget

Plan ~5 minutes of downtime for a routine point-release upgrade on a single VPS. Cross-major upgrades may take longer if migrations need to rewrite tables; back up first, watch journalctl -u hiveloom during the restart.

See also

Backup & restoreTroubleshooting