n8n Community Nodes: Installing, Building and Publishing Custom Nodes

n8n natively covers several hundred integrations, but a niche business tool — a vertical CRM, an internal ERP, a small SaaS API — never quite makes the list. That leaves two options: hack the call together with an HTTP Request node every time, or install (or even build) a Community Node: a real node with its own icon, typed parameters, and autocomplete, behaving just like a native one. This article covers both angles: safely installing an existing community node, and building one from scratch when nothing fits your use case.

What a Community Node actually is

A Community Node is a public npm package that follows the n8n-nodes-* naming convention (for example n8n-nodes-notion-enhanced or n8n-nodes-airtable-extended). Technically, it's compiled TypeScript code implementing n8n's INodeType interface: a description of the parameters shown in the UI, and an execute method that receives input data and returns output — exactly like native n8n-nodes-base.* nodes.

The only real difference from a native node is maintenance and vetting: a native node is maintained and audited by the n8n team, a community node is published and maintained by any third-party developer — including you.

Installing a community node

On a self-hosted instance, there are two paths:

• From the UI: Settings > Community Nodes > Install. Just enter the npm package name (n8n-nodes-my-package); n8n installs it and reloads the node rendering process automatically, without a full instance restart in most cases.
• Via an environment variable, useful for a reproducible Docker setup: running npm install n8n-nodes-my-package inside the image build before startup, so the node is available the moment the container first launches, without depending on the UI at all.

On n8n Cloud, installing from the UI only accepts packages that have earned the verified badge from the n8n team — a restricted, audited list, shown directly in the installation panel. This is a structural Cloud limitation worth knowing before committing to it if your stack depends on an unverified community node: see our self-hosted vs Cloud n8n comparison to weigh this criterion against everything else before picking your hosting.

Install options at a glance

	Self-hosted	n8n Cloud
Install from the UI	Any n8n-nodes-* npm package	Verified packages only
Install via Docker build / npm	Yes	No
Unverified packages	Yes (at your own risk)	No
Who carries the security risk	You	n8n's audit process

Security: what a community node can really do

A community node runs inside the same Node.js process as n8n itself, with the same privileges. Concretely, a malicious or compromised package can:

• read the server's environment variables, including secrets never meant to be exposed to nodes;
• make arbitrary network calls to any destination, in the open or hidden inside an otherwise legitimate request;
• in some cases, reach credentials decrypted in memory during the execution of a workflow that uses them.

This isn't theoretical: a study by Zimmermann, Staicu, Tenny, and Pradel, presented at the USENIX Security Symposium in 2019, analyzed the npm ecosystem as a whole and showed that a small number of maintainers, some with poorly secured accounts, concentrate the implicit trust of hundreds of thousands of downstream packages — a single compromised maintainer account is then enough to spread malicious code at massive scale (Zimmermann et al., 2019, USENIX Security Symposium). The npm supply chain has in fact already been the target of packages compromised after the fact, including popular packages hijacked through a maintainer's account — exactly the scenario this study models at the scale of the whole ecosystem. Three habits to follow before installing an unverified community node in production:

• Check its reputation: npm download count, last update date, GitHub issue history, and whether there's an identifiable, active maintainer.
• Prefer verified nodes whenever an equivalent exists — the badge means n8n has audited the code and commits to watching future updates.
• Isolate the instance if an unverified community node is unavoidable: a dedicated self-hosted instance without access to other workflows' sensitive credentials limits the blast radius of a compromise.

Community node vs. a plain HTTP Request: when it's worth it

Building a dedicated node isn't always justified. A well-configured HTTP Request node (n8n-nodes-base.httpRequest), with a Set node upstream to build the URL and body via n8n expressions ({{ $json.id }}), effortlessly covers most one-off API integrations.

A custom node earns its place when:

• the logic goes beyond a single call — pagination across multiple pages, fine-grained error handling by HTTP status code, or a response transformation applied consistently every time;
• authentication is complex and would otherwise be reimplemented in every workflow calling that API (request signing, a proprietary OAuth token refresh) — a node encapsulates that logic once, for good;
• a dedicated UI adds real value — dropdowns that query the API to surface valid values (n8n's loadOptions) instead of forcing users to type an ID by hand;
• several people on the team will reuse this integration: a node published internally, even on a private npm registry, saves everyone from reinventing the same piece of code.

Building your own node: the main steps

n8n ships an official starter, n8n-nodes-starter, cloned from GitHub, that scaffolds the whole project structure.

1. Clone the starter and open it: the standard layout puts each node in nodes/MyNode/MyNode.node.ts, with its assets (an SVG icon) in the same folder, and any credentials in credentials/MyApi.credentials.ts.

2. Describe the node in the class implementing INodeType: a description object with displayName, name, icon, group, and — most importantly — properties, the array defining every parameter shown in the UI (text, number, static dropdown, or dynamic dropdown via loadOptions).

export class MyNode implements INodeType {
  description: INodeTypeDescription = {
    displayName: "My Node",
    name: "myNode",
    group: ["transform"],
    version: 1,
    properties: [
      {
        displayName: "Client ID",
        name: "clientId",
        type: "string",
        default: "",
      },
    ],
  };
}

3. Implement execute: the method called on every run, reading parameters via this.getNodeParameter(), making the call (often with this.helpers.httpRequest, the n8n utility that automatically handles credentials attached to the node), and returning an array of INodeExecutionData.

4. Test it locally: npm link the package into a local n8n instance (N8N_CUSTOM_EXTENSIONS pointing at the dev folder), so you can iterate without republishing on every change.

5. Publish to npm with a name following the n8n-nodes-* convention — a hard requirement for n8n to recognize the package as an installable node from the Community Nodes UI.

For anything beyond this overview, n8n's official node-building documentation details every properties field and available hook (loadOptions, credentialTest) more thoroughly than a single article can.

Community nodes vs. AI Agent custom tools: two different mechanisms

Don't confuse a classic community node with a custom tool for an AI Agent: the latter doesn't require publishing an npm package at all — it's built directly inside a workflow with a Custom Code Tool node or a Sub-workflow exposed as a tool. Our article on building custom tools for AI Agent in n8n covers that specific case, which is much faster to set up when the need stays internal to a single workflow or team.

Wrapping up

A well-chosen community node turns a repeated API call into a clean, typed, reusable building block — as long as you check its reputation and keep unverified nodes to self-hosted instances you control. On n8n Cloud, only verified nodes are installable, a criterion worth weighing when you first choose your hosting. If your team builds AI workflows more often than raw API integrations, take a look at the RAG Assistant Pack ($79), which already packages several of these building blocks ready to adapt.