Workflow automation for teams that still want code

n8n is a visual workflow automation system for technical teams. It gives you the drag-and-drop surface people expect from Zapier, but it keeps escape hatches open: JavaScript, Python, npm packages, custom nodes, webhook flows, queue workers, and self-hosted deployments. That mix explains why it keeps showing up in searches for “Zapier alternative” and “self-hosted automation.” It is not just a prettier cron runner. It is an integration server with a workflow editor on top.

The README describes n8n as secure workflow automation for technical teams, with 400+ integrations, native AI features, and a fair-code license. The sharper reading is this: n8n is strongest when an operations, data, or product team wants ownership of workflows without turning every small automation into a backend project.

As of 2026-06, the repository has 192,025 stars, 58,456 forks, and 1,472 open issues. The latest release observed during writing was [email protected], published on 2026-06-10. Those numbers should be read as a writing snapshot. The live data card on this page is the part that refreshes.

Install and first run

The README gives two quick-start paths. For a local test, Node.js plus npx is the shortest route:

npx n8n

The editor then runs on:

http://localhost:5678

Docker is the path most people inspect before self-hosting. The README points at the official docker.n8n.io/n8nio/n8n image and a local volume setup. That Docker path is fine for evaluation. It is not the production design. A serious self-hosted n8n setup needs a real database, queue workers for heavier execution, secrets management, backups, logs, and a clear rule for upgrades. n8n can be self-hosted, but “self-hosted” here means you own the boring parts too.

What makes n8n different from a normal no-code tool

The important feature is not the canvas. It is the boundary between visual work and code.

n8n has nodes for common SaaS APIs and databases, but workflows can drop into JavaScript or Python when the built-in node is too narrow. It has webhooks for inbound events, scheduled workflows for background jobs, credentials management, and templates for common patterns. Recent positioning also leans hard into AI workflows: LangChain-based agent flows, MCP-related integrations, model calls, memory, and tool use.

That makes n8n more useful than a pure no-code tool when a workflow starts as a business process and slowly becomes software. The canvas remains readable to non-specialists, while the code nodes keep the team from exporting the hard part into a separate service on day three.

The trade-off is surface area. A simple Zapier automation hides almost everything. n8n exposes enough internals that you need someone who understands webhooks, retries, OAuth credentials, database health, and deployment state. That is the price of control.

Cloud, self-hosted, and the license line

n8n is source-available under its Sustainable Use License, with an Enterprise License for paid features. The README calls it fair-code. That is useful shorthand, but it is not the same as an OSI open-source license like MIT or Apache-2.0. If your procurement rule says “open source only,” read the license before you treat n8n like a normal permissive dependency.

Cloud is the easiest path when the main job is business automation. You avoid database care, worker sizing, and upgrade sequencing. Self-hosting makes sense when data locality, private network access, cost control, or custom deployment policy matters more than operational simplicity.

For production self-hosting, assume PostgreSQL rather than a toy local store, and assume Redis if you run queue mode. That is where the issue tracker becomes more honest than the landing page. Recent open issues mention database reconnect trouble after an AWS RDS failover (#31800), Redis Cluster key formatting in queue mode (#31952), and workflows disappearing or credentials missing for non-admin users (#32019). None of that says “do not self-host.” It says n8n should be treated as an application platform, not a disposable container.

Where the AI and MCP story is real

n8n has become a practical place to wire model calls into business workflows. You can call LLM APIs, build agent-like flows, bring in memory, and connect tools around the same workflow graph that handles webhooks and SaaS APIs. That matters because many AI automations fail outside the model call: they need credentials, retries, approvals, rate limits, and a place to inspect failures.

The newer MCP angle is promising but still moving. The repository topics include mcp, mcp-client, and mcp-server, and recent issues show the rough edge: Atlassian MCP OAuth 2.1 connection problems (#31887), get_workflow_details returning empty tags (#31825), and a crash when a draft contains a webhook node without parameters (#31705). If you are adopting n8n mainly for MCP, test the exact server and OAuth flow you need. Do not assume the checkbox is the same as stable interoperability.

AI agent workflows have a similar shape. A recent issue describes nested AgentToolV3 with Redis memory producing invalid OpenAI tool messages after upgrading from 2.23.0 to 2.25.1 (#31860). That is the kind of bug that only appears once real state and tool calls meet long-running workflows. n8n can host those flows, but you should version them like code.

Operational gotchas from recent issues

The most useful issues are not philosophical. They point to the things that cost time in production:

  • Webhook triggers can be hard to reason about when a reverse proxy, a third-party sender, and long-running downstream nodes are involved. Issue #31837 reports duplicate webhook executions around a Baserow trigger, with maintainers asking for proxy logs and debug-level n8n logs.
  • OAuth setup remains integration-specific. Issue #31770 reports a Slack OAuth callback returning 500 through the n8n cloud callback URL, with the thread narrowing toward credential configuration.
  • Forms with large uploads need explicit testing. Issue #32078 reports uploads above 100 MB silently refreshing the form and losing user input.
  • Database and Redis behavior matter in queue mode. The RDS reconnect issue and Redis Cluster issue are exactly the kind of failures you only notice after a deployment becomes important.

The lesson is simple: n8n is easy to start, but not magic once it becomes infrastructure. Put it behind normal production habits: staging, backups, logs, upgrade windows, and workflow exports.

Compared with Activepieces, Windmill, Huginn, and Zapier

Activepieces is the closest open workflow automation peer in the current GitHub field. As of 2026-06 it has 22,704 stars, TypeScript code, AI-agent and MCP positioning, and an “n8n-alternative” topic in its own repo metadata. If you want a younger automation platform that markets directly into AI agents and MCPs, compare Activepieces first.

Windmill is a different tool wearing some of the same labels. It is a developer platform for scripts, webhooks, workflows, and internal UIs. As of 2026-06 it has 16,705 stars and is primarily Rust. Choose it when the core unit is a script or internal app rather than a business-user automation canvas.

Huginn is older and more hacker-shaped. It has 49,455 stars, Ruby code, and a long history around agents that monitor feeds, pages, and events. It is less polished as a modern SaaS automation replacement, but still useful when you want a self-hosted event-monitoring toolkit.

Zapier remains the default if you want hosted convenience and do not care about code-level control or self-hosting. n8n wins when ownership, custom logic, private network access, or AI workflow inspection matters enough to accept operations work.

Star curve reading

The sampled star curve shows n8n climbing steadily for years, then accelerating into the AI automation cycle rather than flattening. The exact short-window deltas are not reliable from the sampled curve, but the overall shape is clear: this is no longer a niche automation repo. It is one of the main open-source-adjacent workflow platforms developers now evaluate before paying for closed SaaS automation.

For local model backends that can sit behind workflow agents, see ollama/ollama. For web data ingestion inside AI workflows, firecrawl/firecrawl is the adjacent piece. For the broader weekly view, follow LLM tooling and the GitHub trending repositories hub.

FAQ

Is n8n open source? n8n is source-available and self-hostable, but its main license is the Sustainable Use License rather than MIT, Apache-2.0, or another OSI open-source license. Treat that as a legal and procurement detail, not a footnote.

Can I run n8n with Docker? Yes. The README gives a single-container Docker command for trying it locally. Production self-hosting usually needs PostgreSQL, Redis for queue mode, backups, and a more deliberate upgrade process.

Is n8n a Zapier alternative? Yes, if you want more control, code nodes, self-hosting, and private-network access. Zapier is still easier when the only requirement is hosted SaaS automation with minimal operations work.

Is n8n good for AI agents and MCP workflows? It is a good place to orchestrate model calls, tools, credentials, and approvals. For MCP specifically, test your target server and OAuth path, because recent issues show that the MCP surface is still changing.

What should I test before using n8n in production? Test webhooks through your proxy, OAuth credentials for your key integrations, workflow retries, large form uploads, queue mode with Redis, database failover behavior, and export or backup of critical workflows.