npm staged publishing adds a human approval gate for package releases
npm CLI 11.15.0 adds generally available staged publishing plus explicit install-source controls, giving maintainers a safer release path for JavaScript packages and CI/CD workflows.
GitHub has made npm staged publishing generally available and added new install-source controls in npm CLI 11.15.0. The change lets maintainers upload a package version to a staging queue before it becomes installable, then require a maintainer approval step with 2FA. For teams shipping JavaScript packages from CI, the practical shift is that automation can prepare a release while a human still approves what reaches the public registry.
Key takeaways
- Staged publishing is generally available for existing npm packages and requires npm CLI 11.15.0 or later.
npm stage publishsubmits a package to a staging area instead of immediately publishing it to the live registry.- A maintainer must approve the staged package with 2FA from the CLI or npmjs.com before consumers can install it.
- New
--allow-file,--allow-remote, and--allow-directorycontrols join the existing--allow-gitflag for non-registry install sources. - Teams using trusted publishing can combine OIDC-based CI releases with a separate human approval gate.
Practical LinkLoot angle
This is useful for teams that want CI to build repeatable package artifacts without giving automation the final say over public release timing. A safer workflow is: build and test in CI, run npm stage publish, review the staged tarball, then approve it from a maintainer account with 2FA. That gives you a pause point to inspect package contents, provenance, version metadata, and accidental file inclusion before the package becomes installable.
| Option | Best use | Limitation | Source |
|---|---|---|---|
npm publish | Fast direct releases for low-risk packages | Publishes immediately when permissions and checks pass | npm publish docs |
npm stage publish | CI-built releases that need human approval | Only works for packages that already exist on npm | npm staged publishing docs |
| Trusted publishing plus staged approval | OIDC-based CI with a human release gate | Requires updated trusted-publisher permissions and npm CLI support | GitHub Changelog |
--allow-* install-source flags | Hardening installs against non-registry sources | Defaults may still need explicit tightening in project config | GitHub Changelog |
Why it matters
Package registries are high-value targets because a compromised release can reach downstream apps quickly. Staged publishing reduces the blast radius of a stolen CI token or mistaken publish command by separating artifact creation from final registry approval. The install-source flags also help teams make dependency resolution more explicit, especially when they want to block local paths, remote tarballs, directories, or Git dependencies during installs.
For a practical rollout, start with one maintained package rather than flipping every workflow at once. Update CI to npm CLI 11.15.0 or newer, replace direct publishing with npm stage publish, and document who approves staged packages. Then add stricter install-source settings in .npmrc or package configuration where your build should consume only registry packages.
What to verify before you act
Check package eligibility first: npm’s staged publishing docs say the package must already exist on the registry, the maintainer needs publish access, and 2FA must be enabled. Verify your Node and npm versions because the docs list Node 22.14.0 or higher and npm CLI 11.15.0 or later for staged publishing. If you use trusted publishing, review whether your trusted-publisher configuration permits staging only, because GitHub’s announcement says stage-only configurations can reject direct npm publish from that workflow.
Also inspect the staged tarball before approval. Use the CLI review flow to list, view, or download staged packages, then compare the tarball contents against what you expect from npm pack --dry-run. Finally, test --allow-file=none, --allow-remote=none, --allow-directory=none, and --allow-git=none in CI before enforcing them broadly, because legitimate monorepo, local tarball, or Git dependency workflows may break.
It is an npm release flow where a package is uploaded to a staging area and must be approved with 2FA before it becomes available on the registry.
If you are tightening release automation, pair this with LinkLoot’s guide to AI workflow automation so approval steps, CI checks, and human review stay visible instead of becoming hidden tribal knowledge.