Updates

burrowee update

burrowee update [--dry] [--auto] [--force] [--no-restart] [--version <v>] [--console <url>]

Flag	Meaning
--dry	show the plan (current version, latest version, changelog) only — install nothing
--auto	assume-yes: apply without the interactive prompt
--force	reinstall + restart even when you're already on the latest version
--no-restart	install but skip the service restart
--version <v>	pin or roll back to an exact public version (from the console catalog) instead of latest
--console <url>	console base URL for the release catalog (used with --version; default https://console.burrowee.com)

Plain burrowee update (no --version) checks GitHub for the latest release, prints the version gap and changelog, and — unless you passed --dry or you're already up to date — re-runs the official install.sh. --version <v> switches to a different path instead: it resolves that exact version from the console's release catalog and downloads it directly, which is what makes rollback possible (the GitHub/install.sh path only ever moves forward to latest).

Either way, three modes govern whether anything actually gets written:

• --dry — print the report and stop. Nothing is downloaded or installed.
• default (interactive) — print the report, then prompt apply this update? [y/N] on a real terminal. Piped or non-interactive input (a cron job, CI) never prompts — it just prints a hint to re-run with --auto and exits without changing anything.
• --auto — skip the prompt and apply immediately, once past the dry/up-to-date checks.

After a successful install, the CLI restarts its managed service — but only when something actually changed: it hashes the binary before and after, and (for the --version path) also tracks whether the service unit was rewritten, and skips the restart when neither changed (--force overrides this). --no-restart always skips it regardless. The command finishes by printing the same summary burrowee status would, so you can see the post-update state in one shot.

Verify-then-swap

Every artifact is cryptographically verified before it ever touches disk — a compromised or spoofed download can't install a binary Burrowee didn't sign, and a partial/corrupt download can't leave the old binary half-replaced:

1. Download the release zip, its SHA256SUMS.txt, and the matching .minisig signature.
2. Verify the .minisig signature over SHA256SUMS.txt against Burrowee's baked release public key (via the minisign binary — the CLI looks for it on PATH, then /opt/homebrew/bin/minisign and /usr/local/bin/minisign, and tells you brew install minisign / your package manager if it can't find it).
3. Verify the downloaded zip's own sha256 against the now-trusted SHA256SUMS.txt entry.
4. Extract the binary and atomically swap it into place — the new binary is written to a temp file next to the target and renamed over it, so a crash mid-update never leaves a truncated binary on disk.

The plain (no --version) path delegates steps 1–4 to install.sh itself, which does the same minisign+sha256 verification; the --version-pinned path runs the equivalent verification in the CLI's own Go code against artifacts resolved from the console catalog. Either way, nothing is installed unless both signature checks pass.

burrowee-cli-updater — the standalone updater

burrowee-cli-updater update [flags]
burrowee-cli-updater version

The same update logic also ships as its own small binary, burrowee-cli-updater, taking the identical flags as burrowee update above. It exists so an update can be triggered — say, from your own cron job or launchd/systemd timer — without going through the burrowee binary that's being replaced: applying the swap from a separate process means a stuck or already-running burrowee invocation can't get in its own way.

TIP

Unlike the gateway and edge updaters, burrowee-cli-updater is a strict one-shot: burrowee-cli-updater run is refused outright ("the cli updater is a one-shot (no agent); use update"). There's no updater daemon and no server-driven push for the CLI — see Opting out below.

Reading the versions block

burrowee status, burrowee doctor, and burrowee version/--version all end with the same versions block, comparing what's installed on disk against what's actually running:

versions
    dispatcher   v0.1.44
    cli          v0.1.38 running, up to date

• dispatcher — the version of the burrowee dispatcher that exec'd this command, or (not run via burrowee) when you invoked burrowee-cli directly.
• cli — compares the binary you just ran against the version the long-running daemon reported at its last start:
  • vX running, up to date — the daemon is alive and matches the binary you just ran;
  • vX installed · vY running ⚠ drift — run \burrowee cli restart`— you've updated the binary but the running daemon is still the old version. This is the single most common post-update trap:burrowee update` restarts the managed service it knows about, but a daemon you started by hand (or under your own supervisor) won't pick up the new binary until you restart it yourself;
  • vX installed · daemon not running — no daemon is currently up at all.

Pinning or rolling back a version

Pass --version with the exact version string you want (as published in the console's release catalog) plus --console if you're not using the default console:

burrowee update --version v0.1.36

This is the only supported way to move to an older version — a rollback is not a special case, just an update whose target happens to be behind you. The console decides which versions are public and resolvable this way.

Opting out

The CLI has no server-driven push path: burrowee-cli-updater never opens a console connection on its own (only --version reaches the console, to resolve that pinned release), and there is no always-running updater daemon for it the way there is for the gateway and edge. Nothing updates your CLI unless you run burrowee update or burrowee-cli-updater update — by hand, from a script, or on a timer you set up yourself. Opting out is simply: don't run it.