Updates

burrowee update

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

update checks for the latest released cli version, prints the version gap and the changelog, and applies it without prompting — assume-yes is the default for this one verb (it is a shortcut for updater update, below). Pass --auto=false if you want a confirmation prompt back, or --dry for the report alone.

Flag	Meaning
--dry	report the version gap and the changelog, install nothing
--auto	assume-yes: apply without prompting — already the default here; --auto=false restores the prompt
--force	re-install and restart even when already on the latest version
--no-restart	install but do not restart the managed service
--version <v>	pin or roll back to this exact public version from the console catalog
--console <url>	console base URL for the release catalog (used with --version; default https://console.burrowee.com)

Plain burrowee update (no --version) targets the latest release from the public release channel. --version <v> takes a different path: it resolves that exact version from the console's release catalog and installs it directly — which is what makes rollback possible (the plain path only ever moves forward to latest). 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:

burrowee update --version v0.2.0

After the install, the managed service is restarted only when the installed cli version actually changed (or on --force), so a no-op update never bounces your daemon; --dry, --no-restart, and --auto=false all suppress the restart. The final report tells the truth about what happened — "updated to X" when the version moved, "reinstalled X" on a forced re-place.

Verified, migrated installs

Every update is cryptographically verified before anything touches disk. A non-forced update rides the release's update.sh, itself verified against Burrowee's release signing key before it runs; the script then applies the same verification chain as the installer — a minisign signature over the checksum manifest, then the artifact's own SHA-256 — so a spoofed or corrupt download can't replace your binary. The --version-pinned path runs the equivalent verification in the CLI's own code against artifacts resolved from the console catalog. Either way, nothing is installed unless the signature checks pass.

An update also runs the release's migration ladder — versioned scripts that carry an older install's on-disk layout forward. The first rung sweeps stale per-user binary copies that would shadow the freshly installed ones on PATH (it only has work to do on installs with a non-default PREFIX), asking before it removes each file. After a shadowing copy is removed, your shell may still have the old path cached — run hash -r or open a new terminal.

burrowee updater — the update system

burrowee updater <update|upgrade|reinstall|status|doctor|version>

All update work is done by a separate, co-located binary (burrowee-cli-updater), so the swap never runs from inside the binary being replaced — a stuck or already-running burrowee invocation can't get in its own way. burrowee updater <sub> forwards to it verbatim; burrowee update and burrowee reinstall are top-level shortcuts for the two sub-verbs you'll actually use day to day.

Sub-verb	What it does
update	update the cli component to the latest release — what burrowee update runs
upgrade	advance the updater binary itself (see below)
reinstall	repair the current install offline (see below)
status	print the installed · running · available version picture
doctor	the status report plus a one-line verdict
version	print the updater binary's own version

updater status and updater doctor are version-focused: installed · running · available, plus the updater's own version. Both are read-only and never fail on a verdict — an available update is a report, not an error. For pairing, relay, and daemon health, use burrowee status instead.

updater upgrade — updating the updater

A cli update installs the release bundle — it replaces burrowee and burrowee-cli but never the updater binary doing the work. updater upgrade is the updater-only swap that closes that gap:

burrowee updater upgrade

Note the flag asymmetry: a plain upgrade swaps only burrowee-cli-updater (it never prompts, and --auto/--no-restart are no-ops — a one-shot has no service to restart), while --dry, --force, and --version take the full release-bundle route instead: --force and --version do replace burrowee-cli, and --dry reports the version gap and installs nothing.

burrowee reinstall (offline repair)

burrowee reinstall [--dry] [--no-restart]

Repair-to-current: reinstall re-runs the already installed install.sh to re-render the service units and re-seed config against the binaries on disk. It downloads nothing, replaces no binary, and never prompts — so it can neither upgrade nor roll back. Reach for it when the managed service unit or config looks mangled but the binaries themselves are fine. --dry shows the repair plan; the managed service is restarted afterwards unless --no-restart.

When the installed cli is too broken even for that, repair from outside with the hosted one-liner — the same trust anchors and verification path as install.sh. It re-installs and then force-runs the release's migrations at or above a floor, regardless of the version this host recorded (the fix when migrations were skipped, e.g. hand-placed binaries or a same-version rebuild):

curl -fsSL https://release.burrowee.com/cli/upgrade.sh | sh              # force the whole shipped ladder
curl -fsSL https://release.burrowee.com/cli/upgrade.sh | sh -s -- 0.2.0  # force the 0.2.0-and-newer migrations

The optional argument is the inclusive migration floor — it selects which migrations are forced, never which release installs. Details: Upgrading.

Reading the versions block

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

versions
    dispatcher   v0.2.1
    cli          v0.2.1 running, up to date
    updater      v0.2.1

• 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 — you've updated the binary but the running daemon is still the old version; burrowee restart fixes it. Since updates restart the managed service automatically whenever the version changed, drift mostly means a daemon you run under your own supervisor, or an update run with --no-restart;
  • vX installed · daemon not running — no daemon is currently up at all.
• updater — the co-located burrowee-cli-updater's own version (advanced by updater upgrade, not by update).

Opting out

The CLI has no server-driven push path: there is no always-running updater daemon the way there is for the gateway and the edge, and the updater never opens a console connection on its own (only --version reaches the console, to resolve that pinned release). Updates happen when something on your machine starts one — you running burrowee update, a script or timer you set up yourself, or a locally-authorized client asking the running daemon over its unix socket to trigger one (the daemon then spawns the updater; that spawned form is the bare burrowee-cli-updater --auto you may spot in a process listing — an internal trigger, not an operator surface). Opting out is simply: don't run it.