How is jpm so fast and small?

It's one ~2 MB binary with no runtime, uses little memory during installs (34 MB vs npm's 387 MB for a cold nuxt install on GitHub CI), and keeps a content-addressed store where each file is stored once and each package built once — warm installs mostly create hardlinks (1–2 ms for a repeat install).

What security protections does jpm provide by default?

Install scripts don't run until you run `jpm approve` for the package and version; versions published in the last day are skipped (min-release-age); published packages can't introduce git or tarball dependencies; packages are integrity-checked against the lockfile before their files are visible; credentials stay out of jpm.lock; cloned repos can't disable TLS checks or loosen the release age; and requested Node.js runtimes are verified against Node's release signatures. Note that this is not a sandbox — an approved script runs with your permissions.

How was jpm built, and how trustworthy is it?

Every line was written by Claude Code (running Claude Opus 5.5) under the direction of engineer JT Turner. External verification was a stated condition: the custom TLS implementation is tested against Project Wycheproof and RFC test vectors, and the tool is checked against the test suites of npm, pnpm, yarn, and bun.

jpm — Fast, small, secure-by-default package manager for JS

jpm is a JavaScript package manager built for speed, low resource use, and security defaults. It ships as a single ~2 MB binary with no runtime dependency, installs npm packages, and claims the fastest cold install times on GitHub CI in most tested scenarios. It imports existing lockfiles from npm, pnpm, yarn, and bun without registry lookups, uses a content-addressed store with hardlinks so each file and package is stored/built once per machine, and blocks common npm supply-chain attack paths by default: install scripts wait for explicit approval, packages published less than a day ago are rejected, and git/tarball dependencies are refused unless your own project declares them.

Key Features

Single ~2 MB binary

One binary with no runtime to install and no dependency tree of its own — far smaller than pnpm (~60 MB), bun (~80 MB), or aube (~150 MB).

Fast CI installs

In the site's benchmarks across three real projects (nitro, nuxt, next) on GitHub CI, jpm was fastest in 9 of 12 install-phase cells; a cold nuxt install of 591 packages took 1.22 s vs 18.54 s for npm, and peak memory was 34 MB vs 387 MB for npm.

One-command migration

jpm install reads your existing lockfile (package-lock.json / npm-shrinkwrap.json from npm 7+, pnpm-lock.yaml from pnpm 9+, bun.lock, or yarn.lock from yarn 1 or 2+) and writes jpm.lock with the same versions. Workspaces, pnpm-workspace.yaml, catalogs, overrides, resolutions, and patches are also re

Content-addressed store and hardlinks

Tarballs are verified against their integrity, unpacked once into ~/.jpm/store, and stored by hash read-only. Packages are built once as named@version entries with a digest of their dependency graph; project node_modules just links to those entries, and warm installs make only a few links.

Approval-gated install scripts

A dependency's install scripts (the usual malware vector in npm) don't run until you run jpm approve for that package and version, and each new version requires approval again.

24-hour minimum release age

Versions published in the last day aren't picked (min-release-age), even when pinned exactly deep in the tree, so a newly hijacked release can't ride in on a pin.

No surprise dependency sources

Published packages can't pull in git or tarball dependencies or paths outside themselves — only your project and its workspaces choose where code comes from.

Lockfile integrity checks

Every package is checked against its lockfile integrity before any of its files are visible to your project, and credentials never land in jpm.lock — tokens stay in .npmrc and git URLs carrying passwords are refused.

How It Works

Run jpm install in your project

jpm imports your current npm, pnpm, yarn, or bun lockfile into jpm.lock with the same versions and tree, using no registry lookups for fully-specified lockfiles. Your old lockfile is left untouched until you're ready to delete it.

Packages are stored and built once per machine

Verified tarballs are unpacked once into a content-addressed store (~/.jpm/store); each package version is built once as an entry with its dependencies linked beside it, and every project's node_modules hardlinks to those entries — so repeat installs finish in 1–2 ms.

Security defaults apply without configuration

Install scripts stay dormant until approved, day-old releases are skipped, foreign dependency sources are refused, and packages are integrity-checked before their files become visible.

Pros & Cons

Pros

Measured 15× faster than npm on a cold nuxt install in GitHub CI (1.22 s vs 18.54 s), and fastest in 9 of 12 benchmark cells
Very low resource footprint: ~2 MB binary, 34 MB peak memory and 244 MB disk for a cold nuxt install (vs 387 MB / 443 MB for npm)
Secure defaults that don't require opt-in: script approval, min-release-age, no foreign dependency sources, pre-visibility integrity checks, and lockfiles that never hold credentials
Non-destructive migration: existing lockfiles are preserved and CI can keep installing from them until jpm.lock is committed
Custom TLS implementation tested against Project Wycheproof and RFC vectors rather than relying on OpenSSL

Who It's For

Best for

Teams optimizing CI install time and memory, where jpm's measured cold-install wins are largest
Security-conscious teams that want supply-chain protections (script approval, release-age floors, source restrictions) on by default
Projects currently on npm, pnpm, yarn, or bun looking to switch without re-resolving their dependency tree
Environments where a tiny, runtime-free binary is easier to provision than a Node.js-based package manager

Not ideal for

Workflows that need to install packages published within the last 24 hours immediately
Users who want dependency install scripts to run automatically without per-package approval

Use Cases

Speeding up npm/pnpm/yarn/bun installs in CI pipelines, where cold-install time and peak memory dominate

Reducing exposure to npm supply-chain attacks (install-script malware, freshly published hijacked versions, git/tarball dependency smuggling)

Migrating an existing project between package managers without changing resolved dependency versions

Shared machines or fleets where a per-machine content-addressed store avoids duplicating package files across projects

Integrations

npm (package-lock.json, npm-shrinkwrap.json, npm 7

pnpm (pnpm-lock.yaml, pnpm 9+, pnpm-workspace.yaml

yarn (yarn.lock from yarn 1 and yarn 2+)

bun (bun.lock)

Node.js (runtime requests verified against SHASUMS

GitHub CI (benchmarked on ubuntu-latest; install s

Windows Defender (compatible; scans jpm-written fi

FAQ

What is jpm?

jpm is a package manager for JavaScript that installs npm packages from a single ~2 MB binary, with no runtime to install, fast install times, and security restrictions enabled by default.

How do I install jpm?

On macOS/Linux run `curl -fsSL https://getjpm.sh | sh`; on Windows run `irm https://getjpm.sh/install.ps1 | iex`. Release binaries are also downloadable from GitHub.

Can I switch from npm, pnpm, yarn, or bun without changing my dependency versions?

Yes. Run `jpm install` in your project and it imports your existing lockfile (package-lock.json / npm-shrinkwrap.json, pnpm-lock.yaml, bun.lock, or yarn.lock) into jpm.lock with the same versions and tree. For npm, pnpm, and bun lockfiles it needs no registry lookups; for yarn.lock it only queries the registry for what the lockfile doesn't record (peers, platforms, bins). Your old lockfile is left untouched.

Will my CI keep working during the migration?

jpm