Starbase / 02 RecipeAgents

RecipeAgents / n8n community nodes / Most used / Methodology

Last refresh Oct 30, 2026

How we rank n8n community nodes

The ranking measures usage and staying power from public data. It doesn't measure quality, and nobody pays to be in it or to move up.

What it ranks

npm packages tagged n8n-community-node-package. Each month we take the 120 with the most monthly downloads in the npm registry search, keep those with at least 1,000 typical downloads per 28 days and either at least one community forum thread naming the package or a place in n8n's verified node catalog (so vendor-built nodes like ElevenLabs qualify without forum chatter). Names with test, trial or demo are dropped, and score the ones at least 6 months old. Younger packages go in the "new and rising" list without a score.

Sources

  • npm downloads API (api.npmjs.org): daily downloads for the last 365 days.
  • npm registry: first publish date, latest release date, releases in the last 180 days.
  • n8n community forum (community.n8n.io search): number of threads that name the package.

How the score is built

  1. Usage (40 points). Typical downloads per 28 days = median daily downloads × 28. Scored on a log scale from 1,000 up to the top package, so 10× more downloads adds a fixed step instead of crushing everyone else.
  2. Staying power (30 points). The current level as a share of the level 3 months ago and 6 months ago, each capped at 100%, averaged. A package that held gets full points; one that dropped by half gets half. Growth earns nothing extra, so a sudden surge can't buy a top spot.
  3. Problems (15 points). Forum threads naming the package per 100,000 downloads over the year (with spikes capped). Fewer threads per download scores higher. Low, Medium and High are thirds of the list. Packages with no threads at all are labelled "Not discussed" and get a neutral middle score, not a perfect one.
  4. Upkeep (15 points). Days since the newer of the latest npm release and the latest GitHub code push: up to 90 days full points, up to 180 = 70%, up to a year = 40%, older = 10%.

Score = the weighted sum, out of 100. Ties go to the package with more downloads.

Retention and churn columns

Kept after 3 / 6 months is retention: the current download level (median day in the last 28 days) as a share of the level 3 months ago and 6 months ago, capped at 100%. These are the same two numbers the staying-power points use. Lost after 3 / 6 months is churn: 100% minus retention, for the same two windows. A package with 70% kept after 6 months shows 30% lost.

  • This is download churn, a drop in the download level. It isn't user churn: npm doesn't say who downloads a package, and one install can count many times.
  • Because retention is capped at 100%, a package that grew shows 0% lost, however much it grew. The change vs 6 months ago is in each row's detail.
  • The Sticky, Holding and Fading label next to retention uses the lower of the two kept numbers: Sticky at 90% or more, Holding at 60 to 90%, Fading under 60%.

Month-over-month churn chart

Each expanded row has a second chart under the daily downloads. We cut the last 364 days into 13 back-to-back 28-day blocks ending on the data end date and take the median daily downloads in each block as its level. Churn for a block is the share of the previous block's level that is gone: 1 − level ÷ previous level, shown as 0% when the level grew (marked "grew"). Blocks before the package was first published, or where the previous level was under 3 downloads a day, are shown as grey "not enough data" gaps. It is computed in your browser from the same daily series as the first chart. It measures downloads, not users.

Categories

Every tracked package gets one broad category (Communication, AI and Language Models, Data and Storage, E-commerce and Payments, Marketing, Productivity, Web and APIs, Media, DevOps) from a fixed, hand-checked table by package name. Categories only filter the list; they never change scores or order.

Cleaning

Median days instead of totals, so one-day bursts from CI servers or mirrors don't move the ranking. For the yearly problem rate, any day above 3× its trailing 28-day median is capped. Packages with a burst over 20× the median are marked "Spiky downloads" (badge only, no penalty). Packages whose downloads rose over 6× in 6 months while having under 50 GitHub stars and no vendor backing get a "Sudden jump" badge and lose a quarter of their score, because that pattern usually means automated installs. We tested a "too flat" check too and dropped it: real, steady products look flat.

Limits

  • Downloads aren't users. Automated installs, Docker rebuilds and mirrors count.
  • Self-hosted instances that cache packages, and verified nodes installed through n8n Cloud, may not show up in npm the same way.
  • Forum search matches the package name, so threads can be questions, not bugs, and the count tops out at one search page.
  • Popular doesn't mean best for you, or safe. Check the install risks.

Refresh

Monthly, at the start of the month. The date at the top of the ranking shows the last pull. Raw numbers are in data.json.

Money

The ranking has no affiliate links today. If we add one later, for example to n8n Cloud, it will be labelled, and it will never change the order.

Other rankings

The same score is used for AI npm packages and AI Python packages, with GitHub issues in place of forum threads. All three are on the rankings page.

Spotted an error? Write to mission@usestarbase.com.

Newsletter

One small automation every Friday

Each Friday email has one recipe, the prompt for it, and the way it broke when we wrote it up. It's free, and every email has an unsubscribe link.