LPM

CLI Documentation   •   LPM.dev Registry   •   LPM Firewall   •   LPM Vault

What is LPM?

LPM is a fast, secure package manager and developer platform for modern JavaScript and TypeScript projects. It ships as a single Rust binary called lpm, works with the npm ecosystem, and adds secure-by-default installs, built-in developer tooling, hosted registry features, and an npm package firewall.

lpm install
lpm add lpm-source-package
lpm run dev

LPM has four connected parts:

• LPM CLI - an npm-compatible package manager and dev toolkit written in Rust. It installs from npm, lpm.dev, JSR, and private registries; blocks dependency lifecycle scripts by default; and includes a task runner, dev server, test/bench runner, linter, formatter, Node version pinning, local HTTPS, tunnels, secrets, and project health checks.
• LPM.dev Registry - the hosted registry and platform behind the @lpm.dev/* scope. Use it for private packages, Pool distribution, Marketplace sales, Swift packages, package quality analysis, generated metadata, access control, and Pro/team platform features.
• LPM Firewall - a hosted verdict service for public npm package versions. Enforcement mode checks versions before LPM materializes package bytes; monitor mode reports verdicts without holding the install. Both help teams catch malicious packages, critical vulnerabilities, suspicious lifecycle behavior, and policy violations during install.
• LPM Vault - a native macOS app for project environment variables and secrets. It stores secrets in the macOS Keychain, supports multiple environments, and syncs encrypted data through LPM.dev. The app shares local env data with the LPM CLI, so edits are available to lpm env and lpm run.

CLI env approval on macOS

In LPM Vault, select a project. Use CLI approval beside All variables:

• Off: lpm run injects the linked project's env values automatically.
• On: Keychain requires Touch ID or your Mac login password before it releases the project's env values. If authentication fails or you cancel it, LPM stops before it runs lifecycle hooks or the main script.

The setting applies to every environment in that project on this Mac. Existing lpm.json project links still work. The sidebar shows a folder for automatic access and a lock for required approval. Change the setting while the app is unlocked; no extra authentication prompt appears. The app's Lock button remains separate and does not change CLI approval.

Approval also protects other CLI commands that read the project's secrets. It controls secret retrieval. Processes that already received values retain them until they exit.

Install

LPM supports macOS, Linux glibc 2.28 or newer, Linux x64 musl (including Alpine), and Windows x64 through npm. Homebrew and the standalone installer support macOS and Linux; the standalone installer selects the matching glibc or musl binary automatically on Linux x64.

# npm
npm install -g @lpm-registry/cli --allow-scripts=@lpm-registry/cli

# Homebrew
brew tap lpm-dev/lpm && brew install lpm

# Standalone
curl -fsSL https://cli.lpm.dev/install | sh

Run the installer and all LPM CLI user commands without sudo. LPM CLI elevates only the specific operating-system operation that requires administrator access.

The npm package installs the matching platform package through optionalDependencies. The approved postinstall script verifies the native program and connects the global commands to it.

If your npm version or policy does not require explicit script approval, this also works:

npm install -g @lpm-registry/cli

Update LPM with:

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

Nightly snapshots are available through npm and the standalone installer:

npm install -g @lpm-registry/cli@nightly
curl -fsSL https://cli.lpm.dev/install | LPM_INSTALL_CHANNEL=nightly sh

Quick Links

• Get Started

  • Introduction
  • Installation
  • Your first install
  • Registries
  • Project setup
  • Migrating
  • Comparison

• Packages

  • lpm install
  • lpm add
  • lpm publish
  • lpm audit — source capabilities and JSON output
  • lpm trust
  • lpm approve-scripts
  • Workspaces
  • Lockfile
  • Content-addressable store
  • npm compatibility

• Dev

  • lpm dev
  • lpm run
  • lpm exec
  • lpm dlx
  • lpm test
  • lpm bench
  • lpm lint
  • lpm fmt
  • Node version pinning
  • Environment variables

• Infra

  • lpm tunnel
  • lpm cert
  • lpm config
  • lpm doctor
  • lpm store
  • lpm self-update
  • Secrets vault
  • Port management
  • Dependency graph

• Guides

  • Publishing a package
  • Firewall for npm
  • Zero-config dev server
  • Monorepo setup
  • Managing secrets
  • CI/CD setup
  • Docker deploys
  • Migrating from npm
  • Migrating from pnpm
  • Migrating from yarn
  • Migrating from Bun

• Reference

  • package.json fields
  • lpm.json
  • lpm.toml
  • Configuration
  • Environment variables
  • Schemas
  • Lockfile format
  • MCP servers
  • AI agent skills
  • Exit codes

Benchmarks

Install benchmarks use the tracked T3-stack Next.js fixture. See full benchmarks and methodology.

Measured September 28, 2026, on an Apple M5 Pro with 48 GiB RAM and macOS arm64. Each cell shows the median of 10 successful runs. Lower is better.

Median install time (ms)

Benchmark	npm	pnpm	bun	LPM	LPM Firewall enabled¹
First install	13,787.5	4,174	1,825	1,594.5	2,171
Fresh / warm	3,318.5	355	191.5	66	321.5
CI cold	2,655.5	3,455.5	1,538	1,374.5	1,797
CI warm	2,293	329.5	186.5	102	387.5
Installed / cache gone	667.5	10	19	12	12
Up to date	440.5	10	19	12	12

Median peak RSS (MiB)

Benchmark	npm	pnpm	bun	LPM	LPM Firewall enabled¹
First install	863.2	624.4	393.5	355.6	383.7
Fresh / warm	1,448.7	123.5	49.6	90.4	96.0
CI cold	395.3	481.9	129.7	239.0	258.3
CI warm	865.9	60.8	7.2	61.6	59.0
Installed / cache gone	158.7	18.5	7.9	25.3	25.5
Up to date	149.2	18.5	7.9	25.5	25.5

¹ Firewall enabled means monitor mode, measured in a separate run with the same LPM binary and fixture. The difference between columns is not a controlled measurement of firewall overhead.

Dev commands — median time (ms)

These benchmarks measure already-installed scripts, local binaries, and tools, with two warmups before the 10 measured runs. Dependency installation is outside the measured interval.

Benchmark	npm	pnpm	bun	LPM
Package script: echo hi	67.5	13.6	5.5	10.7
Node startup + tiny script	88.0	34.0	26.4	30.2
Local bin: esbuild --version	133.5	22.2	8.2	11.9
Run TSX app, warm cache	200.4	87.8	6.2	47.4
Lint 20 JS files (Oxlint)	162.4	50.7	37.0	16.6
Format check, 20 JS files (Biome)	158.7	46.6	33.7	15.5

Benchmark methodology

Versions: LPM 0.78.0, npm 12.1.0, pnpm 12.6.0, Bun 1.4.2, and Node 24.19.0. LPM used a release build from commit 5cc8869c5a4c03b04788a80c5dc648098df295e3.

Install setup: run-t3-install-six-states.mjs uses the T3 manifest from Bun's install benchmark. Each run uses an isolated project, home directory, and dependency cache. Preparation is outside the measured interval. Manager and state order rotate between rounds.

Lifecycle scripts are disabled. Other security and release-age settings retain product defaults, except the explicit firewall monitor run. LPM's default release age is zero and its firewall is off. npm retains its default audit behavior.

LPM uses V2 and --json --no-security-summary --no-skills --no-editor-setup. This is not a comparison with identical security settings or dependency graphs.

Six states: First install and Fresh / warm have no lockfile or installed tree, with cold and warm dependency caches respectively. CI cold and CI warm retain a lockfile but have no installed tree. Installed / cache gone and Up to date retain both, with cold and warm dependency caches respectively. The CI labels describe the initial state, not a dedicated ci command. Each manager runs its normal install command.

Cold refers to local dependency caches, not operating-system or CDN caches. LPM retains its backing content store in Installed / cache gone because installed symlinks depend on it.

Firewall conditions: All 40 install/reinstall samples completed verdict requests, but the server used individual lookups because its flagged-package index was stale. The 20 no-op samples reused validated preparation state and did not request new verdicts. Network and server conditions can differ between the firewall-off and monitor runs.

Memory: Peak RSS comes from /usr/bin/time -l. It is not the simultaneous memory total of a process tree. Each table cell is the median of 10 per-run peaks.

Dev commands: run-dev-command-suite.mjs runs commands sequentially and rotates manager order. Script rows use run. Local binaries use npm exec --no --, pnpm exec, bun run, or lpm exec.

The TSX fixture imports 10 modules and uses a small local JSX runtime. LPM and Bun use their built-in TSX entry commands. npm and pnpm launch local tsx through exec. The npm TSX result therefore includes npm startup, unlike the previous direct-tsx result.

Tool versions are esbuild 0.28.2, tsx 4.23.15, Oxlint 1.79.0, and Biome 2.5.9. LPM uses managed Oxlint and Biome. The other columns launch those versions as local tools. Lint checks 20 lint-clean JavaScript files. Format checks use preformatted files and never write changes. Correctness checks reject unexpected output, failed commands, and source changes.

Reproduction instructions cover both suites. More results and measurement details: full benchmark page.

Contributing and security

See CONTRIBUTING.md for development setup, testing expectations, and the pull request workflow.

Report suspected vulnerabilities privately according to SECURITY.md. Do not open a public issue for a security report.

License

Dual-licensed under MIT OR Apache-2.0.

See LICENSE-MIT and LICENSE-APACHE.