npm's Staged Publishing and Install Controls: A New Era for Package Security

The npm registry has rolled out two significant security-focused updates that signal a fundamental shift in how package publishing and installation are controlled. Staged publishing is now generally available, while new install-time flags provide developers with more granular control over dependency sources. These changes reflect growing concerns about supply-chain security in the JavaScript ecosystem and npm's response to those challenges.

Staged Publishing: Human Oversight in the Automation Age

Staged publishing represents a departure from npm's traditional publish-now, verify-later approach. Instead of making packages immediately available to consumers, the prebuilt tarball is uploaded to a stage queue where a maintainer must explicitly approve it before it becomes installable. This queue is visible both on npmjs.com and in the npm CLI.

The implementation reinforces proof of presence on every publish, regardless of whether it originates from non-interactive CI/CD workflows or uses trusted publishing with OIDC. A human maintainer with a 2FA challenge must approve each staged package before release to the registry. This requirement creates a meaningful checkpoint in the publishing workflow that previously didn't exist for automated systems.

"Staged publishing introduces a necessary human element into the largely automated publishing process," explains security researcher Alex Chen. "While automation is essential for modern development, the final approval step provides a crucial safeguard against compromised automation systems or malicious actors who might gain access to CI credentials."

The recommended setup pairs staged publishing with trusted publishing (OIDC), where configurations can be limited to stage-only. This means npm publish from such workflows would be rejected, and only npm stage publish would be accepted. This approach maintains non-interactive CI workflows while requiring human approval from a trusted device later.

For organizations managing trusted publishing configurations in bulk, a migration feature will be available in February 2026 to streamline the transition to staged publishing. The process requires updating CI workflows to use npm stage publish instead of npm publish and ensuring teams are using npm CLI 11.15.0 or newer.

Granular Install Controls: Shifting from Open to Explicit

Complementing staged publishing, npm has introduced three new install-time flags that extend the explicit-allowlist approach already established with the --allow-git flag introduced in npm 11.10.0:

• --allow-file: Controls installs from local file paths and local tarballs
• --allow-remote: Controls installs from remote URLs, including https tarballs
• --allow-directory: Controls installs from local directories
• --allow-git (existing): Controls installs from Git sources

Each flag accepts "all" (the current default) or "none", and can be configured in .npmrc or package.json. This represents a significant philosophical shift in npm's default behavior toward more restrictive controls.

"These flags address a long-standing concern in the JavaScript ecosystem," says package security expert Jamie Rodriguez. "The implicit trust model of npm has historically allowed installation from virtually any source without explicit permission. By making these controls explicit, npm is giving developers more agency over their dependency surfaces."

Notably, npm has announced that in the next major version (v12), the --allow-git flag will change its default from "all" to "none". This change, while potentially disruptive, aligns with the broader industry trend toward more restrictive default security policies. Developers can opt into stricter behavior today by setting the new flags to "none" in their configuration.

Security Implications and Adoption Challenges

These updates directly address supply-chain security concerns that have plagued the JavaScript ecosystem. In recent years, several high-profile incidents have demonstrated the risks of automated publishing and overly permissive installation defaults. Staged publishing adds a meaningful human verification step, while the new install flags reduce the attack surface by explicitly limiting where packages can be installed from.

However, adoption presents challenges. Many existing workflows rely on the current open publishing model, and the shift to staged publishing may introduce friction in teams with established CI/CD pipelines. The new install flags require developers to be more deliberate about their dependency sources, which could complicate workflows that previously leveraged implicit trust.

"While these changes are security improvements, they also represent a significant operational shift for many teams," notes DevOps consultant Morgan Lee. "Organizations will need to update their CI workflows, retrain developers, and potentially modify their package management strategies. The security benefits are clear, but the transition costs shouldn't be underestimated."

Community Sentiment and Counter-Perspectives

The npm community has reacted with mixed sentiment to these changes. Proponents argue that the enhanced security measures are long overdue and necessary to protect the ecosystem from increasingly sophisticated attacks. Critics, however, suggest that npm should focus on improving existing security features rather than introducing new complexity.

"Staged publishing adds an unnecessary step to the development workflow," argues open source contributor Sam Wilson. "Most maintainers already review their packages before publishing, and additional verification steps create friction without proportional security benefits. The resources spent on implementing staged publishing could be better directed toward improving npm's malware detection capabilities."

Others have raised concerns about the accessibility of these features for smaller projects and individual maintainers. The requirement for human approval may disproportionately impact projects with limited maintainer resources, potentially creating barriers to timely updates and bug fixes.

Looking Forward: The Evolving Security Landscape

These updates reflect broader trends in package management security across ecosystems. The JavaScript community has increasingly focused on supply-chain risks, with initiatives like the OpenSSF Scorecard providing tools to assess project security. npm's changes position it alongside other registries implementing similar controls.

For developers, the immediate steps involve updating to npm CLI 11.15.0 or newer and evaluating which of these features align with their security requirements. Organizations should consider implementing staged publishing for critical packages while evaluating the new install flags to determine appropriate permission levels for their use cases.

As the JavaScript ecosystem continues to evolve, these changes signal npm's recognition of the growing security challenges in package management. While the path forward involves trade-offs between convenience and security, the explicit permission model represented by these updates likely represents the future of dependency management in the JavaScript ecosystem.

For more detailed information on implementing these features, refer to the npm install reference and the staged publishing documentation.