lpm self-update

lpm self-update

Checks GitHub Releases for the latest LPM version, compares against the running version, and runs the appropriate upgrade command for whichever channel you installed from. The install method is auto-detected from the executable path.

How it works

1. Probe for the latest version. The npm registry is the primary source — https://registry.npmjs.org/@lpm-registry/cli/latest — which is anonymous and unmetered, so most users never touch a rate-limited path. If npm is unreachable, falls back to GitHub Releases (api.github.com/repos/lpm-dev/rust-client/releases/latest). The two sources stay in lockstep because every release publishes from the same tag.
2. Cache the result. Successful probes write ~/.lpm/update-check.json with a 10-minute TTL — a second lpm self-update inside that window short-circuits the network call. Use --refresh to bypass the cache. A recent probe failure also caches a cooldown so the network isn't hammered after an outage.
3. Compare against the current binary's version (baked in at build time).
4. If newer, detect the install channel from the executable path:

5. Spawns the upgrade command. The current process continues; the new binary is in place for the next invocation.

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 --refresh   # ignore the 10-minute version-lookup cache
lpm self-update --json      # structured: current, latest, up_to_date, install_method, update_command, cache_hit

Channel-specific equivalents

If you'd rather drive the upgrade yourself:

lpm self-update is just a convenience wrapper that picks the right one and pins the exact version it just resolved. For npm and Cargo the wrapper substitutes the resolved version into <latest>; the npm @latest dist-tag and an unpinned cargo install --git work too if you want channel-latest semantics, at the cost of skipping past any release the wrapper would have pinned.

The standalone installer at https://lpm.dev/install.sh is the get-started helper for new users — it always resolves releases/latest itself 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 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