update

Usage

$ beam update

beam update checks the public polybase/payy GitHub Releases feed, selects the newest stable release that includes a matching binary for the current platform with a valid GitHub Release SHA-256 digest, downloads that asset, verifies the digest, and only then swaps the running executable in place.

Why a separate command

beam update bypasses the normal Beam state bootstrap, so it still reaches the public GitHub Releases feed even when local config.json, chains.json, or wallets.json need repair.

Normal startup and non-update commands do not wait on GitHub. They refresh ~/.beam/update-status.json asynchronously at most once every 24 hours, and beam update remains the only command that requires the live release check to finish before proceeding.

In the REPL

If you run update from the REPL, Beam always relaunches itself after a successful self-update so you are immediately running the new binary. When the current session still matches the original startup flags, Beam reuses them; otherwise it falls back to a plain beam restart.

Release naming

Release tags use the beam-v<version> format. The matching assets are:

• beam-x86_64-unknown-linux-gnu
• beam-x86_64-apple-darwin
• beam-aarch64-apple-darwin

The installer and beam update only consider non-draft, non-prerelease beam-v<version> releases from polybase/payy, and they only select a release when it contains the current platform asset with a valid sha256: digest. Other repository release trains do not affect Beam downloads.

Cached status notice

In default output mode, Beam prints a warning before entering the REPL when a previous background refresh found a newer GitHub Release. The cached file is ~/.beam/update-status.json. Non-default output formats suppress this notice so JSON/YAML scripting stays clean.