n8n, reviewed as the thing your automations will actually live in

We build most client automations on n8n. That is a bias, and it is also the reason this review can tell you where it hurts: a tool you have only demoed has no sharp edges yet.

Short version: n8n is the right default for a company that wants automations it can read, host and keep. It is the wrong choice if nobody on your side will ever open it, and the licence has a clause that matters if you plan to run it on behalf of other companies.

What it is

n8n is a workflow tool: triggers on one side, a chain of nodes in the middle, systems on the other end. Visually it looks like Zapier or Make. Structurally it is closer to a piece of software you own, because you can run it on your own server, read the JSON behind every workflow, and drop into a JavaScript or Python node whenever the visual layer runs out.

That last property is the whole argument. Every no-code tool eventually meets a requirement it has no node for. In Zapier that is where the project stops or turns into a paid connector. In n8n it is a Code node and thirty lines.

Where it is genuinely good

The escape hatch is first-class. A code step sits in the same canvas as everything else, receives the same items, and returns the same shape. There is no context switch and no separate deployment. Most of our client workflows are 90% nodes and 10% code, and the 10% is where the business logic that nobody else’s system has actually lives.

Workflows are text. Every workflow exports as JSON. That means diffs, code review, a repo, and a real answer to “what changed last Tuesday.” Compare that with a visual tool where the audit trail is a screenshot in someone’s Slack.

Self-hosting is not a downgrade. The Community Edition is the full node set with no execution limit. You pay for a small VPS and nothing else. For a mid-sized company with a data-protection officer who asks where customer email is being processed, “on our own machine in Frankfurt” is a very short conversation. It is the single biggest reason n8n wins in the DACH mid-market over the American alternatives.

Error handling is a design, not an afterthought. Per-node retry, error branches, and a dedicated error workflow that fires when anything in the account fails. That last one is the feature to configure on day one and the one most teams discover in month three.

The AI nodes are close enough to the metal. Model calls, tool calls, memory and vector stores are nodes rather than a separate product tier. You can wire an agent whose tools are your own workflows, which is the thing most “AI automation platforms” are actually reselling.

Where it hurts

The canvas gets ugly before the system gets large. Past about thirty nodes, a workflow becomes hard to read and impossible to diff usefully. The answer is sub-workflows, and the answer is not optional, but n8n will happily let you build the 80-node monster first and discover the problem afterwards.

Debugging a long chain is slow. Pinned data helps a lot and is underused. Without it you re-run the whole chain to test node 19, and if node 3 sends an email, you have just sent it again. Build the destructive steps behind a flag from the start.

Version control is bolted on, not built in. Git integration exists on the paid tiers; on Community you are exporting JSON yourself. Doable, and we do it, but nobody should pretend it feels like a normal codebase.

Upgrades occasionally move things. It is a fast-moving product. Read the release notes on a self-hosted instance before you bump it, and do not bump it the day before a client demo.

It expects an owner. This is the honest disqualifier. n8n rewards someone who will open it, read a failed execution, and fix a node. A company where nobody will ever do that should buy a closed product with a support line, not a workflow engine, and should be told so before the invoice, not after.

A company where nobody will ever open the tool should buy a closed product with a support line, not a workflow engine.

Pricing, and the part that surprises people

Two facts do most of the work here.

$0 against $864 a month, the same node set, self-hosted or on the cloud Business tier.

n8n pricing page, July 2026

Self-hosted Community is free, with unlimited executions. Your cost is infrastructure, realistically a few euros a month on a small VPS for a workload of this size, plus whatever the LLM calls cost.

Cloud is billed per execution, not per step. One workflow run counts once, no matter how many nodes it passes through. That is the opposite of Zapier’s per-task model and it changes the design incentive completely: in n8n you are rewarded for putting the whole chain in one workflow, in Zapier you are punished for it.

As of July 2026 the cloud tiers run roughly $25.92/month for Starter, $64.80 for Pro and $864 for Business, with an enterprise tier above that and about 17% off for annual commitment. n8n removed active-workflow limits across all plans in April 2026, so the only meaningful meter is executions. Check the current page before you budget: this is the number that has moved most often.

The trap: a self-hosted Business plan introduces per-execution fees, which is a different economic shape from Community. Teams that started free and scaled into a paid self-hosted tier are the ones who get a surprise. Model the execution volume before you upgrade, not after.

The licence clause nobody reads

n8n is fair-code, not open source. It ships under the Sustainable Use License, and the distinction is not academic.

You may use it for internal business purposes and for non-commercial purposes, freely. You may modify it. What you may not do is “distribute the software or provide it to others” commercially: that is, host n8n as a service for third parties, or white-label it into your own product, without a separate agreement with n8n. Files with .ee. in the name sit under a stricter enterprise licence again.

For a company automating its own operations, this is a non-issue: internal use is exactly what the licence is for. For an agency planning to run one n8n instance and sell seats on it, or a SaaS planning to embed the canvas, it is the first thing to resolve. There is an embed and OEM path for that. Take it before you build, not after a customer asks.

Who it is for

Buy it if: you have systems worth connecting, someone technical who will own the result, and any requirement, regulatory or cultural, to keep customer data on infrastructure you control. It is also the right pick if you expect to hand the system to another team later, because JSON in a repo transfers and a proprietary account does not.

Don’t buy it if: the automation is three steps between two SaaS products and nobody wants a server. Zapier will do it in an afternoon and the difference will never matter. We have told clients this. It is a bad reason to lose a project and a worse reason to win one.

Look elsewhere if you need a vendor to be accountable for uptime and nobody in the company will ever open the tool. Managed n8n exists and helps, but the operating model still assumes an owner.

What we would tell a client on day one

Put every workflow in a repo. Configure the error workflow before the first production run. Split anything past thirty nodes. Pin test data. Give each credential the narrowest scope the integration will accept. And write down, in a document a non-technical person can read, what the chain does and who to call when it stops, because the automation will outlive whoever built it, and that document is the difference between an asset and a haunted house.

If you want to see what that looks like end to end, the email triage build is a complete one, and the orchestration-layer comparison covers the choice against Make and Zapier in more detail.

Frequently asked questions