According to the npm docs I read on 19 October 2026, publishing with provenance requires a supported cloud CI/CD provider and a cloud-hosted runner, and trusted publishing says self-hosted runners are not currently supported but are planned. If your release job runs on your own runners, check the live docs before you plan around either feature.
What the docs state
Two npm pages are relevant.
The provenance page says that to publish a package with provenance you must build with a supported cloud CI/CD provider using a cloud-hosted runner, and names GitHub Actions and GitLab CI/CD. It also requires npm CLI 9.5.0 or later and a package.json repository field that matches, case-sensitively, where you publish from.
The trusted publishing page lists the supported environments: GitHub Actions on GitHub-hosted runners, GitLab CI/CD on GitLab.com shared runners, and CircleCI cloud. It says self-hosted runners are not currently supported but are planned. It also requires npm CLI 11.5.1 or later and Node 22.14.0 or higher.
| Feature | Supported today per docs | Self-hosted runners |
|---|---|---|
| Provenance with the provenance flag | GitHub Actions, GitLab CI/CD, cloud-hosted runners | Not supported |
| Trusted publishing (OIDC, no long-lived token) | GitHub-hosted, GitLab.com shared, CircleCI cloud | Not currently supported, planned |
Pages change. These facts are dated, so confirm them before you rely on them.
Why the restriction exists
Provenance rests on an identity the build system proves to Sigstore through an OIDC token. A cloud-hosted runner gives a verifiable statement about the environment. A machine you run yourself is harder for an outside party to vouch for. Our post on who you trust when you verify SLSA provenance explains that trust question in general.
Options if you self-host
- Split the pipeline. Build and test on your own runners, and run the publish step as a separate job on a supported cloud-hosted runner. Be careful that the artifact you hand over is the one you tested, for example by publishing from the tagged commit and rebuilding there.
- Keep token publishing, harden it. Use a granular, short-lived token, restrict it to one package, and keep it in a protected environment. See which npm token settings for a CI publish job.
- Wait and watch. The docs say self-hosted support is planned. Build your workflow so switching is a small change.
- Add your own record. Generate and archive your own SBOM and build record per release, even without npm's attestation. See archiving SBOMs and provenance for every release.
What not to do
Do not copy an attestation or fake the repository field to make a badge appear. A provenance statement that claims a build it did not describe is worse than none. And do not read the absence of provenance as proof of compromise: many safe packages do not publish with it.
For consumers
If you consume packages, you can check what is available with the audit signatures command, which verifies registry signatures and attestations for packages that have them. If you adopt a pnpm trust policy, remember it only fails on a decrease in trust evidence, as covered in pnpm trustPolicy.
Where Safeguard fits
Safeguard's SBOM and dependency scanning, and compliance and evidence automation, help you keep per-release component records that you can show a customer, whatever your CI setup. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Do I need provenance to use trusted publishing?
No. They are related. The npm docs note that trusted publishing generates provenance attestations automatically without the provenance flag, and it removes the need for long-lived tokens.
Is the self-hosted limitation permanent?
The docs say self-hosted runners are not currently supported but are planned. Check the live page before deciding.
Sources
Last reviewed: 19 October 2026.
