What is n8n?

What it actually is

A canvas where you place nodes and connect them. One node starts the workflow: a schedule, an incoming web request, a new row somewhere. Each node after it receives the previous node's output, does something, and passes its own output along.

The shape of every n8n workflow

1. TriggerSomething happensthen
2. ActionDo somethingthen
3. ActionThen something else

That is the whole model. The rest is which nodes exist and how you get data from one to the next.

The detail that catches everybody once is the second sentence above: each node receives the previous node's output, not the original trigger data. A workflow that fetches a record, transforms it, and then wants a field from the original webhook has to carry that field forward deliberately. Most early confusion with n8n is this and nothing else.

1Authentication: NoneThe Webhook node default, so a live workflow is a public endpoint

2One store, every serviceSpreadsheet, chat, CRM, mailbox, model provider

3What each key reachesScope them per service, so a compromise is bounded

4A standing patching commitmentTreat upgrades as security updates, not feature updates

1. 1Authentication: None The Webhook node default, so a live workflow is a public endpoint
2. 2One store, every service Spreadsheet, chat, CRM, mailbox, model provider
3. 3What each key reaches Scope them per service, so a compromise is bounded
4. 4A standing patching commitment Treat upgrades as security updates, not feature updates

What people actually build with it

Four shapes cover most of what gets built, and recognising which one you are building tells you how much care it needs.

Notify. Something happened, tell somebody. A form submission into a chat channel, a failed payment into a ticket. Low risk, immediately useful, and where almost everyone starts.

Move and reshape. Take data from one system, transform it, put it in another. A form into a spreadsheet, a spreadsheet into a CRM. This is where the tool earns its keep in most organisations, and where the failure mode is quiet: a field silently empty for three weeks because a name changed upstream.

Assemble on a schedule. A report built at seven each morning from four systems that do not talk to each other. Popular with finance and operations, and the workflow nobody documents until the person who wrote it leaves.

Decide and act. A ticket summarised by a model, routed by priority, and in the more ambitious versions answered automatically. This is the shape that needs the most thought, because it is the one where the automation acts rather than reports.

Cloud or self-hosted, on the axes that decide it

Expressions, and when you will meet code

You will run into expressions such as {{ $json.name }} within the first hour. They pull a value out of the data flowing between nodes and they are much closer to spreadsheet formulas than to programming. Most people become comfortable with them in an afternoon.

The Code node exists for what expressions cannot express: loops with real conditions, awkward reshaping, calling something with no dedicated node. It runs JavaScript or Python. Plenty of people build genuinely useful automation without ever opening it, and reaching for it early is usually a sign that a built-in node was missed rather than that code is required.

The honest summary is that n8n is a low-code tool rather than a no-code one. The floor is low and the ceiling is high, and the transition between them is gradual enough that you will not notice crossing it.

n8n and AI, which is where most of the interest is

Recent versions ship nodes for language models, agents, vector stores and memory, and this is what has pulled n8n into organisations that never wanted a workflow tool. An agent node with a set of connected tools is a genuinely capable thing to be able to build on a canvas in an afternoon.

It also imports every problem of the underlying architecture, and imports it into a system holding your credentials.

An n8n agent reading support tickets is reading attacker-writable text. The webhook that feeds it is frequently public. The tools you connected to it are real actions with real permissions. That combination is exactly the shape described in the prompt injection guide on this site, assembled quickly by somebody who was thinking about the automation rather than about the trust boundary.

None of that is an argument against building it. It is an argument for deciding what the agent is permitted to do before you connect the tools, because the canvas makes connecting them the easiest step rather than the one that deserves the most thought.

Is it open source?

Not quite, and the distinction has practical consequences.

n8n is fair-code, published under the Sustainable Use License. The source is public and you can read, modify and self-host it at no cost. What the licence restricts is use beyond your own internal business purposes: redistributing it, or embedding it in a product you sell, requires a commercial agreement. Offering consulting or support services around it does not.

For almost every organisation reading this the practical answer is that it behaves like free software. It matters if you intend to build a product on top of it, and in that case it is a conversation with n8n rather than a licence you can simply comply with by reading.

Where it fits

Note the phrasing of the fourth item on the left. The question is not whether you can stand a server up. It is whether you patch the ones you have, for reasons the security section below makes concrete.

How it is priced, and why it matters

Zapier and Make bill by task, meaning roughly each thing a workflow does. n8n bills by execution, meaning one run of a workflow however many steps it contains.

That sounds like a detail and it decides the tool at volume.

Billable units per month, one workflow

Billed per task, 12 steps12,000

Billed per execution1,000

The same work is twelve thousand billable units on one model and one thousand on the other. Add a step for error handling and the first bar grows by a thousand while the second does not move at all. This is the mechanism by which teams find that making a workflow more careful made it more expensive, and it is a genuinely bad incentive.

The part introductions leave out

Two things, and the second is the one that should decide how you deploy this.

The webhook default

n8n's Webhook node has an Authentication setting, and it defaults to None.

The moment you build a workflow triggered by a web request and activate it, you have created a public endpoint that anyone who learns the address can call. If that workflow writes to a spreadsheet, posts into your team's chat, or feeds a model, so can they.

The patching commitment

This is the part that belongs in any honest introduction on a security site, and it is absent from nearly all of them.

n8n has had a serious run of critical vulnerabilities, and self-hosting means you own every one of them.

Critical vulnerabilities, and what they required

1. 18 Nov 2025

   1.121.0 fixes CVE-2026-21858

   Ni8mare. CVSS 10.0, unauthenticated remote code execution via content-type confusion in webhook request parsing, allowing arbitrary local file reads, forged admin cookies and full takeover. Researchers estimated 100,000 exposed servers globally.

2. Late 2025

   CVE-2025-68613

   Authenticated remote code execution in the server-side expression evaluation engine, affecting versions from 0.211.0 up to the 1.120.4 and 1.121.1 fixes.

3. Jan to Feb 2026

   Eight further CVEs

   High to critical issues across expression evaluation, file access controls, Git, SSH, the Merge node and Python execution.

4. Ongoing

   What this means for you

   Not that n8n is unusually bad software. That an internet-reachable automation server holding every credential you gave it is a high-value target, and running one is a standing commitment rather than a setup task.

Read that list alongside what an n8n instance holds. To be useful it stores credentials for every service it touches: the spreadsheet, the chat workspace, the CRM, the mailbox, the model provider. An unauthenticated takeover of the instance is therefore a takeover of everything the instance can reach, which is usually a great deal more than anybody itemised when they approved it.

Getting started, honestly

There are two sensible routes and the choice is about what you want to learn.

n8n Cloud if you want to learn the tool. Nothing to install, webhook URLs are publicly reachable immediately, patching is somebody else's job, and you can be building in minutes. For a small business without an operations function this is usually the honest answer, and the monthly fee is cheaper than the first incident.

Docker if you want it on your own machine or server. It pins a known-good runtime and upgrades are a new image tag, which matters more than it sounds given the section above. If you install with npm instead, note that n8n requires Node.js between 20.19 and 24.x inclusive; outside that range it fails in ways that look like workflow problems rather than runtime problems, and people lose days to it.

A reasonable pattern for an organisation is to learn on Cloud, decide whether self-hosting is genuinely required by a data constraint, and only then take on the operator role deliberately rather than by drift.

That last phrase is doing real work. The common route to a badly run n8n instance is not a bad decision, it is the absence of one: somebody spins up a container to try something, it becomes useful, other people start depending on it, and at no point does anybody decide that the organisation now operates an automation server. Naming an owner at the moment it stops being an experiment costs nothing and is the single most useful thing you can do.

Where to go next

If you want to build something, the tutorial below walks a webhook into a spreadsheet into a chat notification, gets it running in production, and then closes the unauthenticated endpoint you will have just created.

If you are weighing n8n for an organisation rather than for yourself, the question that matters is not whether it can do the job. It is what the automation will be permitted to touch, what happens when the data arriving through it is not what you expected, and who is going to apply the next critical patch.