# n8n

> The open-source, self-hostable automation tool that lets you drop to code when you need to - nodes and workflows, credentials, and real automations including AI steps.


---

# n8n

n8n (say it "n-eight-n", short for "nodemation") is a tool for wiring apps together so work happens without you. A new row lands in a spreadsheet, n8n sees it, looks up the customer, posts to Slack, and files a ticket - all on its own. If you've heard of Zapier or Make, it lives in the same neighborhood. The difference that matters: n8n is open-source, you can run it on your own server, and when the clicking-and-dragging runs out of road, you can drop into a code box and write a few lines yourself. That last escape hatch is why a lot of teams pick it.

This guide is for founders, ops people, and analysts who want to automate the boring connective tissue of a business and don't want to be locked into a per-task bill or a black box. You do not need to be an engineer. You will see what a "node" is, how a "workflow" strings them together, where your passwords and API keys live, and how a real automation looks end to end. We'll be straight about the parts that bite - n8n gives you more rope than a click-only tool, and rope cuts both ways.

The arc: **Phase 1** builds your mental model - nodes, connections, the editor, and what an "execution" is, plus why open-source and self-hosting are the whole pitch. **Phase 2** covers the grown-up concerns: hosting it yourself versus paying for n8n Cloud, where credentials and secrets live, how expressions pull data from one step into the next, and the Code node for when no-code hits a wall. **Phase 3** builds a concrete multi-step automation, shows how a webhook lets the outside world trigger your flow, and adds an AI node so a step can read, summarize, or decide instead of merely shuffling data.


---

# Nodes & Workflows

Picture an assembly line. Something arrives at one end, passes through a row of stations - each does one job - and comes out the other end transformed. n8n is that line, drawn on a canvas. Each station is a **node**. The whole line is a **workflow**. Once you see it that way, the rest is detail.

## A node is one step

A node does a single thing: fetch rows from Google Sheets, send a Slack message, call an API, filter a list, wait an hour. n8n ships with hundreds of pre-built nodes for common apps - Gmail, Notion, Stripe, Airtable, Postgres, HubSpot - plus generic ones like "HTTP Request" that can talk to any service with an API.

Every node takes **data in**, does its job, and passes **data out** to the next node. The data flows as a list of items. If a node pulls 50 spreadsheet rows, the next node runs 50 times, once per row, without you writing a loop. That "one node, runs over every item" behavior is the single most important thing to internalize - it's why a three-node workflow can process a thousand records.

Nodes come in a few flavors:

| Flavor | What it does | Example |
|---|---|---|
| Trigger | Starts the workflow | "New email in Gmail", "Every day at 9am", "Webhook" |
| Action | Does work in an app | "Create row", "Send message", "Update record" |
| Logic | Routes or shapes data | "IF", "Filter", "Merge", "Edit Fields" |
| Code | Runs your own snippet | "Code" node (more on this in Phase 2) |

Every workflow needs exactly one starting point - a trigger. Everything else hangs off it.

## A connection is the wire

You build a workflow by dragging nodes onto the canvas and drawing **connections** between them - literally pulling a line from one node's output dot to the next node's input dot. The line means "send your output here next." Data flows left to right along those wires.

Connections can branch. An IF node has two outputs - true and false - so you can send paid customers down one path and free users down another. You can also merge two branches back together. The shape of the wiring *is* the logic. There's no hidden order; what you see on the canvas is exactly what runs, in that order.

```text
[Schedule: every morning]
        |
[Get new signups from DB]
        |
   [IF paid plan?]
     /         \
  true        false
   |            |
[Send to    [Add to
 sales]      nurture list]
```

## The editor is where you live

The canvas is the n8n **editor**, in your browser. You drag nodes from a panel, click a node to open its settings, fill in fields, and - this is the part that makes n8n pleasant - run a single node on the spot to see what comes out. You don't have to run the whole thing to test a step. Click "execute node," look at the real data it produced, and only then wire up the next one. Build a step, see the data, build the next step against that real data. That tight loop is most of the skill.

When you open a node you'll see input data on the left, the settings in the middle, and output data on the right. Watching real records move through is how you catch mistakes early - a field named `Email` versus `email`, a date in the wrong format, an empty list where you expected rows.

## An execution is one run

Every time a workflow fires - on a schedule, from a webhook, or because you hit "test" - that's one **execution**. n8n keeps a log of executions so you can open any past run and see exactly what each node received and sent. When something breaks at 3am, that history is where you go: you open the failed execution, find the red node, and read the actual data it choked on. No guessing.

This matters for cost and debugging both. On usage-based plans, executions are often the thing you're billed for, so a workflow that fires once per email versus once per batch can mean very different bills (we'll come back to this in Phase 2).

## Why teams pick n8n

Two reasons, and they're related.

**It's open-source and self-hostable.** You can run n8n on your own server - a cheap cloud box, a machine in your office, a Docker container - and your data never leaves your walls. For a hospital, a law firm, or anyone handling customer records under GDPR or HIPAA, "the automation runs on infrastructure we control" is not a nice-to-have. The core is source-available under a "fair-code" license; for most internal business automation, self-hosting it is free of license fees (you pay only for the server it runs on).

**It doesn't trap you when no-code runs out.** Click-only tools are smooth until you hit the one thing they can't express - a weird date math, a custom API call, a transformation with no pre-built node. In n8n you drop into a Code node, write a few lines, and keep going. You're never stuck waiting for the vendor to add a feature. That ceiling-with-an-escape-hatch is the whole appeal, and it's where the next phase begins.

The trade-off, stated plainly: more power means more ways to shoot yourself in the foot. Self-hosting means you own updates and backups. Code nodes mean you own the bugs. n8n hands you the keys; Phase 2 is about driving safely.


---

# Self-Host, Credentials & the Code Node

Phase 1 was the toy version: drag nodes, draw wires, watch data move. This phase is the part that decides whether your automations survive contact with reality - where they run, how they hold your secrets, how data flows between steps, and what you do when the pre-built nodes can't express what you need.

## Cloud or your own box

You have two ways to run n8n.

**n8n Cloud** is the hosted version. You sign up, you get a URL, n8n keeps it running, patched, and backed up. You pay a monthly subscription, and the plan is shaped around how many workflow **executions** you run and how many active workflows you have - not per-task like some competitors. For a small team that wants to skip server administration, this is the path of least resistance.

**Self-hosting** means you run n8n yourself, usually as a Docker container on a cloud server you rent (a $5–$20/month box handles a lot). The software itself is free of license fees for this; you pay only for the machine. In exchange you get: your data stays on your infrastructure, no execution caps beyond what your server can handle, and full control. You also get the chores - updates, backups, and keeping it online are now your job.

| | n8n Cloud | Self-hosted |
|---|---|---|
| Setup | Minutes, no server | You run a server / container |
| Cost shape | Monthly, by executions + active workflows | Server rent only (license-free for most use) |
| Data location | n8n's infrastructure | Yours |
| Updates & backups | Handled for you | Your responsibility |
| Execution limits | Per plan | Whatever your server takes |

A common pattern: prototype on Cloud or a local install, then self-host once it's load-bearing and the data sensitivity matters.

> A self-hosting trap worth naming: when you upgrade a self-hosted instance, **back up first**. Your workflows and credentials live in a database; a botched upgrade or a wiped container can take them with it. "It's just a container" has eaten many people's automations.

## Credentials: where the secrets live

Almost every node needs to prove who you are to some service - a Gmail login, a Stripe API key, a database password. In n8n these are stored as **credentials**, separately from the workflows that use them.

This separation is deliberate and good. You enter your Slack token once, as a credential named "Company Slack," and any node that needs Slack picks it from a dropdown. The secret itself is encrypted at rest and never shown back to you in plain text after you save it. If you export or share a workflow, the credentials don't travel with it - only a reference does. So you can hand a colleague a workflow without handing them your API keys.

A few rules that save pain:

- **One credential, many workflows.** Rotate a key once in the credential, and every workflow using it updates. Don't paste keys into individual node fields.
- **Self-hosters: set an encryption key and guard it.** n8n encrypts credentials with a key it generates on first run. If you lose that key (or spin up a fresh instance against an old database), your saved credentials become unreadable. Back it up alongside your database.
- **Least privilege.** Give each credential the narrowest access that works. An API key that can only read is a smaller disaster if it leaks than one that can delete.

## Expressions: pulling data from earlier steps

Static fields are fine until you need step three to use something step one produced. That's what **expressions** are for. Anywhere you'd type a fixed value, you can instead flip a field to expression mode and reference live data from upstream nodes.

Expressions are written in `{{ }}` and pull from the data flowing through. The common shapes:

```text
{{ $json.email }}              the "email" field of the current item
{{ $json.customer.name }}      a nested field
{{ $now }}                     the current date/time
{{ $node["Get Customer"].json.plan }}   a field from a named earlier node
```

You'll mostly use `$json` (the current item's data) and references to earlier nodes by name. The editor shows you a live preview of what an expression resolves to against your real test data, so you're not guessing. Expressions are how a Slack message becomes "New signup: {{ $json.name }} on the {{ $json.plan }} plan" instead of the same text every time.

## The Code node: the escape hatch

Eventually you hit a wall. You need a transformation no node offers, date math that's fiddly, or you want to reshape a messy list before it moves on. This is the moment n8n earns its reputation. You drop in a **Code node** and write a short snippet (JavaScript, or Python on supported setups) that takes the incoming items and returns new ones.

You don't write a whole program. You get the input items in a variable, you transform them, you return a list. A typical job is "take these 200 rows, keep only the ones from this month, and add a `fullName` field by joining first and last." Five lines, and you're back to dragging nodes.

When to reach for it:

- A transformation or calculation no pre-built node does.
- Reshaping data - flattening, grouping, renaming a pile of fields at once.
- Calling something obscure that the generic HTTP node makes awkward.

When **not** to: if a normal node already does it, use the node. Code is the thing your teammate can't read at a glance and the thing that breaks silently when an upstream field is missing. Reach for it when no-code runs out - not before. The point of the escape hatch is that it's there when you need it, not that you live inside it.

With hosting, secrets, expressions, and the code escape hatch in hand, you have everything to build something real. Phase 3 does exactly that.


---

# Real Automations (and AI Nodes)

Enough scaffolding. Let's build something a real business would actually run, then add a step that thinks.

## A concrete automation, start to finish

The job: **every time a customer fills out the contact form on our website, look them up, route urgent ones to the team in Slack, and log everyone to a spreadsheet.** Here's the wiring.

```text
[Webhook: form submitted]
        |
[HTTP Request: enrich - look up company by email domain]
        |
   [IF: message contains "urgent" or "down"?]
       /                    \
    true                   false
      |                       |
[Slack: ping #support]   [no alert]
       \                    /
        \------- merge -----/
                 |
[Google Sheets: append a row]
```

Walk it node by node:

1. **Webhook trigger.** The form posts its data to a URL n8n gives you. The moment someone submits, this fires. (More on webhooks below.)
2. **Enrich.** An HTTP Request node calls an enrichment API with the submitter's email domain, so you learn the company name and size before a human ever reads it.
3. **Route.** An IF node checks the message text. Anything mentioning "urgent" or "down" goes down the true branch.
4. **Alert.** The true branch posts to Slack: `🔥 Urgent from {{ $json.name }} at {{ $json.company }}: {{ $json.message }}`. Notice the expressions from Phase 2 doing the work.
5. **Merge & log.** Both branches rejoin, and a Google Sheets node appends one row per submission, urgent or not, so nothing is lost.

That's five nodes and maybe twenty minutes. The thing that would've been a recurring "did anyone see the contact form?" problem now handles itself, and you have a spreadsheet of every lead as a side effect.

The build rhythm from Phase 1 still applies: wire the webhook, submit one test form, look at the real data, then build each downstream node against that real data. Don't wire all five and pray.

## Webhooks: letting the outside world knock

A schedule trigger asks "is it time yet?" on a clock. A **webhook** is the opposite - it sits and waits for the outside world to call *it*. n8n hands you a unique URL; whenever something hits that URL, your workflow runs, with whatever data the caller sent as the input.

This is how you connect to anything that can "send a notification when X happens" - form tools, payment processors (Stripe firing on a new charge), GitHub on a new issue, your own app. Instead of polling "any new orders? any new orders?" every minute, the order system tells you the instant it happens.

A few things to know:

- **Test URL vs production URL.** n8n gives you one URL for testing in the editor and a separate one for the live, activated workflow. Point your form at the test URL while building, then swap to production. Forgetting this is the classic "it worked in the editor but nothing happens live" bug.
- **The workflow must be active.** A webhook only listens when the workflow is switched on. In the editor it listens during a test run; in production it listens once activated.
- **Secure it.** Anyone who knows the URL can trigger it. Treat the URL as a secret, and for anything sensitive, check a shared token in the incoming data before acting on it.

## AI nodes: a step that thinks

Everything so far moves and reshapes data. The newer trick is a node that *reads and decides*. n8n has nodes that call large language models - OpenAI, Anthropic, and others - so a step in your flow can summarize, classify, extract, or draft, instead of only routing fields around.

Go back to the contact-form flow. The IF node checked for the literal words "urgent" or "down." Crude - it misses "your service has been broken for an hour and I'm losing money." Swap in an AI step and you can ask, in plain English, "Read this message. Reply with `urgent` or `normal`." The model reads intent, not keywords. You feed its answer into the IF node and the routing gets dramatically smarter for one extra node.

Other real-world, everyday uses:

- **Summarize.** Turn a long support email into one line before it hits Slack.
- **Extract.** Pull a date, an amount, and an order number out of free-text and hand back clean fields for the spreadsheet.
- **Classify & tag.** Sort incoming messages into "billing," "bug," "sales."
- **Draft.** Write a first-pass reply for a human to approve - never auto-send unreviewed.

n8n also has an "Agent" style node where the model can decide which other tools to call, but start with the boring single-shot version: hand it text, get back a label or a summary, use that downstream. Walk before you run.

Two cautions, because AI steps fail differently than normal nodes:

- **They cost money per call and they're slow.** Each AI step is an API charge and a second or two of latency. A workflow that fires thousands of times will run up a bill - batch where you can, and don't put an AI call on a path that fires constantly.
- **They're non-deterministic.** The same input can give slightly different output, and they occasionally make things up. Never let an AI step take an irreversible action - sending money, deleting records, emailing a customer - without a human or a hard rule in between. Use it to *suggest and sort*, and keep a person on anything that can't be undone.

Put it together and you have the shape of modern automation: webhooks let the world trigger you, nodes do the moving and routing, the Code node handles the weird parts, and an AI step adds judgment where keywords fall short - all running on infrastructure you control. That's the whole pitch of n8n, built.
