n8n-nodes-starter: the template that makes an n8n community node publishable

Two example nodes, and they teach different things

The starter repository is described as helping you build custom integrations for n8n, and it includes example nodes, credentials, the node linter and the tooling you need to get started. The two examples are chosen to contrast two styles rather than to cover two services. The Example node is the minimal case, showing the basic structure with a custom `execute` method, which is the shape every node has when you write the request logic yourself. The GitHub Issues node is the production-ready case, built in the declarative style, and the README describes it as a low-code approach where you define operations declaratively without writing request logic. Concretely, it covers multiple resources, Issues and Comments, multiple operations, Get, Get All and Create, two authentication methods in OAuth2 and Personal Access Token, list search functionality for dynamic dropdowns, and proper error handling and typing, and it is described as ideal for HTTP API based integrations. The guidance is explicit that the declarative style is the recommended approach for nodes that talk to HTTP APIs, since it significantly reduces boilerplate and handles requests automatically. The two files together are a decision tree rather than a tutorial with one answer.

The development loop, and why you do not install n8n yourself

The local loop is one command. If you are starting from nothing, the README points at an interactive generator, `npm create @n8n/node`, which scaffolds a complete node package using the `@n8n/node-cli`, and if you already have this starter you run `npm run dev` instead. That script runs `n8n-node dev`, which builds your node in watch mode, starts n8n with your node available, rebuilds automatically when you make changes, and opens n8n in your browser, usually at http://localhost:5678. The prerequisites are short, with Node.js v22 or higher and npm, installed with nvm on Linux, macOS or WSL and with Microsoft's guide on Windows, plus git, and the recommendation to follow n8n's own development environment setup guide. One detail saves an install, and the README points it out: the `@n8n/node-cli` is a dev dependency that is installed automatically when you run `npm install`, and the CLI includes n8n for local development, so you do not need to install n8n globally. The rest of the loop is a lint step and a build step:

The commands themselves:

npm install
npm run dev
npm run lint
npm run build

`npm run lint` to check for errors, `npm run lint:fix` to auto-fix what can be fixed, and `npm run build` to compile the TypeScript into the `dist/` folder.

The package.json is the contract, and it has strict rules

When you fork the template, the manifest is where most of the platform specific knowledge lives. The package name must start with `n8n-nodes-`, and there is a keyword, `n8n-community-node-package`, that the npm search in the README relies on for discovery. The `n8n` block of the manifest is the part n8n itself reads, and in the template it declares `n8nNodesApiVersion` as 1 and `strict` as true, and then lists the credentials and the nodes by their compiled paths under `dist/`, for example the OAuth2 and personal access token credentials for the GitHub Issues node and the two node entry points. Your node has to be registered in that `n8n.nodes` array, and the README says so as a step of its own. Two more constraints are worth noticing. The published `files` array is just `dist`, so nothing but the build output ships, and `n8n-workflow` is a peer dependency, which is the standard way to say that the host application provides the workflow types rather than the package bundling its own copy. The build scripts are all thin wrappers around the CLI, `n8n-node build`, `n8n-node dev`, `n8n-node lint`, `n8n-node release` and a `prerelease` step on `prepublishOnly`.

Publishing now means proving where the build came from

The publishing section has changed recently and it is the part most likely to surprise someone with an older workflow. Publishing is handled automatically by the included GitHub Actions workflow, `.github/workflows/publish.yml`, which runs on every version tag push and publishes to npm with a provenance attestation, and the README states that this is a requirement for n8n community nodes starting May 1, 2026. The one-time setup is on npmjs.com itself, where you add a publisher under Publish access and Trusted Publishers, with the repository owner, the repository name and the workflow name `publish.yml`. The neat part is that no token or secret has to be stored in GitHub, because the workflow uses GitHub's OIDC token instead, and a traditional npm token is offered as an alternative, in which case you create a Granular Access Token on npmjs.com and store it as `NPM_TOKEN` in the repository's Actions secrets. The release itself is `npm run release`, which lints, builds and prompts for a version bump, and before it you replace the README with your own documentation using the `README_TEMPLATE.md`, add your details to the `LICENSE` file, and test the node in different scenarios.

Where to look for patterns once the template runs out

The README has a short section on finding inspiration, and its value is that it names three specific places rather than a general advice. The first is npm itself, where the search for the `n8n-community-node-package` keyword is said to surface thousands of community built nodes, which is the fastest way to see how other people solved a problem like yours. The second is the source of n8n's own built-in nodes, which the README suggests studying for production-ready patterns and best practices. The third is the credentials directory in the same tree, to see how authentication is implemented for various services. The framing is that these are resources for understanding how to structure nodes, handle different API patterns and implement advanced features. That ordering is sensible. The template teaches the packaging, the two examples teach the two authoring styles, and the built-in nodes are where you go when you need to see how a mature integration handles something the template does not cover, such as pagination, retries or a service with an awkward authentication flow.

What the template does not give you

Two gaps are worth naming, and both are normal for a starter rather than problems with it. The first is that there is no test script in the manifest. The available scripts are build, a watch build, dev, lint, lint fix, release and a prerelease step, and the repository has a `CHANGELOG.md`, a code of conduct, a prettier configuration, an eslint flat config, a tsconfig and the `icons/` directory, but the package scripts do not include a test runner, so the testing guidance in the publishing checklist is a sentence rather than a command. If your node has real logic, you will want to add your own test setup, and the built-in node sources are where to look for how n8n does it. The second gap is the obvious one, that both example nodes are meant to be replaced. The GitHub Issues node is a worked example with two resources and three operations, and the README's instruction is to edit the example nodes to fit your use case or to copy the structure from the Example node into new files. The template's value is entirely in the plumbing around the node, and the plumbing is where the platform's real requirements live.

Editorial conclusion

Adopt n8n-nodes-starter as the starting point for any custom n8n node, since it encodes the packaging contract, the lint rules and the publish workflow that the platform expects. Do not adopt it as a library, because it is a template you fork and then replace, and do not expect it to carry a test suite, since the package scripts cover building, linting and releasing but not testing. Before you publish, set up npm Trusted Publishers for the repository and the `publish.yml` workflow, because from May 1, 2026 n8n community nodes require a provenance attestation, and the alternative is storing a Granular Access Token as `NPM_TOKEN`. Also decide early between the declarative style and hand written request logic, since the README recommends the declarative style for HTTP API integrations and it removes most of the boilerplate. The licence is MIT, the last push was on 2026-09-13, and the repository publishes no GitHub releases.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. n8n-io/n8n-nodes-starter on GitHub
4. README