How I Check an n8n Community Node Before Installing It

Before installing an n8n community node, I check the exact npm package and version, who published it, where the source lives, what code the package will run, and whether its setup instructions match the service's API. I also check whether my n8n environment can install that type of node. If any of those answers is unclear, I stop before adding the package to a workflow with real credentials.

n8n's community-node risk guidance says an installed community node can access the machine running n8n and workflow data. That makes the package itself the thing to review. A directory listing, a polished README, or an npm download count cannot tell you what the published tarball does.

Check how your n8n instance can install it

n8n has separate routes for verified nodes and packages installed from npm. Verified community nodes can appear in the nodes panel. On self-hosted n8n, an owner or admin can also install a package from npm through Settings > Community Nodes, subject to instance configuration. The official GUI installation instructions explain that flow and allow a specific version to be entered.

Do not read “published on npm” as “verified by n8n” or “available on n8n Cloud.” n8n Cloud only offers verified community nodes. Check the node's current verification state and your instance's allowed installation route.

n8n 3.0 tightens this further. N8N_UNVERIFIED_PACKAGES_ENABLED now defaults to false, so a self-hosted instance cannot install unverified packages from npm, and unverified packages that are already installed stop loading after the upgrade. An admin can set the variable to true to allow them again, but that turns the review in this article from good practice into the only safeguard. The n8n community node verification guide explains what n8n's review covers. If your team does not control installation settings, settle that question before spending time on the package.

The NativeShip node directory is a starting point for finding a service-specific node. Follow each listing to the exact npm package and source repository before installing. A directory entry is a discovery aid, not an approval badge.

Match the npm package to its source

Copy the full scoped or unscoped package name, then inspect a specific version. Look at the npm publisher, repository URL, license, release date, package scripts, and declared dependencies. Follow the repository link and check that it is public, belongs to the expected maintainer, and has code corresponding to the release. Do not assume the current default branch is identical to a tarball published days or weeks earlier.

I checked @nativeship/n8n-nodes-tidycal on npm on 20 October 2026. The latest registry version was 1.0.1, published 15 October. Its metadata pointed to a public NativeShip GitHub repository, declared an MIT license, listed no ordinary runtime dependencies, and included a provenance attestation URL. The package scripts shown in metadata were for development, linting, and building; I did not see an install lifecycle script there. These are useful observations, not a security clearance. A dependency field does not reveal every line bundled into compiled JavaScript, and an attestation does not establish that API operations work.

Check	What it can tell you	What it cannot tell you
Exact package name and version	Which artifact you plan to install	Whether that artifact behaves as described
Publisher and repository	Who controls the release account and where source is presented	Whether source on the current branch matches this release
Dependencies and install scripts	Additional packages and code that may run during installation	Every behavior in bundled or compiled files
Provenance	Which source and build workflow produced a release, if the attestation validates	Whether the node is secure, n8n-verified, or correct
README and issue history	How users are told to configure and report problems	Whether the documented workflow was actually tested

If the repo has no release tag or the package includes generated files, compare the tarball with the source commit named by provenance. If you cannot make that comparison, record the gap instead of treating “open source” as proof of what npm serves.

Run n8n's package scanner

n8n publishes the same static scanner it uses during verification. Run it against the exact package name before you install:

npx @n8n/scan-community-package @scope/n8n-nodes-example

The scanner checks the published package for patterns n8n does not allow in verified nodes, such as reading environment variables or the file system. A pass is a useful minimum, not a security audit, and a fail is a clear reason to stop. The verified community node checklist lists the rest of n8n's rules (no runtime dependencies, public MIT-licensed repository, matching npm and GitHub metadata, English-only UI) so you can check an unverified package against the same bar.

Read provenance as one narrow signal

The TidyCal 1.0.1 registry metadata includes an attestation URL. npm's provenance feature can connect a package to a source repository, commit, and publishing workflow. The NativeShip article on trusted publishing and provenance explains why that matters for the release path.

I have not run a local signature audit for this article. The metadata's attestation URL is evidence that an attestation was published, not a claim that I verified its signature. Even a valid attestation would answer where the package came from. It would not show that the compiled node calls the right API host, handles credentials, or keeps working after the service changes.

Compare the README with the actual API and package

This is where the TidyCal example changes my decision. The repository and packaged README say no credentials are required. The compiled 1.0.1 node declares no n8n credential and has a placeholder API destination. TidyCal's API documentation says API access requires a paid plan and authenticated requests. The documented setup and published node do not provide a tested path to those authenticated operations.

I would pause an install intended for a real TidyCal workflow. This is an observed configuration mismatch, not an accusation about the publisher or a claim that the package is malicious. A corrected release and an authenticated n8n execution would give users something stronger to evaluate. For a different package, the same comparison applies to callback URLs, permissions, required IDs, pagination, and claimed actions.

A good README answers these questions before you install; the README checklist lists what to expect. Look for a first-run example with the exact resource and operation names shown in n8n, required credentials, safe input values, expected output, and a known failure. If the README only says “add the node and run it,” you may need to inspect the code or ask the maintainer for a working example before connecting production data.

Look for evidence of maintenance

Review release dates, changelog entries, issue reports, and responses to bug reports. A recent publish is evidence of activity, not of quality. Zero open issues could mean a clean project, a new project, or no user reports. A high download count does not prove that users completed a working workflow.

For an API integration, check whether the package still uses the service's current authentication method and endpoints. If the service changed its API, ask which package version contains the fix. Pin the version you test so a later update cannot silently change the code you reviewed. Keep a way to report a reproducible problem: n8n version, package version, operation, redacted input, and error text.

Test with limited access before relying on it

After the review, install only through a route your n8n instance supports. Use a nonproduction instance or test account when available, give the node the narrowest service permission that supports the test, and run one read operation first. Check the request destination and returned data. Then try a controlled write only if you need that action. Do not paste production tokens into screenshots or public issues.

If the node does not appear after installation, follow the NativeShip node visibility guide and check n8n's current installation guidance for your deployment. Treat an installed package, a node visible in search, and a successful API execution as three separate observations.

For the TidyCal package reviewed here, the authentication and destination mismatch stops the process before a working-workflow claim. I would revisit the exact new npm version after those fields are corrected and a redacted authenticated test is available.