lpm self-update

lpm self-update

Follows the running binary's release channel, checks npm first, falls back to GitHub Releases, and updates through the detected installation method.

Stable and nightly channels are sticky:

lpm self-update                    # follow the installed channel
lpm self-update --channel nightly  # switch to nightly
lpm self-update --channel stable   # switch to stable

A version such as 0.71.0-nightly.20260728.42.d82ceea follows nightly. A version without the nightly prerelease identifier follows stable.

How it works

1. Select the release channel. Without --channel, the running version selects stable or nightly. An explicit --channel switches channels.
2. Probe for the latest version. Stable reads npm's latest dist-tag and falls back to GitHub's latest stable release. Nightly reads npm's nightly dist-tag and falls back to the published GitHub prerelease list. A stable lookup rejects prereleases; a nightly lookup rejects stable and non-nightly prerelease versions.
3. Cache the result. Successful probes write ~/.lpm/update-check.json with separate stable and nightly state and a 10-minute TTL. Use --refresh to bypass the cache. Recent failures also have independent per-channel cooldowns.
4. Compare against the current binary's version (baked in at build time). An explicit channel switch is applied even when it is a semantic downgrade, such as a newer nightly switching back to the current stable release.
5. If an update or channel switch is needed, detect the installation method from the executable path:

6. Apply the update. npm, Homebrew, and Cargo installations spawn their package manager in normal output mode. Standalone installations download, verify, and replace the binary in-process. With --json, external install methods return a plan without spawning a command, while standalone updates are still verified and applied.

Nightly is supported for npm and standalone installations. Homebrew and Cargo installations remain stable-only and return a clear error if you request --channel nightly.

If the running version is already the latest, prints Already on the latest version (<v>) and exits cleanly.

GitHub fallback rate limits

The npm primary path has no per-IP limit you're likely to hit. The GitHub fallback does — 60 unauthenticated requests/hour per IP. You'd only see this when npm is unreachable AND you're probing repeatedly. Set GITHUB_TOKEN (or GH_TOKEN, the gh CLI convention) for 5000 req/hour. The token only needs public_repo read scope.

When the GitHub fallback is rate-limited, lpm self-update reports the reset time:

GitHub API rate limit hit. Try again in 17 minutes. Set GITHUB_TOKEN or GH_TOKEN for 5000 req/hr (vs 60 unauthenticated).

Examples

lpm self-update
lpm self-update --channel nightly  # switch to, or continue on, nightly
lpm self-update --channel stable   # switch back to stable
lpm self-update --refresh   # ignore the 10-minute version-lookup cache
lpm self-update --json      # structured result; external-channel updates are plan-only

Successful JSON responses always include success, current, latest, up_to_date, cache_hit, channel, target_channel, and channel_changed. Additional fields depend on the outcome:

Install-method-specific update paths

If you'd rather drive the upgrade yourself:

For npm and Cargo, lpm self-update chooses the matching command and substitutes the exact version it resolved into <latest>. npm users can install the moving channel tags directly:

npm install -g @lpm-registry/cli@nightly  # newest nightly
npm install -g @lpm-registry/cli@latest   # newest stable

For standalone installations, use lpm self-update. Its in-place updater verifies the release manifest's Sigstore identity and replay window, then verifies the selected asset against the authenticated manifest before replacing the running binary. A raw curl or Invoke-WebRequest directly over the executable does none of those checks and is not an equivalent update procedure; reserve that approach for explicitly insecure emergency recovery where you independently verify the downloaded artifact.

The standalone installer at https://cli.lpm.dev/install is the get-started helper for new users. It installs stable by default, accepts LPM_INSTALL_CHANNEL=nightly, and writes to ~/.lpm/bin/. Use it for first installs, not for in-place upgrades.

CI

Skip lpm self-update in CI. CI pipelines should pin LPM CLI to a specific version (via the npm package or a downloaded standalone binary) and bump that pin deliberately, not in-band during a build. Auto-updating CI's tooling is how reproducible builds become un-reproducible.

For a smoke test that the registry is reachable, use lpm health instead.

Flags

Plus the standard global flags.

See also

• Installation — initial install methods (and uninstall)
• lpm doctor — environment health, separate from version updates
• Releases on GitHub — what's in each version