Updating Herald

Updating Herald

⚠️ On a version before 1.26.0? The in-app Update button won't get you past this one version boundary — see Upgrading from before 1.26.0 below before you try it.

The installed version is shown in the web UI's Global Settings tab, with a Check for Updates button that compares it against the latest main release on GitHub. Herald also checks automatically once a day in the background; if a newer release is available, an "Update available" badge appears in the header — clicking it jumps to the Global Settings tab.

An Update Herald button runs the actual update without needing to SSH in:

• Always installs from main, never develop — the same tested release channel as a fresh install
• Downloads and runs the same install.sh a manual update would
• Restarts the service, and verifies it actually comes back up on the new version (a real post-restart health check — service active and version file matches — not just "the restart command didn't error") before reporting success
• Runs in the background so the page doesn't hang waiting on it; a live progress panel shows each stage (backing up → downloading → installing → restarting → done)
• The button is disabled server-side (not just in the browser) while an update is genuinely in flight, so a second click — or a second browser tab — can't start a duplicate update on top of it
• Backs up your current config before making any changes — see Backup & Restore

A brief service restart (a few seconds) happens as part of any update — expected, not an error.

Manual / CLI Update

Same commands install.sh itself uses, if you'd rather update over SSH:

curl -fsSL -H "Cache-Control: no-cache" https://raw.githubusercontent.com/N6LKA/AllStar-Herald/main/install.sh | sudo bash

See Getting Started for what the installer does — running it again over an existing install is how both the web UI's Update button and a manual update work under the hood.

Upgrading from before 1.26.0

1.26.0 renamed the GitHub repo from ASL3-Herald to AllStar-Herald (issue #47) and scrubbed the old asl3-herald naming out of every path/file. GitHub redirects the old repo URL automatically, but its archive/tarball download always names the extracted folder after the current repo name — even when requested through the old URL. Any install older than 1.26.0 has the old folder name (ASL3-Herald-main) hardcoded into its self-update step, so that step can't find install.sh inside the downloaded tarball. The update silently does nothing, and the Update button (or the daily background check) leaves you on your old version with no clear error.

This can't be fixed by clicking Update — the broken logic is baked into the code that's already running on your system. One-time fix, run manually over SSH:

curl -fsSL -H "Cache-Control: no-cache" https://raw.githubusercontent.com/N6LKA/AllStar-Herald/main/install.sh | sudo bash

This bypasses the broken tarball-extraction step entirely and installs 1.26.0 directly. After that one-time manual run, the in-app Update button works normally again — this only affects crossing this specific version boundary.

Also check for stale references to the old asl3-herald paths in places install.sh doesn't manage:

• idrecording in rpt.conf, if you've set up the Node ID Generator — this line is entirely your own manual edit to Asterisk's own config, so it's never touched by install.sh. If it still reads /etc/asterisk/scripts/asl3-herald/node-id/node-id, update it to /etc/asterisk/scripts/herald/node-id/node-id and run sudo asterisk -rx "rpt reload" (or restart Asterisk if that doesn't pick it up).
• ASL3-SkywarnPlus-NG-Bridge, if you use it for a weather panel on Allmon3/Supermon — its Weather.JsonPath needs to point at Herald's new weather.json location. Fixed automatically if you update the bridge itself (1.26.0+ of the bridge migrates this the same way Herald's own installer does); otherwise edit /etc/asl3-swp-ng-bridge/config.yaml by hand and re-run the bridge once.
• Any other script or program you've pointed at a Herald-managed file (announcement WAVs, weather.json, etc.) using its old /etc/asterisk/scripts/asl3-herald/... path will need the same one-time path update — Herald's own migration only rewrites what it manages directly (its own config and integration links), not third-party references to it.