For most projects, publish from CI using trusted publishing, because no long-lived token exists to steal and the release is tied to a specific workflow. Publish from a laptop only when you need a human prompt on every release, and then require 2FA and disallow tokens.
The two models
Laptop publishing means you run the publish command yourself after a 2FA prompt. CI publishing means a workflow does it when you push a tag, and the registry trusts that workflow through OpenID Connect (OIDC).
npm's own guidance lists the options it intends to leave for publishing: local publishing with required 2FA, granular tokens with a limited lifetime of seven days, and trusted publishing. The GitHub post describes this as a plan with gradual rollout, so check current npm documentation for what applies to your account today.
What each model protects against
| Threat | Laptop with 2FA | CI with trusted publishing |
|---|---|---|
| Token leaked from a CI secret | No token needed | No stored token to leak |
| Malware on a developer machine | Exposed, since the session and keys live there | Less exposed, publish happens elsewhere |
| Stolen password alone | Blocked by 2FA | Not relevant to the CI path |
| Malicious workflow edit | Not relevant | Exposed, so protect the workflow |
| Release made by mistake | Human sees prompt | Tag push can trigger it, so add a reviewer gate |
| Provenance for consumers | Not generated | Generated automatically on supported providers |
The last row comes from npm's trusted publishing page, which says provenance is generated automatically for GitHub Actions and GitLab publishes from public repositories of public packages, and not for private repositories.
When laptop publishing still makes sense
- Your registry does not support trusted publishing for your CI provider.
- You release rarely and want a deliberate human step.
- You use a hardware key and a clean, dedicated machine.
When to choose CI
- You release often.
- More than one person can release.
- You want provenance on each version.
If you pick CI, treat the workflow as the crown jewel. Pin actions, set job level permissions, add an environment with required reviewers and use CODEOWNERS. These are covered in the release workflow permissions guide, required reviewers for deployment approval and CODEOWNERS for workflows.
A hybrid that many projects use
Let CI do the publish, but disallow tokens on the package so a leaked token cannot be used from anywhere else. npm's trusted publishing page recommends setting publishing access to require 2FA and disallow tokens, and states this does not affect OIDC publishing. Details are in what disallow tokens does on npm.
Decision steps
- Does your registry support trusted publishing for your provider? If no, use laptop with 2FA.
- Do you want provenance? If yes, use CI.
- Do you have a second person who can review release workflow changes? If no, add a ruleset and consider two person review options.
- Remove old tokens either way.
Safeguard can scan the dependencies that go into each release and gate pull requests, and the free scan at gold.safeguard.sh/scan is a fast start.
Quick check
Is CI publishing safe if my repository is compromised?
No. A compromised repository or workflow can publish. That is why workflow protection and reviewer gates matter.
Do I need provenance to use CI?
No, but trusted publishing on supported providers generates it automatically for public packages from public repositories.
Sources
Last reviewed: 19 October 2026.
