You know that moment when you're building an n8n workflow and realize:
“Wait… does n8n already have a node for this?”
Maybe you need a specific AI provider.
Or a browser automation tool.
Or some obscure database.
Or a service that isn't part of n8n's core integrations.
The first instinct is usually to reach for the HTTP Request node.
But before writing API calls yourself, there's another possibility:
Someone may have already built the node.
That's one of the reasons I created Awesome n8n Community Nodes.
One of the best things about n8n is that it isn't limited to its built-in integrations.
Developers can create community nodes and publish them as npm packages, extending n8n with new services, triggers, actions, AI capabilities, utilities, and more.
The ecosystem has grown significantly. One existing ecosystem tracker had already indexed thousands of community nodes, showing just how quickly the space is expanding.
That's great for n8n users.
But it creates a new problem:
Discovery.
Having thousands of nodes is useful only if you can actually find the one you need.
I created:
Awesome n8n Community Nodes
🔗 https://github.com/bhavyshekhaliya/awesome-n8n-community-nodes It's an open-source, curated directory for discovering community-built n8n integrations and utilities.
Instead of organizing everything as one massive list, I grouped nodes around what you're actually trying to automate.
Looking for AI, LLM, search, agent, or AI-media capabilities?
There's a dedicated section for that.
Need browser automation, crawling, scraping, or web extraction?
You'll find those together.
WhatsApp, email, chat, notifications, and other communication-related nodes have their own category.
Database, storage, infrastructure, monitoring, and data-related integrations live here.
For document processing, media, transcription, content, and productivity workflows. Integrations that are useful for lead generation, sales, CRM, and customer workflows.
And the smaller but extremely useful tools that don't fit neatly elsewhere.
The repository currently links each entry to its npm package and, when available, its public source repository.
You can.
In fact, the repository points users toward npm's n8n-community-node-package
search as another way to explore the broader ecosystem.
But package discovery and use-case discovery are different things.
If I search npm for a package, I need to already know roughly what I'm looking for.
If I browse a categorized directory, I can discover things I didn't even know existed.
That's the experience I wanted to improve.
Imagine you're building an AI workflow.
You want to:
Search the web → extract information → process it with an LLM → send the result somewhere
You might start thinking about several APIs and custom HTTP Request nodes.
But there may already be community nodes covering parts of that workflow.
The directory makes it easier to explore those possibilities before rebuilding something yourself.
That's the real value of a good ecosystem directory.
It doesn't just help you find what you were searching for.
It helps you discover what you didn't know you needed.
There's an important distinction here.
The repository is a curated directory, not an endorsement or security audit.
Community nodes run third-party code inside your n8n environment, so you should review the source, release history, permissions, dependencies, and license before installing one.
Open source makes discovery easier.
It doesn't remove the need for due diligence.
The directory is intentionally open source.
If you maintain an n8n community node, you can contribute it.
If you use a node that isn't listed, add it.
If something is categorized incorrectly or outdated, open a PR or issue.
The goal isn't to create another list that gets published once and forgotten.
The goal is to make this a living map of the n8n community-node ecosystem.
And the more people contribute, the more useful that map becomes.
I think we're going to see even more interesting n8n nodes as AI agents, MCP, browser automation, and specialized APIs become part of everyday automation workflows.
That means the number of possible building blocks will keep increasing.
And when the number of building blocks increases, discovery becomes infrastructure.
That's what I'm experimenting with here.
If you're an n8n user, take a look:
🔗 **GitHub:** [https://github.com/bhavyshekhaliya/awesome-n8n-community-nodes](https://github.com/bhavyshekhaliya/awesome-n8n-community-nodes)
And if you know a great community node that isn't there yet:
Send it my way.
Let's build the directory together.