What Is Trusted Publishing for n8n Community Nodes?

If you’re building an n8n community node, you’ll eventually run into something called Trusted Publishing.

At first, it sounds like another thing you need to configure before you can publish your node.

But it’s actually pretty simple.

Trusted Publishing is about proving that you are actually allowed to publish a package to npm.

And that matters because n8n community nodes are installed from npm. From May 1, 2026, n8n requires every community node, verified or not, to be published from a GitHub Action with npm provenance. Trusted Publishing is the simplest way to meet that rule.

So, what is Trusted Publishing?

Normally, publishing an npm package looks something like this:

You have your package → you log in to npm → you use an npm token → npm publishes your package.

The problem is that npm tokens are long-lived credentials.

If that token ends up in the wrong place, someone could potentially use it to publish packages using your account.

Trusted Publishing takes a different approach.

Instead of storing an npm token inside your GitHub Actions workflow, npm can trust a specific CI/CD workflow to publish your package.

For example:

GitHub repository
       ↓
GitHub Actions
       ↓
npm Trusted Publishing
       ↓
Your n8n community node

So your GitHub Actions workflow can publish the package without keeping a permanent npm publishing token in your repository.

That’s the basic idea.

Why does n8n care about this?

Because an n8n community node is code that other people are going to install and run.

When someone installs:

npm install your-n8n-node

they are trusting that package.

They are not just downloading some JSON file.

They are installing JavaScript that can run inside their n8n environment.

That makes the publishing process important.

n8n wants community nodes to come from a legitimate npm package and follow the expected publishing process.

Trusted Publishing helps connect the dots between:

your source code → your build → your npm package

without relying on a manually copied npm token sitting inside your GitHub repository.

Does Trusted Publishing mean n8n publishes my node?

No.

This is an important distinction.

Trusted Publishing is mainly an npm publishing security mechanism.

You still own your GitHub repository.

You still own your npm package.

Your CI/CD workflow builds and publishes the package.

Self-hosted users can install the package from npm. To appear in the n8n nodes panel and on n8n Cloud, it also has to pass n8n's separate verification review. From n8n 3.0, self-hosted instances also block unverified packages by default, so verification matters more than it used to.

Think of it as proving:

“This package is being published by the repository and workflow that are authorized to publish it.”

What does the setup look like?

A typical setup looks something like this.

1. Create your npm package

Your n8n node has its normal package.json.

For example:

{
  "name": "n8n-nodes-example",
  "version": "1.0.0"
}

2. Put the project on GitHub

Your generated or manually created n8n node lives in a GitHub repository.

3. Configure npm Trusted Publishing

You tell npm which GitHub repository and workflow are allowed to publish the package.

For example:

GitHub repository
→ your-account/n8n-nodes-example

Workflow
→ publish.yml

4. GitHub Actions publishes the package

When you release a new version, GitHub Actions builds the node and publishes it to npm.

No npm publishing token needs to be stored as a GitHub secret.

That's the nice part.

Trusted Publishing vs provenance

These two terms are often mixed up:

Term	What it is	What it proves
Trusted Publishing	npm accepts a short-lived OIDC identity from a named GitHub workflow instead of a stored token	The publish came from the workflow you allowed
Provenance	A signed statement attached to the npm release	Which repository, commit and workflow built this exact tarball

n8n's rule is about provenance: the package must be built and published by GitHub Actions with a provenance statement. When you publish through Trusted Publishing from a public repository, npm generates provenance automatically. You can also get provenance with a token and npm publish --provenance, but then you are back to storing a long-lived secret. The npm provenance publishing guide covers both paths.

A minimal publish workflow

The npm create @n8n/node scaffold includes a publish workflow. A minimal version looks like this:

name: Publish
on:
  push:
    tags: ['v*']
permissions:
  contents: read
  id-token: write   # lets the job request the OIDC token npm checks
jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 24
          registry-url: 'https://registry.npmjs.org'
      - run: npm ci
      - run: npm run lint
      - run: npm run build
      - run: npm publish

There is no NODE_AUTH_TOKEN secret. On npmjs.com, open the package's Settings, add a Trusted Publisher for GitHub Actions, and enter your GitHub user or organization, the repository name, and the workflow file name (publish.yml). Trusted Publishing needs a recent npm CLI (11.5.1 or later), which is why the workflow uses a current Node.js version.

Two details catch people out. The repository field in package.json must match the GitHub repository that runs the workflow, or npm rejects the provenance. And npm can only configure a trusted publisher for a package that already exists, so for a brand-new package, check npm's current docs for how to handle the first release.

Why is this better than just using an npm token?

Because fewer long-lived secrets are involved.

With the traditional approach, you might have:

npm token
   ↓
GitHub Secret
   ↓
GitHub Actions
   ↓
npm

With Trusted Publishing:

GitHub Actions
   ↓
Trusted identity
   ↓
npm

The workflow gets permission based on its identity and configuration rather than carrying around a permanent publishing token.

It's a small change, but it makes automated publishing much safer.

What about n8n community nodes?

This is where things become especially important.

If you're building a community node yourself, you can manually handle the GitHub repository, npm package, workflow, and publishing setup.

But if you're building a platform that generates n8n community nodes for other people, things get more interesting.

You shouldn't publish everyone's node through one npm account.

The generated node should ultimately belong to the person who created it.

That means the user should have control over:

• Their GitHub repository
• Their npm package
• Their publishing workflow
• Their npm account

This is one reason a GitHub-based publishing flow makes sense.

The platform can help prepare the repository and workflow, while the user keeps ownership of the actual package.

And this is where NativeShip comes in

Honestly, creating an n8n community node isn't that difficult because of the code alone.

It's all the small things around it.

You need to:

• Understand the n8n node structure
• Generate the node
• Build it
• Validate it
• Create a GitHub repository
• Configure publishing
• Set up Trusted Publishing (the files an n8n community node needs include the publish workflow)
• Publish the npm package
• Keep the package updated when your API changes

That's a lot of steps for something that should feel simple.

NativeShip is built to make this whole process easier.

You start with what you already have, and NativeShip helps turn it into an n8n community node without making you manually deal with every part of the process.

Instead of spending your time figuring out:

“How do I structure this node?”

“What needs to go into package.json?”

“How do I build this?”

“How do I connect GitHub?”

“How do I publish this to npm?”

you can focus on the thing that actually matters:

the integration you want to give your users.

NativeShip handles the boring parts around node creation and publishing, while you keep ownership of your GitHub and npm accounts.

That's the idea.

Make the whole journey from idea → n8n node → published package much simpler.

One thing people often misunderstand

Trusted Publishing doesn't magically make an n8n node trusted.

It doesn't mean:

“npm trusted this node, therefore n8n says it's safe.”

That's not what it means.

Trusted Publishing answers a much narrower question:

Who is allowed to publish this npm package?

n8n has its own requirements and review/distribution process for community nodes.

So think of Trusted Publishing as one part of the publishing chain, not a security certificate for your entire node. Users should still check a community node before installing it, and n8n still scans and reviews nodes before verifying them.

The simple way to think about it

If I had to explain Trusted Publishing to a friend, I'd say:

Trusted Publishing lets your GitHub workflow prove to npm that it's authorized to publish your package, without keeping a long-lived npm publishing token in GitHub.

That's really it.

And when you're building n8n community nodes, it's useful because your node is ultimately an npm package that other people's n8n installations will download and run.

So the publishing chain needs to be secure, traceable, and controlled by the package owner.

That's why Trusted Publishing matters.

And if you don't want to spend your weekend figuring out GitHub Actions, npm publishing, node builds, and all the little pieces around it, that's exactly the problem we're trying to solve with NativeShip.

Build the node.

Let the boring parts be boring.