npm trusted publishing is configured on each package, not on the repository. You name the GitHub organization, repository and workflow filename that may publish it. In a monorepo, that means repeating the setting for every package, pointing them at one tightly controlled publish workflow, and updating them if you rename or move that workflow.
What the setting contains
The npm documentation describes trusted publishing as a trust relationship between npm and your CI provider using OpenID Connect, so you do not need long-lived npm tokens. For GitHub Actions you enter an organization or user, a repository, a workflow filename, and optionally an environment name. The filename is the name only, with the .yml or .yaml extension, and the file must exist in .github/workflows/. The docs also state that trusted publishing needs npm CLI 11.5.1 or later and Node 22.14.0 or higher, and that self-hosted runners are not currently supported.
Each package can have up to 10 trusted publishers configured, according to the docs.
Why monorepos need extra care
Moving ten packages from ten repositories into one means ten existing settings now point at repositories that no longer publish. Publishing will fall back to whatever other authentication still exists, or fail. Meanwhile new settings must name the monorepo.
The risk is the shortcut. If any workflow in the repo could publish any package, a change to an unrelated workflow file becomes a route to your registry.
Steps
- Create one publish workflow for the monorepo, for example
publish.yml, and keep it as small as you can. - Protect that file. Give it a CODEOWNERS entry for the release team, as covered in CODEOWNERS for workflows and release files.
- For each package, open its settings on npmjs.com and add the trusted publisher with the monorepo name and that filename.
- Add an environment name, such as
npm-release, and put required reviewers on that environment so a human approves each release. - Remove the old repository's trusted publisher entry from each package.
- Remove any stored npm tokens that are no longer needed, once a test publish through the new path works.
- Publish a prerelease version of one package to confirm before the rest.
Keep private packages private
Moving code into a workspace is a good moment to check names. npm's scope documentation says unscoped packages are always public and private packages are always scoped. Internal packages that must never be published should also carry private: true in their manifest, as explained in private true and files stop accidental npm publish.
After the move
Record which package maps to which workflow, and review the list when the release workflow is renamed. Safeguard's SBOM and dependency scanning can show what each published package ships, and policies and gates can check pull requests that touch the release workflow.
Plan for the rollout order
Do not switch every package on the same day. Start with a low-risk internal or rarely changed package, publish a prerelease through the new path, and check the provenance and the logs. Then move packages in groups. Keep a table with the package name, the workflow filename it trusts, the environment, and the date it was switched. If a package still accepts old tokens, that table is also your list of what to revoke next.
Quick check
Is the npm trusted publisher set once per repository?
No. It is set per package, so every package in the monorepo needs its own entry.
Does the workflow field take a full path?
No. Enter the filename with its extension, and the file must live in the workflows directory.
Sources
Last reviewed: 19 October 2026.
