What Is n8n? A Developer Introduction to Workflow Automation

n8n is a workflow automation tool you run on your own hardware. You wire together triggers, API calls, and code steps on a canvas, and it executes them on a schedule, on a webhook, or on demand. If you have ever glued three services together with a cron job and a 200-line Python script that nobody else can maintain, n8n is aimed squarely at you.

This is the first article in our n8n Automation Stack series. It covers what n8n is, the four concepts you need before anything else makes sense, what changed in 2026, and when reaching for n8n is the wrong call. No workflow building yet. That starts in the next two parts.

What n8n Actually Is, and What It Is Not

n8n is a node-based automation engine with several hundred built-in integrations. You self-host it, your credentials stay in your database, and every workflow is JSON you can export and commit to git. That last property is the one that matters most for developers, and it is the main thing hosted automation tools do not give you.

Here is the part most introductions skip: n8n is not open source. It is source-available under the Sustainable Use License v1.0. You can read the code, modify it, and self-host it, but the licence sets explicit boundaries:

You may use or modify the software only for your own internal business purposes or for non-commercial or personal use. You may distribute the software or provide it to others only if you do so free of charge for non-commercial purposes.

In practice that means running n8n for your own company or your own projects is fine. Wrapping it up and reselling it as a hosted service is not. Separately, any source file with .ee. in its filename or .ee in its directory name sits outside that licence entirely and needs a commercial Enterprise licence.

We cover open-weights models and genuinely open tooling here, so it is worth being precise rather than calling everything self-hostable "open source". n8n is fair-code. For most readers that distinction changes nothing. If you are building a product on top of it, read the licence before you write the business plan.

The Four Concepts That Make n8n Click

Almost every point of confusion for new users comes from missing one of these four ideas.

Nodes

A node is one step. It might call an HTTP endpoint, run a snippet of JavaScript or Python, branch on a condition, or talk to Postgres. Data flows between nodes as an array of JSON items, and this is the single most important thing to internalise: a node does not receive one object, it receives a list. If your workflow mysteriously runs five times, it is because the node upstream handed it five items.

Triggers

A trigger is how a workflow starts. The common ones are schedule (cron), webhook (an inbound HTTP request), and manual execution from the editor. A workflow has exactly one active trigger path. Getting the trigger right is most of the design work.

Credentials

Credentials are stored separately from workflows and referenced by name. This is why you can export a workflow to JSON and share it without leaking your API keys. It also means the encryption key that protects those credentials is the single most important thing to back up. Lose it and every stored credential becomes unreadable, even with an intact database. We come back to this in part two.

Executions

Every run is recorded with its input and output at each node. When something breaks at 3am, the execution log tells you which node failed and exactly what data it received. This is the feature that makes n8n worth using over a shell script, and it is the one people discover last.

Test Runs and Production Runs Are Not the Same Thing

n8n distinguishes between executing a workflow from the editor and running a published one. They use different URLs, and this trips up almost everyone the first time they build a webhook.

A test execution shows live data in the editor, which is what you want while building. A production execution does not display in the editor at all. You inspect it afterwards through the Executions tab. If you have ever pointed an external service at an n8n webhook and watched nothing happen, you were almost certainly still on the test URL, which only listens for a single request.

Remember this one. It becomes load-bearing in part three, when we expose a workflow as a tool over the network.

What Changed in n8n During 2026

If your mental model of n8n is from 2024, several things are different.

• The AI Agent node was rebuilt with tool calling across Claude, GPT-4o, Gemini, Mistral, Groq, and any OpenAI-compatible endpoint. That last one is what lets you point it at a local model.
• Four memory node types shipped: in-memory, Redis, Postgres, and Motorhead. Conversation state no longer has to be something you hand-roll.
• The Canvas UI arrived in version 1.30 and replaced the flat left-to-right builder. Nodes can be grouped into labelled clusters and collapsed, which matters once a workflow passes about 20 nodes.
• Per-node retry with exponential backoff is now built in, instead of being something you construct out of error branches.
• Execution replay landed in June 2026 and lets you trace variables line by line through JavaScript and Python nodes on a failed run.
• MCP support means n8n can act as a Model Context Protocol server or client. This is the subject of part three.

When n8n Is the Right Tool

It is not always. Being honest about this saves you a rewrite later.

The honest failure mode of n8n is complex branching business logic. Once a workflow has 40 nodes and six conditional paths, it is harder to read than the equivalent 100 lines of code, and much harder to diff in review. Use it as glue between systems, not as a programming language.

What Self-Hosting Actually Costs

n8n itself is free to self-host under the terms above. The community edition has no execution limits, so the cost is your hardware and your time.

A small instance handling a few thousand executions a month runs comfortably on 1 vCPU and 1 GB of RAM. Add Postgres instead of the default SQLite once you care about concurrent writes or want backups that are not a file copy. If you plan to run local models alongside it, the memory budget is dominated by the model, not by n8n. Our full local AI stack guide covers those numbers in detail.

Your First Ten Minutes

The fastest way to get a feel for the editor is a throwaway container. This is not how you should run it permanently, and part two explains why, but it is enough to click around:

docker run -it --rm --name n8n -p 5678:5678 docker.n8n.io/n8nio/n8n

Open http://localhost:5678, create the owner account, and build the smallest possible workflow: a Schedule Trigger into a Code node that returns { hello: "world" }. Execute it, then open the Executions tab and look at the recorded input and output. That loop of build, run, inspect is the whole tool in miniature.

Note the --rm flag. Everything you build in that container disappears when you stop it, credentials included. That is deliberate for a first look and unacceptable for anything else.

What Comes Next in This Series

Part two covers setting n8n up properly: the barebones Docker and npm paths, the environment variables that decide whether your webhooks work behind a reverse proxy, and the two bundled harnesses that install n8n alongside a local model stack. Part three turns a workflow into an MCP tool that an AI agent can call directly.

If you would rather jump straight to building something, our AI generator tutorial wires n8n to Ollama and the Claude API end to end.

Sources and Further Reading

• n8n documentation
• n8n Sustainable Use License
• n8n self-hosting documentation
• n8n release notes