Self-update
Beam ships with `beam update` — a SHA-256-verified self-update from the public `polybase/payy` GitHub Release feed.
See also: the update command reference for the user-facing flags.
How it works
beam updatequeries the publicpolybase/payyGitHub Releases feed.- It selects the newest stable release that includes the current platform asset with a valid
sha256:digest. - The asset is downloaded.
- The downloaded binary is verified against the release's SHA-256 digest.
- Only if the digest matches does Beam swap the running executable in place.
Any digest mismatch aborts the update. There is no fallback that runs an unverified binary.
Why it's a separate code path
beam update bypasses the normal Beam state bootstrap. That means:
- It still works when
config.json,chains.json, orwallets.jsonneed repair. - It is the only command that requires the live GitHub check to finish before proceeding.
- Other commands rely on a cached check in
~/.beam/update-status.json, refreshed asynchronously at most once every 24 hours.
Update notice
In default output mode, Beam prints an update warning when the cached status indicates a newer release is available. JSON/YAML/compact/quiet output modes suppress the notice so scripted runs stay clean.
The cache lives at ~/.beam/update-status.json.
Release naming
- Tags are
beam-v<version>. - Assets shipped per release:
beam-x86_64-unknown-linux-gnubeam-x86_64-apple-darwinbeam-aarch64-apple-darwin
The installer and beam update only consider non-draft, non-prerelease beam-v<version> releases from polybase/payy, and only select a release when it contains the current platform asset with a valid sha256: digest. Other release trains in the same repo don't affect Beam downloads.
Release control
Releases are published from polybase/payy via .github/workflows/beam.release.yml. The workflow builds the platform binaries and publishes the beam-v<version> GitHub Release assets that the installer and beam update consume.
Each beam-v<version> tag publishes once — reruns skip rather than overwriting, so the maintainer team cuts a new version before re-releasing.
Version bumps follow conventional-commit semantics: feat → minor, breaking change → major, anything else → patch. Maintainers can also pick an explicit version when triggering the release manually.