What n8n is, how it is sold, the core mental model, the workspace, and your first workflow.
A Signal Through field guide. Independent, plain-English documentation; not affiliated with or endorsed by n8n GmbH. Approximately 22036 words.
In this volume:
Somewhere in your business, right now, a person is copying information from one screen and pasting it into another. Maybe it is you. A customer fills out a form on your website; someone reads the notification email, opens the CRM (the customer relationship management system — the app where the business keeps its customer records), and re-types the customer's name, email, and question into a new record. Then they open the team chat and paste a summary there too. Then they add a row to a spreadsheet so the weekly report stays accurate. Four tools, one piece of information, fifteen minutes — and a small chance of a typo at every step.
Workflow automation is the practice of teaching software to do that relay work for you: to notice that something happened, carry the information to every system that needs it, transform it along the way if necessary, and do it the same way every single time, at any hour, without getting bored or making transcription errors.
n8n (pronounced "n-eight-n") is a tool for building exactly that kind of automation. This book is a complete, plain-English guide to it — what it is, how it thinks, and how to make it do useful work for you. This first chapter builds the foundation everything else rests on: the core vocabulary of automation, the reasons businesses bother with it, where n8n came from, how it compares to the alternatives you have probably heard of, and what its unusual license means for you in practice.
One promise before we start, and it holds for the entire compendium: every technical term is defined in plain English the first time it appears. You do not need a programming background to read this book. When we must use a term of art — and sometimes we must, because it is the word you will see in menus, documentation, and forum posts — we will stop and explain it before moving on.
Tip: If you ever meet a term mid-book and cannot remember where it was defined, Chapter 40 (Mega-Glossary and the Resource Shelf) collects every definition in one alphabetized place.
Every business runs on a collection of specialized tools: one for email, one for invoicing, one for customer records, one for project tracking, one for chat. Each tool is good at its job. None of them, on its own, knows what the others are doing.
The gap between them gets filled by human effort — a category of labor that rarely appears on any job description but consumes an astonishing share of the working week. Industry people sometimes call it "swivel-chair integration": a person swiveling between two screens, reading from one and typing into the other. It has three ugly properties:
Repetitive, rule-based, high-volume: that is the exact profile of work computers excel at. Workflow automation exists to hand it over.
Almost everything in this book — and in n8n's own interface — is built from five concepts. Get these five, and the rest of the compendium is elaboration.
A workflow is a recipe for a repeatable process, written down precisely enough that software can follow it. Like a kitchen recipe, it has a starting condition ("when an order arrives...") and a sequence of steps ("...create an invoice, then email the customer, then post a message in the sales channel"). Unlike a kitchen recipe, once written, it executes itself — every time the starting condition occurs, the steps run automatically, in order, without you watching.
In n8n, a workflow is something you build visually: a diagram of connected steps on a canvas, which you can read at a glance the way you would read a flowchart. Chapter 3 (The Core Mental Model: Workflows, Nodes, Items, and Executions) unpacks exactly how n8n represents workflows internally; for now, "self-executing recipe" is the right picture.
A trigger is the event that starts a workflow — the doorbell, not the dinner party. "A form was submitted." "An email arrived." "It is 9:00 a.m. on Monday." "A payment cleared." Every workflow begins with a trigger, because software needs an unambiguous answer to the question when should this run?
Triggers come in a few flavors — some wait to be notified the instant something happens, others check on a schedule, and some you fire by hand — and the differences matter enough that Chapter 7 (Triggers: Deciding When Work Happens) is devoted entirely to them.
An action is a step the workflow performs once triggered: create a record, send a message, update a spreadsheet row, generate a document, wait two days, decide between two paths. If the trigger is the doorbell, actions are everything you do after answering it. A useful workflow is a trigger followed by one or more actions; the craft of automation is mostly the craft of choosing and arranging actions well, which is the subject of most of Volume B.
An integration is a pre-built connection between an automation tool and some other piece of software. When people say "n8n integrates with Google Sheets," they mean n8n ships with a ready-made component that already knows how to talk to Google Sheets — how to log in, how to read rows, how to add rows — so you do not have to figure any of that out yourself.
Think of integrations as power adapters in a travel kit. The electricity (your data) is the same everywhere; the sockets (each app's particular way of connecting) are all different; the adapter absorbs the difference so you can just plug in. n8n ships with hundreds of these adapters, covering most of the well-known business tools, and Chapter 12 (Navigating and Operating the Integration Catalog) teaches you how to find and operate them.
An API — short for application programming interface — is the mechanism that makes integrations possible. It is the way one piece of software formally offers its services to other software.
The classic analogy, and a good one, is a restaurant waiter. You (one program) cannot walk into the kitchen (another program's internals) and cook your own meal. Instead there is a waiter (the API) who takes requests in a fixed format — "one lookup of customer #4512, please" — carries them to the kitchen, and brings back the result. The menu tells you exactly what you may ask for and how to ask. You never see how the kitchen works, and you do not need to.
Nearly every modern business application has an API: a documented set of requests other software can make of it — give me this record, create that one, tell me when something changes. When an app publishes a good API, tools like n8n can build integrations on top of it. When an app has an API but no ready-made n8n integration exists, you can still talk to it directly — that is what Chapter 13 (The HTTP Request Node: Talking to Any API) is for, and it is one of n8n's quiet superpowers.
Tip: You do not need to become a programmer to use n8n, but simply knowing the word "API" and the waiter analogy will let you read the documentation of almost any software product and understand what is automatable about it. Look for a link labeled "API," "Developers," or "API reference" in an app's website footer — its presence tells you the kitchen accepts orders.
Five words: workflow (the recipe), trigger (when it starts), action (what it does), integration (the pre-built adapter to another app), API (the formal doorway that makes adapters possible). Everything else in this book is built on these.
If manual copying is so bad, an obvious question follows: why do businesses use a dozen separate tools in the first place? Why not buy one giant system that does everything?
Some do — the giant systems are called ERP suites (enterprise resource planning), and they are famously expensive, slow to change, and mediocre at any individual job. Most organizations instead choose best-of-breed: the best email tool, the best accounting tool, the best support desk, each picked on its own merits. It is a rational strategy with one built-in cost: the tools do not know about each other. Every best-of-breed stack is a set of islands, and the business's actual processes — order to cash, lead to customer, hire to onboard — flow across the islands.
That gap gets bridged one of three ways:
The switchboard approach wins on three counts that compound over time. Consistency: the process runs identically every time, which is what makes results trustworthy. Speed: things that took a person fifteen minutes happen in seconds, around the clock. Visibility: because every hand-off runs through one place, you get a log of what happened, when, and to which record — something the swivel chair never provides. (That log, called the execution history, turns out to be one of the most valuable things an automation platform gives you; Chapter 21 treats it as the system of record it is.)
Watch out: Workflow automation is not the same thing as AI, even though the two are increasingly sold in the same breath. Classic automation follows rules you wrote, deterministically — same input, same output, every time. AI adds judgment-like behavior to steps that need it (summarize this text, decide which team should handle this ticket). n8n does both, and does them well together, but they are different tools for different jobs. Volume F covers the AI side; do not feel you need it to get enormous value from the deterministic side.
n8n was created by Jan Oberhauser, an engineer whose earlier career was in the film and visual-effects industry — a world that lives and dies by "pipelines," long chains of automated processing steps that carry footage from camera to finished shot. He had spent years building automation for studios and wanted the same power in a general-purpose, self-hostable tool that individuals and small teams could afford to run.
He released the first public version in 2019. The name is a compression of "nodemation" — node (the software word for one building block in a connected diagram; Chapter 3 makes nodes precise) plus automation — shortened in the style programmers use for long words (the same convention that turns "internationalization" into "i18n"): first letter, count of the letters in between, last letter. Hence n8n, "n-eight-n."
Two decisions made at the start still define the product today:
The project found an early audience among developers and technically curious operators, grew into one of the more popular repositories in its category on GitHub (the website where most of the world's open software projects live and collaborate), and the company behind it — based in Berlin — subsequently raised venture funding (outside investment taken to grow a company fast) and built a commercial hosted offering alongside the free self-hosted one. With the AI wave of the mid-2020s, n8n grew again, this time as one of the most popular ways to build AI-powered agents and pipelines without writing an application from scratch. How the product family is structured and sold today is Chapter 2's territory (The n8n Product Family and How It Is Sold); the origin matters here because it explains the product's temperament — built by an engineer, for people who want to see and control what their automation is doing.
Nobody evaluates n8n in a vacuum. By the time you are reading a book like this, you have probably heard at least two of these four names. Here is where each one genuinely shines, and where n8n sits among them.
Zapier is the household name of the category and, for many people, the first automation tool they ever touch. Its model is deliberately simple: pick a trigger app, pick an action app, map a few fields, done — a pairing Zapier calls a "Zap." It has the largest catalog of app connections in the industry and an interface a complete beginner can succeed with in ten minutes.
The simplicity is also the ceiling. Zapier is built around mostly linear sequences; when your process needs real branching logic, loops over lists of items, heavy data reshaping, or unusual error handling, you start fighting the tool. It runs only on Zapier's servers (your data always passes through their infrastructure), and its pricing is metered per task performed, which means costs climb in step with your volume. For high-volume workflows, that meter becomes the dominant fact of the relationship.
Make (which was called Integromat until a 2022 rebrand — you will still see the old name in older tutorials) sits a step up in power. Like n8n, it is visual-first: you build "scenarios" (Make's word for workflows) on a canvas with genuine branching and iteration, and watch data flow through them. It is a capable, popular product, particularly loved by freelancers and agencies.
Like Zapier, Make is cloud-only and consumption-metered (by operations rather than tasks — same idea, different word). Its canvas is expressive but has its own learning curve, and when you outgrow what its built-in modules (Make's word for pre-built steps) offer, the escape hatches are narrower than n8n's. You cannot take Make home and run it on your own machines.
The developer's reflex: skip the platforms and write a program. A script is a small program, usually written to do one specific job — "every hour, fetch new orders and append them to the spreadsheet." Scripts offer total power and zero platform fees, and for a genuinely one-off, stable task written by someone who will stick around, a script is a fine answer.
The trouble is everything around the script. Where does it run, and what restarts it when the server reboots? Who gets notified when the API it calls changes its rules and the script starts silently failing? Where are the passwords stored? What happens when its author changes jobs? Automation platforms exist because those questions — scheduling, credentials, retries, logging, monitoring, handover — are 80 percent of the real work, and a platform answers them once for every workflow instead of once per script.
Watch out: The most dangerous script is the one that has worked flawlessly for two years. Nobody remembers how it works, its author may be gone, and the business process on top of it has quietly become load-bearing. If you inherit a company with automation, ask early: how much of it is unowned scripts?
For processes too important or too complex for off-the-shelf tools, you can pay professionals to build custom integration software. You get exactly what you specify, at consulting rates, on a consulting timeline — and every future change goes back through the same channel, at the same rates. For a stable, well-understood, high-value process this can be the right call. For the living, shifting mass of ordinary business processes — where the request is usually "can we also make it do X?" twice a month — it is the most expensive possible way to iterate.
n8n occupies a distinctive position in this landscape: the power of code with the accessibility of a visual tool, on infrastructure you can own.
The honest cost of all this is a somewhat steeper opening climb than Zapier's. n8n asks you to understand a little more about how data moves — which is precisely what Volume A of this book exists to teach you, gently.
| Zapier | Make | Custom scripts | Hired developer | n8n | |
|---|---|---|---|---|---|
| Building model | Guided forms, mostly linear | Visual canvas | Code | Code (someone else's) | Visual canvas, code optional |
| Where it runs | Vendor's cloud only | Vendor's cloud only | Wherever you put it | Wherever they put it | Vendor's cloud or your own machines |
| Complexity ceiling | Low–moderate | Moderate–high | Unlimited | Unlimited | High, with code as the escape hatch |
| Cost shape | Metered per task | Metered per operation | Free software, hidden labor cost | High up-front and per change | Subscription (cloud) or free license + your hardware (self-hosted) |
| Best fit | Simple links between popular apps, fast | Mid-complexity visual automation | One stable, well-owned job | Critical bespoke systems | Complex, high-volume, data-sensitive, or AI-heavy automation you want to control |
Tip: If you are choosing today, two questions cut through most of the marketing. First: is any of the data involved sensitive enough that "it passes through a third party's servers" is a problem? If yes, n8n self-hosted is on a very short list. Second: will this process ever need logic more complicated than "when A happens, do B and C"? If yes, you will eventually outgrow the simplest tools, and it is cheaper to start where you will end up.
n8n's license is unusual, frequently misunderstood, and worth five minutes of your attention, because it affects what you may legally do with the software.
First, the vocabulary — defined, as promised:
Open source software is software whose source code is public and whose license grants everyone broad freedoms: to use it for any purpose, study it, change it, and redistribute it, including commercially. "Open source" has a precise, guarded meaning in the software world; licenses like MIT, Apache, and GPL qualify.
Source-available software is software whose source code is public, but whose license withholds at least one of those freedoms. You can read the code, usually run it, often modify it — but the license draws a line somewhere, typically around reselling.
Fair-code is not a license but a philosophy — a term n8n itself coined, to describe both its own licensing model and those of similar companies whose code is source-available but commercially restricted. It describes a middle path: the software's source is open to read, it is free to use and self-host for most purposes, and the community may extend it — but the creators reserve one commercial right, so that the company building the software can survive. The problem fair-code answers is real: fully open-source projects have repeatedly watched large cloud vendors take their code, sell it as a hosted service, and capture the revenue that would have funded the original developers.
n8n's implementation of this idea is the Sustainable Use License (it adopted this license in 2022; very early versions used a different arrangement). In plain English, its terms amount to this:
The one-sentence version: free to use, not free to resell.
Watch out: Because of this reserved right, n8n is technically not open source under the strict definition, even though its code is public and using it costs nothing. You will see it called open source constantly — in blog posts, videos, sometimes even in casual vendor material — and the sloppiness is usually harmless. It stops being harmless the day you build a product that embeds n8n or offer it as a hosted service to others. If your plans run in that direction, read the actual license text and talk to the company first; the license file lives in the public code repository, and this book is not legal advice.
For an operator deciding whether to trust a platform, the license philosophy translates into concrete, practical properties:
You can inspect it. When you wonder what the software actually does with your credentials or your data, the answer is not "trust the brochure" — the code is public, and anyone (your security team, an auditor, a suspicious contractor) can go look.
You can leave the vendor without leaving the software. If you self-host, the software running your business is on your machines. If the company changed direction tomorrow, your installation would keep working exactly as it does today, and the public source code would still exist. Compare that with a cloud-only platform, where the vendor shutting a feature — or a pricing tier — changes your reality overnight.
Your data can stay home. With self-hosting, customer records, financial data, and health information need never transit a third party's infrastructure. For some industries this is a preference; for some it is the law.
The community compounds. A public codebase attracts a large community that builds extensions (Chapter 15 covers these "community nodes"), shares thousands of ready-made workflow templates, and answers questions in public forums. When you search for help with an obscure n8n problem at midnight, the depth of that commons is what you are drawing on.
The company has a visible business model. This one is underrated. A tool this central to your operations needs to exist in five years. The fair-code arrangement is explicit about how the company earns money (hosted cloud, enterprise features, embedding licenses — all detailed in Chapter 2), which is a healthier sign than either a free tool with no visible income or a proprietary one you cannot audit or escape.
You now hold the foundation. Automation exists to absorb the repetitive relay work between the specialized tools a business runs on. Its grammar is five words: workflows made of a trigger and actions, connecting apps through integrations, which are built on APIs. n8n's particular offer within that world is high-ceiling visual automation — code when you want it, never as a requirement — on infrastructure you may own outright, under a license that is free for internal use and honest about how its maker survives.
Two chapters complete this foundation. Chapter 2 (The n8n Product Family and How It Is Sold) maps the concrete forms n8n comes in — the hosted cloud service, the self-hosted editions, the enterprise and embedding options — and how to choose among them; everything about plans and pricing lives there. Chapter 3 (The Core Mental Model: Workflows, Nodes, Items, and Executions) then introduces the four ideas that govern how n8n actually thinks, and it is the single highest-leverage chapter in this book: readers who internalize its item model find everything afterward easy, and readers who skip it fight the tool for months. After the workspace tour in Chapter 4, you will build your first working automation in Chapter 5.
The copying, the re-typing, the swivel chair: that work has an expiration date. Turn the page.
n8n is one product with several front doors. The workflow editor, the node library, the execution engine — everything you will learn in the rest of this compendium — is essentially the same whether you pay n8n to host it, run it yourself for free, buy an enterprise license for your own servers, or license it to live inside a product you sell. What changes between those doors is who operates the machine, which team-and-governance features are switched on, and how the bill is calculated.
This chapter maps the whole family so that, for the rest of the set, a phrase like "this is plan-gated" or "Cloud only" lands with precise meaning. It also explains the single most important commercial fact about n8n — that pricing is based on executions, meaning whole workflow runs, not individual steps — and closes with a short orientation to the ecosystem that surrounds the product: templates, docs, forum, and community nodes. What this chapter deliberately does not do is teach you how to install or scale anything; that is Volume G territory, especially Chapter 32 (Self-Hosting from Zero) and Chapter 33 (Scaling and Performance).
One honesty note before the map: names, prices, and plan boundaries are the most changeable part of any software product. Everything here describes the shape of the offering as of this writing, in deliberately qualitative terms. When you need an exact figure — a price, an execution allowance, a concurrency cap — check n8n's pricing page directly. The structure described here has been stable for years; the numbers on it move.
Here is the family portrait in one table. Each row is a distinct way to acquire and run n8n.
| Offering | Who hosts it | What it costs | Who it is for |
|---|---|---|---|
| n8n Cloud | n8n hosts it for you as a subscription service | A monthly or annual fee tied to a plan tier and an execution allowance | Individuals and teams who want zero server responsibility |
| Community edition (self-hosted) | You host it, on anything from a laptop to a cloud server | Free software; you pay only for your own infrastructure | Tinkerers, technical teams, cost-sensitive or privacy-sensitive deployments |
| Paid self-hosted (Business / Enterprise) | You host it; n8n licenses the advanced features | A paid license, arranged with n8n's sales team at the top tier | Organizations that need enterprise governance features and full control of the infrastructure |
| n8n Embed | You host it inside your own product | A commercial embedding license, negotiated with n8n | Software companies that want to offer n8n's automation power to their own customers, under their own brand |
A few definitions before we go deeper, because two of these terms carry a lot of weight:
Hosting means running the n8n server software somewhere and keeping it alive — applying updates, backing up the database, making sure it is reachable. When n8n hosts (Cloud), that is their problem. When you self-host, it is yours.
Licensing is separate from hosting. The community edition's source code is publicly available and free to use, but n8n also ships paid features — team permissions, single sign-on, deployment pipelines — that unlock only when a license key from a paid plan is present. This is why "self-hosted" and "free" are not synonyms: you can self-host for free, and you can also self-host on a paid enterprise license.
Tip: If you are brand new and just want to learn, the fastest path is a Cloud trial — n8n offers a free trial period with no credit card needed at the time of writing — or a free community edition on your own machine if you are comfortable running software locally. Everything you learn on one transfers to the other; the editor is identical.
n8n Cloud is the hosted, subscription version. You sign up, n8n provisions a private instance for you (your own URL, your own data, your own workflows), and everything in the browser from that moment on is identical to what a self-hoster sees — same canvas, same nodes, same execution list. The differences are operational: n8n applies version upgrades, manages the database, handles backups and uptime, and gives you an administrative dashboard for the account itself.
The Cloud plan ladder, at the time of writing, has four rungs: Starter, Pro, Business, and Enterprise. Rather than memorize their exact contents — which shift — it helps to understand what each rung is for.
Starter is the entry-level paid plan: one person or a very small team, a modest monthly execution allowance, and the full core product with only the lightest team structure. Everything you need to build real, production automations is here. What you give up relative to higher tiers is mostly headroom (fewer executions and less concurrency — the number of workflow runs allowed to happen simultaneously) and room to grow the collaboration and governance features, which scale up as you climb the ladder.
Pro is the working-team plan. The execution allowance grows substantially, concurrency limits rise, and — most importantly for this compendium's purposes — the projects model becomes central. A project in n8n is a container that groups workflows and credentials and controls who can see and edit them; it is the foundation of role-based access control (RBAC), which simply means assigning people roles like viewer, editor, or admin per project instead of giving everyone access to everything. Paid plans all include at least one shared project, and the number you get grows with the tier. Chapter 34 (Access, Security, and Secrets for Teams) covers this machinery in depth. Pro also typically extends how long execution history and workflow version history are retained.
Business sits between Pro and Enterprise and is aimed at organizations that need serious governance without a full enterprise procurement cycle. This is the tier where, at the time of writing, the heavier governance features start to appear: source control integration (connecting your n8n instance to a Git repository so workflow changes can be versioned and promoted between environments) and single sign-on (SSO — logging in through your company's identity provider, via standards like SAML or LDAP, instead of separate n8n passwords), along with larger allowances across the board. n8n has offered Business in both hosted and self-hosted forms at various points; treat the exact packaging as something to confirm on the pricing page.
Enterprise is the custom-priced, talk-to-sales tier, available both on n8n Cloud and self-hosted. It exists to satisfy the requirements a security or compliance team brings to the table: the deepest identity and directory integration on top of the SSO that Business already provides, log streaming (pushing a live feed of audit and execution events into your own observability or SIEM — security information and event management — platform), external secrets (storing credentials in a dedicated vault product rather than n8n's own database), extended data retention, uptime commitments in a service-level agreement (SLA), and the highest ceilings on projects, concurrency, and history.
The pattern to internalize: the ladder is not "more features for power users." It is "more governance for larger organizations." A solo operator on Starter and an enterprise team have the same canvas and the same nodes. What the enterprise buys is control over who touches what, proof of what happened, and integration with corporate identity and security tooling.
Almost everything about an n8n Cloud bill flows from one definition, so it deserves its own section.
An execution is one complete run of one workflow, from trigger to finish. If your workflow has three nodes, one run is one execution. If it has three hundred nodes, loops over two thousand rows of spreadsheet data, calls four APIs, and takes ten minutes — that is still one execution. n8n meters the run, not the steps inside it and not the volume of data passing through it. (Chapter 3 gives executions their full conceptual treatment, and Chapter 21 covers the execution log as a system of record.)
This is genuinely different from how much of the automation market prices. Several popular competitors charge per task or operation, meaning every individual step that fires inside a run consumes billable units. Under per-task pricing, making a workflow smarter — adding a deduplication step, an enrichment lookup, a formatting pass — makes it more expensive. Under n8n's per-execution pricing, complexity inside a workflow is free. The economic incentive flips: you are rewarded for building fewer, richer workflows rather than punished for it.
Because a bill is roughly plan fee + execution volume against your allowance, your monthly cost is driven by how often workflows run, which comes down to your triggers (Chapter 7 covers trigger design):
Watch out: The classic surprise bill in n8n comes from an aggressive schedule. A "check every minute" polling workflow executes on the order of forty-plus thousand times a month all by itself. Before activating anything on a fast schedule, ask whether the source system can push to a webhook instead — you get lower latency and fewer executions. Chapter 14 (Webhooks In Depth) shows how.
Each Cloud plan includes a monthly execution allowance, with higher tiers including more. What happens when you exceed it — hard stop, overage billing, or a prompt to upgrade — is plan-dependent and has changed over time, so verify the current behavior rather than assuming. Two secondary meters also vary by plan: concurrency (how many executions may run at the same instant; excess runs queue rather than fail) and retention (how long finished executions remain inspectable in your history). Neither affects correctness of your automations, but both affect debugging comfort and throughput at scale.
For self-hosters, none of this metering applies to the software itself: the community edition imposes no execution counting. Your "bill" is your server, and your ceiling is your hardware — which is Chapter 33's subject.
The community edition is the free version of n8n that you download and run on your own machine or server. It is the same core application: the full editor, the full standard node catalog, webhooks, scheduling, queue-based scaling, unlimited workflows, and unlimited executions. For a great many real businesses, it is all the n8n they will ever need.
n8n describes its licensing model as fair-code, and the main license is called the Sustainable Use License. In plain terms: the source code is public and you can read it, run it, and modify it freely for your own internal business purposes — automating your company's operations, running client work, building on top of it. What you cannot do without a commercial agreement is take n8n and sell it as n8n — that is, offer it to others as a hosted automation service or embed it in a product you charge for. (The embedding case is exactly what the n8n Embed license, below, exists to permit.)
This is different from a classic open-source license, which would allow unrestricted commercial resale, and different again from closed-source software, where you cannot see the code at all. The practical takeaway for an operator: if you are automating your own or your clients' work, the community edition's license almost certainly covers you; if your business model is "resell n8n itself," talk to n8n.
The community edition lacks the licensed governance features: no projects and RBAC (all users on the instance share broad visibility), no SSO, no source-control environments, no log streaming, no external secrets integration. You can create multiple user accounts with basic role separation, but the fine-grained project model belongs to paid plans. You also carry the full operational load — updates, backups, security hardening, uptime — which Chapter 32 treats seriously rather than hand-waving.
There is a half-step between "free and anonymous" and "paid": if you register your community instance with an email address, n8n unlocks a small bundle of convenience features at no cost. At the time of writing the bundle includes folders (organizing workflows hierarchically instead of one flat list), debug in editor (copying data from a past execution back into the editor so you can re-test against a real payload — a technique Chapter 22 leans on heavily), a short window of workflow history (automatic snapshots letting you revert recent changes, retained for about a day on the free unlock versus much longer on paid plans), and custom execution data (tagging executions with searchable metadata, covered in Chapter 21). Registration is a one-time step offered during setup, and the unlock does not expire.
Tip: If you self-host, register. There is no meaningful downside, and debug-in-editor alone will repay you the first time a webhook workflow misbehaves and you want to replay the exact payload that broke it without waiting for the real event to happen again.
The third door combines the previous two: you run n8n on your own servers, but with a paid license key that switches on the governance features. This is how a bank, a hospital network, or any organization with strict data-residency rules gets projects and RBAC, SSO, environments, log streaming, and external secrets without their workflow data ever leaving infrastructure they control. n8n has at times offered a mid-tier self-hosted plan (packaged under the Business name) alongside self-hosted Enterprise; the top tier is arranged through sales and can include support commitments and deployment assistance, including for air-gapped environments — networks deliberately disconnected from the public internet.
Mechanically, the difference from the community edition is small: the same software checks for a license key and lights up the licensed features when it finds one. Operationally, everything Chapter 32 and Chapter 33 teach about self-hosting applies identically.
The fourth door is the one most readers will never open but should know exists. n8n Embed is a commercial license for software companies that want to put n8n's workflow-building capability inside their own product — so their customers get a visual automation builder without the vendor writing one from scratch. White-labeling means the embedded editor can be re-skinned and re-branded so it appears to be a native part of the host product; end users may never see the name n8n at all.
Embed arrangements are negotiated directly with n8n, typically priced on the scale of the embedding (for instance, the number of customer instances), and come with the legal permission the Sustainable Use License otherwise withholds: reselling n8n's functionality as part of a paid product. If you run a SaaS company and your roadmap says "let customers build their own integrations," Embed is the make-versus-buy conversation to have. The platform surface that makes deep embedding practical — the public API, CLI, and related tooling — is Chapter 35's subject.
Throughout this compendium, chapters will occasionally flag a capability as plan-gated. Here is the master reference those flags point back to. The middle column tells you what the feature is; the right column tells you where it typically lives on the ladder as of this writing — always confirm current placement before making a purchasing decision.
| Feature | What it is | Where it typically lives |
|---|---|---|
| Projects & RBAC | Containers that group workflows and credentials, with per-person roles | Paid plans; project counts and custom roles grow with tier (Ch 34) |
| Folders | Hierarchical workflow organization | Paid plans and registered community edition |
| Workflow history | Automatic version snapshots with revert | Short window on registered community; longer retention on higher tiers (Ch 10) |
| Debug in editor | Replay past execution data inside the editor | Paid plans and registered community edition (Ch 22) |
| Source control & environments | Git-backed versioning and promotion between dev/staging/production instances | Business and Enterprise tiers (Ch 35) |
| SSO (SAML/LDAP) / directory integration | Login through your corporate identity provider | Business and Enterprise tiers (Ch 34) |
| Log streaming | Real-time event feed into your observability/SIEM stack | Enterprise (Ch 25) |
| External secrets | Credentials held in a dedicated vault product instead of n8n's database | Enterprise (Ch 34) |
| Extended insights & log retention | Longer look-back on execution and usage analytics | Grows with tier; longest at Enterprise (Ch 25) |
| Scaled concurrency | More simultaneous executions | Grows with tier on Cloud; hardware-bound when self-hosted (Ch 33) |
| SLA & dedicated support | Contractual uptime and response commitments | Enterprise |
Notice what is not on this list: nodes, integrations, the expression language, AI and agent capabilities, webhooks, unlimited workflows. n8n does not gate the building blocks. The paywall runs almost entirely through team governance, compliance, and operational headroom.
Watch out: Third-party blogs and videos frequently misstate which features are free, partly because the boundaries have genuinely moved over the years (some features have migrated down the ladder, others up). When it matters — before a purchase, before an architecture decision — trust only n8n's own pricing page and documentation, dated recently.
You do not need to make this decision today, and nothing in Volumes A through F depends on it. But since "which one should I use?" is usually the first question a new operator asks, here is the honest framework. Treat it as orientation; the operational detail lives in Chapter 31 (Operating n8n Cloud Like an Owner) and Chapter 32 (Self-Hosting from Zero).
Ask yourself five questions:
1. Do you have someone to feed the server? Self-hosting is not hard to start — Chapter 32 will have you running quickly — but it is a standing commitment: security updates, database backups, disk space, restoring service when something breaks at an inconvenient hour. If nobody on your team wants that pager, Cloud's subscription is buying you an operations team, and that is usually a good trade for non-technical organizations.
2. Where must your data live? Every piece of data flowing through your workflows passes through the n8n instance. If regulation, client contracts, or internal policy require that data stay on infrastructure you control — or within a specific country — self-hosting answers that cleanly. Cloud publishes its hosting arrangements; check them against your requirements rather than assuming either way.
3. What is your cost shape? Cloud costs scale with your plan and execution volume: predictable, but rising as automation succeeds. Self-hosting costs are mostly flat — a server bill plus your time — regardless of whether you run a hundred executions a month or a hundred thousand. High-volume, technically capable teams often find self-hosting dramatically cheaper; low-volume teams often find Cloud cheaper once their own labor is priced honestly.
4. Which gated features do you need, and where do they live? Consult the paywall map above. If you need SSO and log streaming, you are in a top-tier conversation whichever hosting mode you choose. If you need none of the governance features, the free community edition covers the entire technical surface of the product.
5. How much do you customize? Self-hosted instances can install any community node (see below and Chapter 15), pin their own upgrade schedule, tune environment variables, and run custom code with full freedom. Cloud is more curated: upgrades arrive on n8n's cadence, and community-node installation is restricted to a vetted subset at the time of writing. Heavy customizers lean self-hosted.
There is no wrong answer, and it is not a one-way door: workflows export as JSON files (a portable plain-text data format; Chapter 10) and move between instances readily, so many teams prototype on Cloud and later migrate to self-hosting — or the reverse — with modest effort.
Tip: A common and sensible pattern for small technical teams: learn and prototype on a Cloud trial, then decide with real usage data in hand. Two weeks of actual executions tells you more about your cost shape and feature needs than any amount of forecasting.
Finally, the product does not stand alone. Four surrounding resources will show up constantly in your n8n life, and knowing what each is for saves you from searching in the wrong place.
The template library. n8n maintains a public gallery of thousands of ready-made workflow templates — complete, importable workflows contributed by n8n and its community, covering everything from "sync form submissions to a spreadsheet" to full AI agent architectures. Templates are reachable from n8n's website and from inside the editor itself, and any template can be imported into your instance and modified. Chapter 6 discusses using templates as one of the three ways to start a build; treat them as sketches to adapt, not products to trust blindly — you must still connect your own credentials and verify the logic.
The documentation. The official docs (at n8n's docs site) are the reference companion to this compendium: exhaustive per-node parameter listings, hosting guides, API references, and release notes. This compendium teaches you how to think in n8n; the docs are where you look up the precise option name on a node you are configuring. Keep both open.
The community forum. n8n runs an active public forum where users and staff answer questions, announce releases, and dissect problems. It is the single best place to search when you hit an error message that makes no sense — odds are high someone has hit it before — and the right place to ask when searching fails. It also functions as the product's public changelog conversation: breaking changes and new features get discussed there in the open.
Community nodes. Beyond the built-in integration catalog (Chapter 12), anyone can publish additional nodes as installable packages, extending n8n to services the core team has not covered. Self-hosted instances can install any of them; Cloud instances can install from a verified subset at the time of writing. They vary in quality and are maintained by their authors, not by n8n — Chapter 15 covers how to evaluate, install, and even write them.
Between these four — plus a large orbit of unofficial YouTube tutorials, courses, and consultants of varying quality — you will rarely be stuck alone. The forum and docs are official and reliable; everything else deserves the same dated-source skepticism as any fast-moving software topic.
That completes the commercial map. You now know the four doors into the product, what an execution is and why it is the unit of money, where the paywall actually runs, and where the surrounding ecosystem lives. From here, the compendium returns to the product itself: Chapter 3 builds the core mental model — workflows, nodes, items, and executions — that every subsequent chapter stands on.
Every automation you will ever build in n8n — from a two-step "copy this form response into a spreadsheet" to a multi-branch AI agent that answers support tickets — is assembled from the same seven primitives: the workflow, the node, the connection, the trigger, the item, the credential, and the execution. Once these seven click into place, the rest of the platform stops feeling like a wall of features and starts feeling like variations on a theme. This chapter teaches the seven on paper, without asking you to build anything yet. Hands-on building starts in Chapter 5 (Your First Workflow and the Capability Map), and the workspace itself is toured in Chapter 4 (A Guided Tour of the Workspace).
One of the seven matters more than the others. The single most important idea in n8n is this: data travels between nodes as a list of JSON items, and most nodes run once per item. If you internalize only one sentence from this entire volume, make it that one. Most confusion beginners experience — "why did it send five emails?", "why is my message repeated?", "why did only the first row come through?" — traces back to that sentence. We will unpack it slowly, with a concrete five-row example, and then walk one complete workflow end to end so you can see all seven primitives cooperating.
Here is the whole vocabulary of this chapter in one table. Do not worry about memorizing it now; each row gets its own section below.
| Primitive | What it is | Everyday analogy |
|---|---|---|
| Workflow | A saved automation: a named canvas holding nodes and their connections | A recipe card |
| Node | One step in the workflow that does a specific job | One instruction in the recipe |
| Connection | The wire linking one node's output to another node's input | The "then" between instructions |
| Trigger | The special node that decides when the workflow runs | The oven timer that starts the cooking |
| Item | One unit of data flowing through the workflow, expressed as JSON | One order ticket in a kitchen |
| Credential | Saved login details that let nodes act on your behalf in other services | A keycard that opens a specific door |
| Execution | One recorded run of a workflow, from trigger to finish | A dated entry in the kitchen's logbook |
A workflow is the unit of automation in n8n. It is a named document that contains a set of nodes, the connections between them, and the settings that govern how they run. When you open a workflow in the editor, you see it as a canvas — a large scrollable surface where each node appears as a card and each connection as a line between cards. Data flows along those lines, conventionally from left to right.
Under the hood, a workflow is stored as a structured text document (in the same JSON format we will meet shortly, as it happens). That has a practical consequence you will use constantly: workflows can be copied, pasted, exported, shared, imported from templates, and version-controlled like any other file. When someone shares "an n8n workflow" in a forum post, they are sharing that document, and you can paste it straight onto your own canvas.
A workflow also carries housekeeping metadata: a name, optional tags for organizing your list, ownership and sharing settings on team plans, and — critically — whether it is published (its triggers live) or still an unpublished draft. That state is the hinge of the workflow lifecycle, and we return to it at the end of this chapter.
There is no meaningful limit to how small or large a workflow can be. Two nodes is a legitimate workflow. So is sixty. In practice you will learn to keep individual workflows focused and compose bigger systems out of several workflows calling each other — a pattern covered in Chapter 9 (Flow Control: Branching, Looping, Waiting, and Sub-workflows).
A node is one step in a workflow — a self-contained block that receives data, does one job, and passes data on. Every capability n8n has is packaged as a node. Broadly, nodes come in three families:
Every node has parameters — the settings you fill in to tell it exactly what to do. A Gmail node's parameters include which operation to perform (send, reply, search), who the recipient is, and what the subject line says. Parameters can hold fixed values you type in, or expressions — small snippets wrapped in double curly braces that pull values out of the data flowing in. Expressions are how a workflow says "send the email to whatever address is in this item" rather than to one hard-coded address. They get a full treatment in Chapter 17 (Expressions: The Double-Curly-Brace Language); for now, just know the mechanism exists.
One more distinction worth planting early: a node describes what to do, but the data arriving at the node determines how many times it does it. Hold that thought for the items section.
A connection is the line that carries data from one node's output to another node's input. On the canvas you create one by dragging from the small circle on the right edge of a node to the left edge of another. Connections are directional: data flows from output to input, never backward.
Connections are also where a workflow's shape comes from:
Branching, merging, and looping are Chapter 9's territory. The mental model to take from here is minimal and load-bearing: a workflow is a directed graph — boxes and one-way arrows — and reading one is just following the arrows and asking, at each box, "what comes in, what goes out?"
A trigger is the node that answers the question "when does this workflow run?" Every workflow that runs on its own needs at least one. Triggers come in a few temperamental styles:
Whatever the style, the trigger's other job is to produce the workflow's first data. A webhook trigger emits whatever was sent to it. A "new row" trigger emits the new rows. That output is the raw material every downstream node works on — which brings us to the heart of the chapter.
This is the section to read twice.
JSON (JavaScript Object Notation, pronounced "JAY-son") is a plain-text format for writing down structured data so that both humans and software can read it. Despite the name, it long ago outgrew JavaScript; it is the common tongue of the modern web, and it is the format n8n uses for everything. The rules fit in a paragraph:
"name": "Ada Diallo". Keys are
always in double quotes.true or false (a boolean), or
null meaning "deliberately empty."{ } group key–value pairs into an
object — one bundle of related facts.[ ] hold an ordered
list (formally an array) of values, which can
themselves be objects.Here is one small, legal JSON object describing a sales lead:
{
"name": "Ada Diallo",
"email": "ada@example.com",
"company": "Brightline Labs",
"score": 82,
"newsletter": true
}Read it aloud as sentences: the name is Ada Diallo, the score is 82, newsletter is true. That is all JSON is — sentences about data, written in a strict enough style that software never has to guess.
Tip: When a blob of JSON looks intimidating, narrate it. Every
{opens the phrase "a thing whose...", every[opens "a list of...". The nesting that looks like noise on screen becomes ordinary grammar out loud.
In n8n, one JSON object traveling through a workflow is called an item. The lead above, flowing between nodes, is one item. An item can also carry an attachment of binary data — a file such as a PDF or an image that is not itself JSON — riding alongside the JSON like a paperclipped document; Chapter 20 (Files and Remembered State) covers that side. For this chapter, item means "one bundle of JSON."
And here is the rule that everything else in this book leans on:
Between any two connected nodes, what travels is not a single value and not a free-form blob — it is a list of items. Always a list. When there is only one thing to send, it is a list containing one item. When there is nothing, it is an empty list. The uniformity is the point: every node in n8n is built to accept a list of items and emit a list of items, which is why any node can be wired to almost any other.
Now the second half of the golden sentence. When a list of items arrives at a node, the node does not process the list as one lump. Most nodes execute their job once for each item in the list, top to bottom, and emit one output item per input item. The node's parameters — especially any expressions in them — are re-evaluated for every item, so each run can use that item's own values.
Watch what this means concretely. Suppose a Schedule trigger fires at 08:00 and the next node reads a spreadsheet of new sign-ups, finding five rows. Those five rows leave the spreadsheet node as five items:
[
{ "name": "Ada Diallo", "email": "ada@example.com", "plan": "pro" },
{ "name": "Ben Ochoa", "email": "ben@example.com", "plan": "free" },
{ "name": "Chloe Marsh", "email": "chloe@example.com", "plan": "pro" },
{ "name": "Dev Patel", "email": "dev@example.com", "plan": "free" },
{ "name": "Erin Walsh", "email": "erin@example.com", "plan": "pro" }
]Connect a "send email" node next, with the recipient parameter set by
expression to each item's email field, and that node runs
five times — one email to Ada, one to Ben, and so on,
each greeting its own recipient by its own name. You configured the node
once; the item list supplied the repetition. There is no visible loop on
the canvas, no counter, no "for each" scaffolding. The loop is implicit
in the data.
This is the trait that most sharply separates n8n from ordinary intuition about "a flowchart." In a flowchart, a box happens once. In n8n, a box happens once per item, and the number of items is decided upstream at run time. Five rows today, zero tomorrow, four hundred on Monday — same workflow, no edits.
Watch out: The implicit loop cuts both ways. If a trigger hands your workflow fifty items and a later node posts a message to your team channel, you will post fifty messages. When a node should act once per batch rather than once per item — "send one summary of all fifty" — you must first collapse the items into one, using tools like the Aggregate node. The habit to build now: before adding any node with side effects, ask "how many items will reach this, and do I want the action repeated that many times?"
A small number of nodes deliberately break the once-per-item pattern because their whole purpose concerns the list itself: nodes that aggregate many items into one, split one item into many, sort or limit the list, merge two lists, or route items down different branches. You will meet them naturally as you build. The precise mechanics — how items are paired across nodes, how expressions address "the current item," what lives under the hood of the item structure — are the deep dive of Chapter 16 (Reading and Reasoning About Data: The Item Model in Practice). At this altitude you need only the golden sentence and its corollary: to predict what a workflow will do, track the item count at every arrow.
Most useful nodes act on systems that require you to prove who you are — your email account, your CRM (customer relationship management system — the database of customers and deals), your payment processor. A credential is n8n's way of storing that proof once, securely, so nodes can use it without you pasting secrets into every workflow.
A credential is a named, saved bundle of authentication details for one service: an API key (a long secret string a service issues so software can act on your account), a username and password, or an OAuth connection (the "sign in with Google"-style handshake where you approve access on the service's own site and never hand your password to n8n at all). You create a credential once — say, "Marketing Gmail" — and then any Gmail node in any workflow can simply select it from a dropdown.
The design principle to absorb is separation: credentials live outside workflows. A workflow document says "use the credential named Marketing Gmail"; it does not contain the secret itself. That is why exporting or sharing a workflow does not leak your keys, why rotating a password means updating one credential rather than editing forty workflows, and why a colleague can be allowed to use a shared credential in their workflows without being able to see the secret inside it. n8n stores credential secrets encrypted, and on team plans access to them can be scoped and shared deliberately. Setting up your first credentials, service by service, is Chapter 11 (Credentials from Zero); the team-scale governance story is Chapter 34 (Access, Security, and Secrets for Teams).
An execution is one complete run of a workflow: the trigger fires (or you click execute), data flows node to node until there is nothing left to do, and the whole episode is written down. The record includes when the run started, how long it took, whether it succeeded or failed, and — depending on your logging settings — the actual item data that entered and left every node along the way.
Executions have a small vocabulary of statuses you will quickly learn
to read at a glance: success (ran to the end),
error (a node failed and the run stopped, or was handed
to error handling), running (in progress right now),
and waiting (paused on purpose — for a timer, or for
something external to respond — a state you will meet in Chapter 9).
Each workflow has an executions list beside its canvas, and the
workspace has a global list covering all workflows, typically reachable
from the main left-hand navigation under Executions.
Two things make executions more than an audit trail. First, they are your primary debugging instrument: because n8n can record the items at every arrow, you can open a failed execution and see exactly what data reached the node that broke — no guesswork, no printouts. You can even load a past execution's data onto the canvas and re-test against it. Second, they are your system of record for proving the automation is doing its job: how often it runs, how often it fails, what it processed. Retention (how long records are kept, and how much item data is stored) varies with plan and configuration, so treat specifics as something to check in your own workspace. Chapter 21 (Executions: The System of Record) covers the machinery; Chapters 22 and 23 build the debugging and error-handling craft on top of it.
Tip: From your very first workflow, make the executions list the first place you look when anything behaves oddly — before re-reading node settings, before editing anything. The recorded data almost always answers "what actually happened?" faster than reasoning from the canvas can.
Time to put all seven primitives in motion at once. No building — just careful reading. Here is a small, realistic workflow, the kind a one-person business might genuinely run. Its job: every morning, look for yesterday's new sign-ups in a spreadsheet, welcome the paying ones personally, and post one summary to the team chat.
The canvas, described left to right:
Ops Google account.plan field equals "pro". Two outputs: true and
false.Founder Gmail.#growth. Uses
credential Team Slack.Now run it in your head, tracking item counts at every arrow — the discipline this chapter has been building toward.
08:00. The schedule trigger fires. An execution begins and is assigned to this run; everything that follows belongs to it. The trigger emits one item (a timestamp — triggers always emit something, so downstream nodes have an input). Count: 1.
Google Sheets. The node presents its saved credential to Google, reads the sign-up rows, and receives five — our Ada-through-Erin list from earlier. It emits five items. Count: 5.
If. The node evaluates its condition once per item —
five evaluations. Ada, Chloe, and Erin have "plan": "pro"
and exit through the true output; Ben and Dev exit through false. No
data was changed; items were only routed. Count: 3
true, 2 false.
Gmail. Three items arrive, so the node runs three times, re-evaluating its expressions each time: one email to Ada greeting Ada, one to Chloe greeting Chloe, one to Erin greeting Erin. Note what you did not build: any loop. Three items in, three sends out. Count: 3 (email nodes pass their items through, typically annotated with send results).
No-op / Merge. Ben and Dev drift through the false branch untouched. The Merge node reunites the streams. Count: 5.
Aggregate. Here the once-per-item pattern is deliberately broken: five items in, one item out, containing all five sign-ups as a list under a single key. This is the collapse move from the earlier callout, exactly where it belongs — just before a node that should act once. Count: 1.
Slack. One item arrives, so the node runs once, posting a single message: "5 sign-ups yesterday, 3 pro — Ada, Chloe, Erin." Count: 1. Nothing remains to do; the execution closes with status success, its every arrow's data recorded.
Every primitive appeared: a workflow contained the whole design; nodes did the jobs; connections gave it shape, including a branch and a reunion; a trigger decided the timing; items carried the data and silently supplied all the repetition; credentials opened three different doors without a secret appearing anywhere on the canvas; and an execution recorded the episode for tomorrow's you.
Tip: Do this paper-trace deliberately for the first several workflows you build: walk the arrows and write the item count at each one before you run anything. It feels remedial for about a week, and then it becomes the instinct that lets you predict a workflow's behavior — and spot the missing Aggregate — at a glance.
One question remains: our workflow ran "at 08:00" — but what made n8n watch the clock at all? The answer is publishing, and around it, the workflow's lifecycle.
Every workflow is either an unpublished draft or published. A draft runs only when you manually execute it in the editor. Once you publish a workflow, its triggers go live — n8n starts watching the schedule, listening at the webhook address, polling the app — and the workflow runs on its own, whether or not you are logged in. You publish with a button in the top-right of the editor; that button also carries an unpublish option, which stands the triggers back down.
Tip: If you have used older n8n, or are following a tutorial written for it, you will remember an Activate/Deactivate toggle instead of a Publish button. n8n's 2.0 release (late 2025) reworked this: the switch became a button, and — the change that matters most — saving your edits and pushing them live became two separate acts (the watch-out below spells this out). The underlying idea is unchanged: a live workflow's triggers fire on their own; a draft's do not. Workflows that were "active" before the change were simply carried over as published.
That distinction splits executions into two kinds you will constantly tell apart:
Execute workflow), the workflow runs immediately in front
of you against your current draft, and the resulting data appears node
by node on the canvas for inspection. You can also execute a single node
at a time to check a step in isolation. Test runs work whether or not
the workflow is published — a draft is fully runnable by hand.Webhook-triggered workflows sharpen the distinction further: a webhook trigger has both a test URL, which listens only briefly while you are actively testing in the editor, and a production URL, which works whenever the workflow is published. Chapter 14 (Webhooks In Depth) makes heavy use of this pair.
Watch out: The classic beginner trap is configuring a real system to call the test webhook URL, watching it work beautifully during the session, and then wondering why everything went silent the next day. The test URL stops listening when you stop testing. Production systems must point at the production URL, and the workflow must be published.
The lifecycle, then, runs like this. You create a workflow; it is born a draft. You build and test, iterating with manual runs until the behavior is right; Chapter 10 (Test, Fix, Activate, and Keep It Tidy) turns this stage into a craft. You publish — and the triggers go live. (A workflow whose only trigger is manual has nothing to make live, so publishing matters for workflows with schedule, webhook, or app triggers.) From then on, production runs accumulate in the executions list, and you monitor — the concern of Volume E. Eventually you iterate: open the workflow, adjust, and, when the new version is ready, publish again.
Watch out: Saving and publishing are not the same thing. Saving your edits keeps them as a draft and does not touch the running workflow; production keeps executing the last published version until you deliberately publish the new one. (In current versions your edits are saved for you automatically as you work, which makes this easy to forget.) That separation is a safety feature — half-finished changes cannot leak into production — but it also means a fix you saved has not gone live until you publish it. On older, pre-2.0 instances the rule is reversed and much sharper: there, saving an active workflow is deploying, so rehearse consequential changes on a deactivated or duplicated copy first. Chapter 10 gives you a tidy routine either way; Chapter 35 covers source control for teams who want history and rollback.
Finally, unpublishing is always reversible and loses nothing: the workflow, its nodes, and its execution history remain; only the live triggers stand down. Workflows can also be archived or deleted from the workflow list when their day is done.
A workflow is a canvas of nodes wired by connections. A trigger decides when it runs and supplies the first data. Data moves between nodes as a list of JSON items, and most nodes run once per item — so the data, not the diagram, supplies the repetition. Credentials let nodes act inside your other systems while living safely outside the workflow itself. Every run is an execution, recorded and inspectable. Drafts run by hand; published workflows run alone.
Seven primitives, one golden sentence. In Chapter 4 you will see where each of these lives on screen, and in Chapter 5 you will build your first workflow and feel the item list flow under your own hands.
Every tool has a geography, and you learn a tool faster when you can hold its map in your head. This chapter is that map. You will sign up for an n8n Cloud trial — the zero-install way to get a working copy of n8n in front of you — and then walk every major surface of the product: the canvas where workflows are built, the panels where nodes are configured, the lists where workflows, executions, and credentials live, the templates gallery, the data tables, the projects switcher, the settings, and the built-in AI Assistant.
One promise before we start walking: this chapter is the map, not the manual. Each surface gets a single paragraph explaining what it is for and which volume of this compendium covers it in depth. When you finish, you will know where everything is and where to read more — and nothing here requires you to build anything yet. The building starts in Chapter 5 (Your First Workflow and the Capability Map).
A second note, because software drifts: n8n ships updates frequently, and labels occasionally move or get renamed. This tour describes the stable geography — what each area is for and roughly where it lives — rather than pixel-precise directions. If a label in your version differs slightly, the room it names will still be there.
There are two ways to get n8n running: let the vendor host it for you (n8n Cloud), or install it on a machine you control (self-hosting). For a first tour, Cloud is the obvious choice because there is nothing to install, patch, or secure — you sign up in a browser and you are looking at the real product minutes later. Everything you learn transfers: the editor is essentially the same whether n8n runs on the vendor's servers or your own. Self-hosted installation — Docker, databases, environment variables and all — is deliberately deferred to Chapter 32 (Self-Hosting from Zero), and the trade-offs between the two models were covered in Chapter 2 (The n8n Product Family and How It Is Sold).
Signing up follows the familiar software-as-a-service pattern. You go
to the n8n website, choose the Cloud sign-up path, and provide an email
address and password (or sign in with a supported identity provider).
Along the way you will be asked to name your workspace — and this name
matters more than it looks, because it typically becomes part of your
instance's web address, a subdomain along the lines of
your-name.app.n8n.cloud. An instance is your own
private copy of n8n: your workflows, your data, your URL, walled off
from every other customer. The sign-up flow may also ask a few
onboarding questions about your role and what you plan to automate;
these tune the suggestions you see later, and none of them are
binding.
Tip: Pick a workspace name you can live with — something like your company or team name rather than a throwaway. It becomes part of the URL that integrations and webhooks (inbound web addresses other systems call to reach your workflows) will point at, so a flippant choice can follow you around.
The trial itself gives you time-limited access to a paid tier's feature set — typically a couple of weeks, with an execution allowance that is generous for learning but capped — and you can usually start without entering payment details. That makes the trial a genuinely free sandbox: worst case, you let it lapse and have lost nothing but the workflows you built inside it. Exact durations, tiers, and allowances shift over time, so treat the sign-up page as the source of truth; Chapter 2 explains how the plans are structured, and Chapter 31 (Operating n8n Cloud Like an Owner) covers managing a paid workspace once you commit.
Watch out: When a Cloud trial expires without an upgrade, the workspace shuts down and is eventually deleted — including everything you built in it. n8n has historically allowed a grace period after expiry in which you can still download your workflows, but do not bet on it: before the trial ends, export anything you care about (each workflow can be downloaded as a JSON file from the editor's workflow menu) so your learning does not evaporate with the trial.
Once sign-up completes, your instance boots and drops you into the editor — the web application where all real work happens. Everything in the rest of this chapter lives inside it, with one exception we will meet first.
n8n Cloud has a split-level design that trips up newcomers, so let us
name it clearly. The editor (some documentation calls it the
workspace or Editor UI) is the application itself: canvas, workflows,
credentials, executions. The Admin Panel — the documentation
also calls it the Cloud admin dashboard — is a separate Cloud-only
surface that sits one level above the editor and manages the instance as
a thing — your subscription and billing, the n8n version your instance
runs, instance-level operations like restarting it, and account concerns
that exist whether or not anyone is building workflows. It belongs to
the workspace owner, and you reach it either from the
Admin Panel link near the bottom of the editor's left
sidebar or by signing in at n8n's cloud site directly; either way it
opens in place of the editor rather than inside it. The practical rule
of thumb: if the question is "how do I build or run automations?" the
answer is in the editor; if it is "how do I manage my subscription,
upgrade my plan, or restart my instance?" the answer is in the Admin
Panel. Self-hosters never see an Admin Panel at all — its
responsibilities fall on whoever operates the server. Chapter 31
(Operating n8n Cloud Like an Owner) owns this surface in depth.
When you log in, the editor opens on a home screen the product calls
the Overview, framed by a persistent left sidebar. The sidebar
is your primary navigation: at the top, Overview brings you
back home from anywhere; the middle section lists your projects (more on
those shortly); and the bottom collects instance-wide destinations — the
Templates entry point, Variables (a small
store of reusable key-value constants available on higher-tier plans,
which your expressions can read; they reappear in Chapter 17),
Insights, help, your account menu, and on Cloud the
Admin Panel link you just met. The Overview page itself is
a set of tabs — Workflows, Credentials,
Executions, and Data tables — showing
everything you have access to across the instance. Those four tabs are
the spine of the editor, and the next sections walk them in order.
The Overview > Workflows tab is the master list of
every workflow you can see — a workflow being, as Chapter 3
established, one saved automation: a set of connected nodes with a
trigger at the front. Each row shows the workflow's name, whether it is
active (switched on and responding to its trigger) or inactive, and when
it was last updated. Two organizing tools keep this list from becoming a
junk drawer: folders, which nest workflows hierarchically the
way a file system does, and tags, freeform labels you attach to
workflows and then filter by — a workflow lives in one folder but can
wear many tags. The create-workflow button here is where new automations
are born. Naming conventions, folder strategy, tagging discipline, and
the archive-versus-delete decision are the "keep it tidy" craft of
Chapter 10 (Test, Fix, Activate, and Keep It Tidy).
Tip: Start using folders and tags before you think you need them. Ten workflows feel manageable without structure; fifty do not, and retrofitting organization onto a flat list of cryptically named workflows is a chore you can avoid entirely by adopting a naming-plus-folders habit on day one.
The Overview > Executions tab is the system of record
for everything n8n has actually done. An execution is one run
of one workflow — every time a trigger fires or you press a test button,
an execution is created, and this list shows them all: which workflow
ran, when, whether it succeeded or failed, and how long it took. Click
any row and n8n opens that execution in a read-only view of the canvas
with the real data that flowed through each node — which is what makes
this list the front door of all debugging. Filters narrow the view to
one workflow, one status, or one time range. Everything about reading,
retaining, retrying, and reasoning from executions belongs to Volume E,
starting with Chapter 21 (Executions: The System of Record).
Watch out: Execution history is not kept forever. Instances prune old execution records after a retention window (how long depends on plan and configuration), so treat this list as a recent-history log, not an archive. If an execution's data matters for compliance or bookkeeping, Chapters 21 and 25 show ways to get it into storage you control.
The Overview > Credentials tab is the editor's locked
cabinet. A credential is a saved, encrypted bundle of
authentication details — an API key, a username and password, or an
OAuth connection (the "sign in with Google"-style handshake) — that lets
your workflows act on your behalf in other services. You create a
credential once, n8n stores it encrypted, and any node that talks to
that service can reuse it without you ever pasting a secret into a
workflow. The list shows each credential's name and type alongside when
it was created and last updated. Getting credentials right is
foundational enough to open a whole volume: Chapter 11 (Credentials from
Zero) walks the creation flows step by step, and Chapter 34 (Access,
Security, and Secrets for Teams) covers sharing and governance.
The Overview > Data tables tab is the newest of the
four: a small built-in database that lives inside n8n. A data
table is a spreadsheet-like grid — columns you define, rows your
workflows read and write — that gives automations a place to remember
things between executions without involving an external database or a
Google Sheet. Classic uses are lookup lists (customer tiers, routing
rules), deduplication logs ("have I already processed this record?"),
and lightweight queues. You can create and edit tables by hand here
(including importing a CSV to seed one), and a dedicated node lets
workflows operate on them. They are sized for state, not scale —
instances cap total data-table storage, so think megabytes of lookup
rows, not a data warehouse. Data tables share Chapter 20 (Files and
Remembered State: Binary Data and Data Tables) with binary data, because
both answer the same question — where does state live when a workflow
ends?
The Templates link in the sidebar leads to n8n's public
gallery of prebuilt workflows — thousands of community- and
vendor-contributed automations, browsable by app, category, and use
case. A template is a complete, working workflow you can copy
into your own instance with a click, then adapt: swap in your
credentials, adjust the logic, and activate. For a beginner this is the
single fastest route from blank canvas to something that runs, and even
experienced builders use templates as pattern references — "how do other
people connect these two systems?" Templates are one of the three
starting strategies weighed in Chapter 6 (Choosing What to Automate and
Three Ways to Start), which also covers how to evaluate one before you
rely on it — templates arrive with example data and no credentials, and
deserve a careful read before they touch your systems.
Open any workflow — or create a new one — and the editor switches from lists to the construction site. Four surfaces make up this view.
The canvas is the large gridded area in the middle of the workflow view: the drawing board where automations take shape. Nodes appear on it as cards, and the lines between them — connections — define the order in which data flows: out of one node's output side and into the next node's input, by convention left to right. You pan by dragging the background, zoom with the scroll wheel or the zoom controls, drag nodes to rearrange them, and draw connections by dragging from the small handle on one node's edge to the next node. The canvas is also where you run rehearsals: a test-execution button triggers the whole workflow manually so you can watch data move through it, with each node reporting success or failure right on its card, and sticky notes — colored annotation boxes that do nothing except hold your words — keep the picture legible for whoever reads it next. Everything about canvas fluency — selection, copy-paste, alignment, keyboard shortcuts, annotation habits — is the business of Chapter 8 (Building the Action Chain: Canvas and Node Mechanics).
Press the + button on the canvas (or the keyboard
shortcut, Tab on most setups) and the nodes panel
slides out: a searchable directory of every block you can add. Type a
service name — "Slack", "Google Sheets", "OpenAI" — and matching nodes
appear instantly; type an action — "send email", "filter" — and n8n
surfaces nodes that do that. The panel groups its contents sensibly:
triggers (nodes that start workflows, the subject of Chapter 7), app
integrations, data transformation nodes, flow-control nodes, and AI
capabilities. Each app entry expands into the specific operations it
supports, so you pick not just "Slack" but "Slack: send a message to a
channel". The mechanics of adding and wiring nodes live in Chapter 8;
the strategy of navigating the full integration catalog — hundreds of
services deep — gets its own treatment in Chapter 12 (Navigating and
Operating the Integration Catalog).
Double-click any node on the canvas and you enter the node details view — the configuration room where a node's actual behavior is defined, laid out as three panes. The left pane shows the node's input: the items that arrived from the previous node, viewable as a table, as JSON (the bracketed text format APIs speak), or as a schema of field names you can drag from. The middle pane holds the node's parameters — the settings for what this node should do, which credential to use, and which fields to send. The right pane shows the node's output after you press the execute-step button: exactly what this node produced, which the next node will receive. This input-configure-output loop is the tight feedback cycle that makes n8n learnable, and it leans entirely on the item model from Chapter 3. Chapter 8 covers operating this view; Chapter 16 (Reading and Reasoning About Data: The Item Model in Practice) teaches you to actually read what those panes are telling you.
Across the top of the workflow view runs a slim header that carries
the workflow's identity and life controls: its name (click to rename —
do this immediately; "My workflow 3" is future-you's enemy), its tags, a
Save button, a share control on team plans, a pair of
sub-tabs switching between Editor and this workflow's own
Executions history, a menu of workflow-level actions
(duplicate, download as a file, import, per-workflow settings), and —
most consequential — the Active toggle. Activating a
workflow tells n8n to run it automatically whenever its trigger
condition occurs: on a schedule, when a webhook arrives, when an app
event fires. Until you activate it, a workflow only runs when you
manually execute it in the editor. The full test-then-activate
discipline, including what changes about webhook URLs when you flip the
switch, is Chapter 10's territory, with triggers themselves covered in
Chapter 7 (Triggers: Deciding When Work Happens).
Watch out: Saving and activating are different acts.
Savepreserves your edits;Activeswitches the workflow on in production. A saved-but-inactive workflow will never fire on its own — and an active workflow keeps running your last saved version even while you edit, so an unsaved fix is not yet live. When something "mysteriously isn't running", check this toggle and the save state before anything else.
The remaining surfaces are about structure, visibility, and help rather than construction.
The middle of the left sidebar holds the projects list — n8n's mechanism for dividing one instance into separate compartments. Every user has a Personal project (your private sandbox), and on team-oriented plans you can create shared projects — "Marketing", "Finance Ops" — each with its own workflows, credentials, and member list, so the finance team's bank credentials are simply invisible to marketing. Clicking a project switches your whole context: the workflow, credential, and execution lists all rescope to that project. If you are alone on a trial, you can ignore projects entirely and live in Personal; the moment teammates arrive, projects become your main access-control tool. The full model — roles, sharing rules, and moving assets between projects — is owned by Chapter 34 (Access, Security, and Secrets for Teams), with the operational angle in Chapter 31.
The Insights entry in the sidebar (with a summary strip
that also appears on the Overview page) is n8n's built-in reporting
layer: aggregate charts of how many production executions ran, how many
failed, average runtimes, and an estimate of time saved by your
automations. Where the executions list answers "what happened in this
specific run?", Insights answers "how is the whole operation trending?"
— which makes it the surface you show a manager, and the first place you
notice a slow degradation like a rising failure rate. Availability of
the deeper views varies by plan. Reading Insights critically, defining
what "time saved" should mean for your team, and building monitoring
beyond the built-ins are the subjects of Chapter 25 (Monitoring,
Insights, and Proving Value).
Behind your account avatar and its menu near the bottom of the sidebar sits the settings area, which gathers everything about configuring the instance and your presence in it: your personal profile, password, and two-factor authentication (turn that on today), users and their roles on multi-user plans, API keys for n8n's own public API — the interface that lets external programs manage your n8n programmatically — plus, depending on edition and plan, sections for community nodes, single sign-on (one company-managed login shared across your apps), external secret stores, source control, and log streaming. Settings is a hallway with many doors, and nearly every door leads to a later chapter: workspace administration to Chapter 31, self-hosted configuration to Chapter 32, community nodes to Chapter 15, security features to Chapter 34, and the API, CLI, and source-control surface to Chapter 35 (The Platform Surface: API, CLI, Source Control, and Embed). For now it is enough to know the hallway exists and where it starts.
In a corner of the editor lives the AI Assistant — a chat panel, opened from its own button, that knows n8n and can see what you are working on. Ask it "how do I split one item into many?" and it answers from n8n's documentation; when a node fails, an assistant prompt appears on the error offering to diagnose it, and it can suggest concrete fixes to your configuration, expressions, or code. Two boundaries keep it in perspective. First, do not confuse the Assistant with n8n's AI building blocks: the Assistant helps you build workflows, while the AI Agent and model nodes of Volume F are components inside workflows that act on your data. Second, it is a knowledgeable colleague with no accountability — its suggestions deserve the same testing as your own guesses. The Assistant ships with n8n Cloud plans (subject to a usage allowance); on self-hosted instances it has not been generally available — support there has been pre-release at best — so treat it as a Cloud perk unless your edition says otherwise. Its debugging role gets practical treatment in Chapter 22 (The Debugging Craft).
Tip: The Assistant is at its best on "what is the n8n way to do X?" questions, because it draws on documentation you have not read yet. Asking it before you brute-force a problem with custom code will regularly reveal that a built-in node already does the job — a theme Chapter 19 (Code and Command: When Clicks Are Not Enough) returns to.
Here is the tour compressed into a reference table — where each surface lives, what it is for, and which chapter owns it.
| Surface | Where you find it | What it is for | Deep dive |
|---|---|---|---|
| Admin Panel (Cloud) | Admin Panel link, bottom of sidebar |
Subscription, billing, instance version and operations | Ch 31 |
| Overview | Sidebar, top | Home screen; cross-instance tabs | Ch 4 (here) |
| Workflows list | Overview > Workflows |
All workflows; folders, tags, active status | Ch 10 |
| Executions list | Overview > Executions |
History of every run; debugging entry point | Ch 21 |
| Credentials | Overview > Credentials |
Encrypted store of service logins and keys | Ch 11, Ch 34 |
| Data tables | Overview > Data tables |
Built-in database for workflow state | Ch 20 |
| Templates | Templates link in sidebar |
Gallery of prebuilt workflows to copy and adapt | Ch 6 |
| Canvas | Inside any open workflow | Visual construction of node chains | Ch 8 |
| Nodes panel | + on canvas |
Searchable directory of triggers and actions | Ch 8, Ch 12 |
| Node details view | Double-click a node | Input, parameters, output; per-node testing | Ch 8, Ch 16 |
| Workflow header | Top of workflow view | Name, tags, save, Active toggle | Ch 7, Ch 10 |
| Projects switcher | Sidebar, middle | Compartments with separate assets and members | Ch 34 |
| Insights | Insights in sidebar |
Aggregate run metrics and trends | Ch 25 |
| Settings | Account menu area | Users, API keys, instance configuration | Ch 31–35 |
| AI Assistant | Assistant button in editor | In-product help and error diagnosis | Ch 22 |
You now hold the map: an instance of your own, a clear split between the Admin Panel and the editor, and one honest paragraph of orientation for every surface you will spend the coming volumes inside. Nothing you clicked today committed you to anything — but the geography you just internalized is the difference between following the next chapters and merely reading them. Chapter 5 (Your First Workflow and the Capability Map) puts the map to work: you will build and run a real workflow end to end, and use it to survey what n8n can actually do. From there the volumes fan out exactly as the table above promises — and whenever you lose your bearings, this chapter is the page to fold back open.
The first four chapters were orientation. This chapter is where you stop reading and start building. You will construct one small but genuinely useful automation, click by click, and then push it into production — meaning it runs on its own, on a schedule, whether or not you are watching. Then, once you have seen every major part of n8n in miniature, the chapter hands you the capability map: a permanent index that matches each of n8n's capability areas to the volume and chapter of this compendium that covers it in depth. Bookmark that table. It is how you will navigate the rest of the set.
The workflow is a morning freeze alert. Every day at 7 a.m., n8n will call a free public weather service, check the current temperature for a location you choose, and — only if the temperature is at or below freezing — send you a message in Slack or by email. If it is warm, nothing happens, and that silence is the correct behavior.
It is deliberately modest, but it exercises the four moves that make up nearly every automation you will ever build:
A quick refresher on vocabulary, all covered properly in Chapter 3 (The Core Mental Model): a workflow is a saved automation — a set of connected steps. Each step is a node, a block on the canvas that does one job. Data moves between nodes as items, which are small packages of structured data. Each time a workflow runs, from trigger to finish, n8n records an execution — a complete, replayable log of what happened. You will meet all four in the next twenty minutes.
Every node used below has a full chapter of its own elsewhere in this compendium. This chapter uses each one at the shallowest depth that produces a real result; the cross-references and the closing tables tell you where the depth lives.
You need three things:
Tip: Do this chapter at a real keyboard with n8n open in the next tab. Reading a click-by-click build without clicking is like reading sheet music without a piano — technically possible, but nothing sticks.
Log in to n8n. You land on the home screen — labeled
Overview in recent versions — which lists your workflows,
credentials, and recent executions (Chapter 4, A Guided Tour of the
Workspace, walks the whole layout).
Click Create Workflow (top right). n8n opens the
editor: a large empty grid called the
canvas, where you will place and connect nodes, with a
toolbar across the top.
First, name it. Click the placeholder title at the top left of the
canvas — it reads something like My workflow — and type
Morning Freeze Alert. Press Enter. Naming things
immediately is a habit worth forming on day one: three months from now,
a list of workflows called "My workflow 7" is an archaeology
project.
Click Save (top right). n8n saves the workflow in its
current state — empty is fine. From here on, save whenever you finish a
step; n8n also warns you if you try to leave with unsaved changes.
Every workflow begins with a trigger node — the node that decides when the workflow runs. Nothing downstream can happen until a trigger fires. A workflow without a trigger is a script with no run button. Triggers get a full treatment in Chapter 7 (Triggers: Deciding When Work Happens); today you need just one.
In the middle of the empty canvas is a large prompt —
Add first step, or a plus symbol, depending on version.
Click it. A search panel slides out from the right listing everything
n8n can start a workflow with: manual starts, app events, incoming
webhooks, chat messages, and schedules. Type schedule and
select Schedule Trigger.
The node appears on the canvas and n8n opens its node details view: a three-part panel with input data on the left (empty, since a trigger has no input), the node's settings — called parameters — in the middle, and output data on the right. Every node you ever configure uses this same layout, so take a second to register it now.
Now set the schedule:
Days from the
interval dropdown. This tells n8n to fire once every N days.1 — every
day.7am and the minute to
0. Exact field labels shift slightly between versions
(Trigger at Hour, Trigger at Minute), but the
intent is unmistakable in the panel. The same dropdown also offers
seconds, minutes, hours, weeks, months, and a custom cron
expression — a compact scheduling syntax inherited from Unix —
none of which you need today.That is the entire configuration: fire once a day at 07:00.
Watch out: 7 a.m. in which timezone? A fresh workflow uses your instance's default timezone, which on a new self-hosted install may be UTC — meaning your "7 a.m." alert could arrive mid-afternoon. To pin it down, open the workflow's settings via the three-dot menu next to the
Savebutton and setTimezoneexplicitly for this workflow. Cloud workspaces let you set a sensible default for the whole workspace too (Chapter 31, Operating n8n Cloud Like an Owner).
One more thing to understand before moving on: a schedule only fires by itself once the workflow is active — switched on for production, which you will do in Step 7. While you are building, the schedule does nothing on its own; instead you run the workflow manually and n8n simulates the trigger firing. This split between manual (test) executions and production executions is fundamental, and Chapter 21 (Executions: The System of Record) covers it thoroughly.
Close the node details view with Back to canvas (or the
X in the corner). Your trigger sits on the canvas with a small clock
badge. Save.
Next, the workflow needs weather data. It will get it from a public API — an Application Programming Interface, which is simply a way for one program to ask another program for data over the web, using structured requests instead of clicks. The node for this job is HTTP Request, n8n's universal "talk to any web service" tool. It is arguably the most important node in the entire platform, and Chapter 13 (The HTTP Request Node: Talking to Any API) is devoted to it; here you will use it in its simplest form.
On the canvas, click the small + on the connector stub
to the right of the Schedule Trigger. The same search panel opens, now
showing regular (non-trigger) nodes. Type http and select
HTTP Request. n8n draws the new node connected to the
trigger by a line — the connection, along which items
will flow left to right.
The node details view opens. Configure two parameters:
GET. HTTP methods
are verbs; GET means "just give me data, change nothing."https://api.open-meteo.com/v1/forecast?latitude=52.52&longitude=13.41¤t=temperature_2m,wind_speed_10mThose coordinates are Berlin; swap in your own latitude and longitude
(any map service will give them to you — two decimal places is plenty).
Everything after the ? is a set of query
parameters: named values the API reads to know what you want.
Leave every other setting — authentication, headers, options —
untouched. This particular API needs no credential (no
stored login or key), which is exactly why it is the right first API:
you get to make your first external call with nothing to sign up for.
Credentials arrive in Step 5 and get their own ground-up chapter
(Chapter 11, Credentials from Zero).
Now the payoff. Click Execute step — the button in the
node details view that runs just this node. After a second, the
output panel on the right fills with data.
Look at it properly. The output panel offers three views, switchable
at the top of the panel: Table (rows and columns),
JSON (the raw structure), and Schema (the
field names and types, draggable). Click JSON. The real
response carries a few more fields than fit here — a units block, a
generation timestamp, and so on — but trimmed to what matters it looks
like this:
{
"latitude": 52.52,
"longitude": 13.41,
"timezone": "GMT",
"current": {
"time": "2026-07-17T06:00",
"temperature_2m": 18.3,
"wind_speed_10m": 11.2
}
}JSON (JavaScript Object Notation) is the
near-universal text format APIs use to structure data: named fields,
nested objects, lists. n8n has wrapped this response as one
item — one unit of data flowing to the next node. The
field you care about is temperature_2m, and note where it
sits: not at the top level, but nested inside an object called
current. Hold that address in your head — "the
temperature_2m field inside current" — because
you will use it in the next step. How items, fields, and nesting really
behave is Chapter 16's territory (Reading and Reasoning About Data).
Close the panel. Notice the canvas now shows a small item-count badge
(1 item) on the connection — a running tally of what flowed
where. Save.
Tip:
Execute stepon a single node is the fastest feedback loop in n8n. Build one node, run it, read the output, then build the next node against that real output. Builders who chain five unconfigured nodes and then wonder why nothing works are debugging five mysteries at once; builders who execute as they go are never more than one node away from the last thing that worked.
The workflow should only continue when it is actually freezing. The node for "keep going only if" is Filter: it examines each incoming item against a condition, passes through the items that match, and silently drops the ones that do not. (Its sibling, the If node, routes items down two separate branches instead of dropping them — that distinction, and all of branching, looping, and waiting, is Chapter 9, Flow Control.)
Click the + after the HTTP Request node, search
filter, and select Filter.
In the node details view, the left-hand input panel now shows the weather data arriving from the previous node — this is why you executed Step 3 first; real sample data makes configuration almost effortless. Build the condition:
Schema view if it is
not already showing. Find current and expand it to reveal
temperature_2m.temperature_2m from the input
panel and drop it into the first value field of the
condition row.Something important just happened. The field did not receive the
number 18.3; it received a small piece of code that looks
like {{ $json.current.temperature_2m }}. That is an
expression — n8n's double-curly-brace mini-language for
saying "at run time, read this value from the incoming item." Read it
once: $json means "the current item's data," and
.current.temperature_2m walks down into the nesting you
noticed in Step 3. Expressions are how workflows adapt to live data
instead of being hard-coded, and they are so central that Chapter 17
(Expressions: The Double-Curly-Brace Language) is entirely about them.
For today: drag the field, let n8n write the expression.
0.The condition now reads, in effect: let this item through only if the current temperature is at or below 0 °C.
Click Execute step. In July, the likely result is an
empty output — 0 items. The dropped item simply disappears;
unlike its sibling the If node, the Filter node keeps no second output
for what it rejected — non-matching items are gone. This is
success. The filter did its job: not freezing, nothing to
report, workflow ends here quietly. A surprising amount of automation
skill is learning to recognize when "nothing happened" is the system
working perfectly (Chapter 39, The Troubleshooting Encyclopedia, has an
entry for exactly this confusion).
Close and save.
Time for the action node. Take the Slack path if you live in Slack; take the email path if that is simpler. Either way, this is the step where you meet a credential: a stored, encrypted set of login details that lets n8n act on your behalf in another service. You create it once; every workflow can then reuse it, and you never paste passwords into nodes. This chapter narrates only the minimum; Chapter 11 (Credentials from Zero) explains every authentication style properly, and Chapter 12 (Navigating and Operating the Integration Catalog) covers app nodes like Slack in general.
Click the + after the Filter node, search
slack, and select Slack. Choose the
message-sending action — resource Message, operation
Send. Then, in the parameters panel:
Connect or
Sign in with Slack button opens Slack's own authorization
page, you approve access, and the credential saves itself with no keys
to copy. On self-hosted instances the dialog instead asks for connection
details (typically a bot token from a small Slack app you create) and
links to setup documentation. That is a ten-minute detour Chapter 11
walks through calmly — if you hit that wall now, switch to the email
option and come back later.Freeze warning:
and then drag temperature_2m from the input panel straight
into the text field, exactly as you did in the Filter node. The final
text will read something like:Freeze warning: it is {{ $json.current.temperature_2m }}°C right now. Bundle up.Live data, embedded in prose, via the same expression mechanism. This one trick — drag a field into any text box — is half of everyday n8n.
Watch out: If Slack answers with an error like
channel_not_foundor a complaint about not being in the channel, your credential is fine — the Slack app behind it simply has not been invited into that channel. In Slack, open the channel and invite the app (for example/invite @your-app-name), then execute the step again. This is the single most common first-Slack-message stumble.
Search the nodes panel for whichever fits your situation:
Either way, set a recipient (you), a subject like
Freeze warning, and a body containing the same dragged-in
temperature expression as above. The workflow is otherwise
identical.
Close the node and save. The full chain now reads: Schedule Trigger → HTTP Request → Filter → Slack (or email).
So far you have executed nodes one at a time. Now run the workflow
end to end: click the large Execute workflow button beneath
the canvas (labeled Test workflow in some versions — same
button, same job). n8n simulates the schedule firing right now and runs
the whole chain, animating each node as data passes through and stamping
green check marks on the ones that succeeded. Click any node afterward
to inspect exactly what went in and came out during that run. If a node
fails, it turns red and the execution stops there with an error message
— reading those well is Chapter 22's craft (The Debugging Craft), and
teaching workflows to survive failure is Chapter 23's (Error
Handling).
In summer, the run will stop at the Filter — trigger green, HTTP Request green, Filter green with zero items out, notification node untouched. Correct behavior, but unsatisfying: you have not actually proven the notification works, and "I assume the last node is fine" is not a sentence operators say.
So force the branch. Open the Filter node and temporarily sabotage
the condition in your favor: flip the operator to "larger than"
0, or raise the threshold from 0 to
50. Run Execute workflow again. This time all
four nodes light up green — and your phone buzzes or your inbox pings
with a freeze warning quoting the real current temperature. Enjoy the
moment; a machine just did your bidding end to end.
Now change the condition back to
smaller-than-or-equal 0, and save. Reverting test hacks
immediately is another day-one habit; the graveyard of automation is
full of workflows still running with "temporary" test conditions.
Tip: Real testing has better tools than sabotaging conditions — pinning a node's output so you can replay known data, mocking, and partial executions from any node. That discipline is Chapter 10 (Test, Fix, Activate, and Keep It Tidy) and Chapter 22. For a four-node workflow, the sabotage-and-revert trick is honest and fast.
Everything so far has been a manual execution — a run you started. The point of automation is production executions: runs the trigger starts on its own, whether or not you are logged in, awake, or on vacation.
In the top-right of the editor is a toggle labeled
Inactive. Click it. n8n may show a brief confirmation
explaining what activation means; accept it. The toggle turns green and
reads Active.
Here is precisely what changed: the workflow's trigger is now live on the server. Every day at 07:00 in the workflow's timezone, the n8n instance itself will start an execution — browser closed, laptop asleep. Active workflows run on the instance, not on your machine. Two corollaries: the instance must be running at 7 a.m. (a given on Cloud; a self-hoster's responsibility — Chapter 32), and an active workflow keeps running until you deactivate it, so when an experiment is over, switch the toggle off rather than just abandoning the tab.
The last step is the professional one: confirm the first production execution actually happened. Do not assume — verify. After the next scheduled 7 a.m. passes:
Executions tab at the
top of the editor (next to Editor). This lists every run of
this workflow, newest first, with status, start time, and duration. The
instance-wide list — all workflows on one screen — lives back on the
home screen, in the sidebar's executions view.If the temperature was above freezing, the execution shows the run stopping at the Filter with zero items passing — a successful execution that sent nothing. If it was at or below zero, you woke up to a warning. Either way: you have built, tested, activated, and verified a production automation. That loop — build, test, activate, verify — is the same at four nodes or four hundred.
Watch out: Executions are not kept forever. Cloud plans retain execution history for a limited window that varies by tier, and self-hosted instances prune by configurable age and count. If you check next month for today's run, it may be gone — which matters once workflows do things you might need to audit. If a workflow produces records you must keep, write them somewhere durable as part of the workflow itself. Retention and its settings are covered in Chapters 21 and 31.
In one small build you touched a remarkable cross-section of the platform: the editor and canvas, a trigger, the HTTP Request node, JSON and the item model, expressions, a flow-control decision, an app integration, a credential, activation, and the execution log. Every one of those was used at perhaps ten percent of its depth, on purpose. This table is your set of forward pointers — the depth on every node used here lives in its owning chapter:
| What you used today | What was left on the table | Owning chapter |
|---|---|---|
| Schedule Trigger | Cron expressions, multiple rules, webhook/app/chat triggers | Vol B Ch 7 |
| Canvas and node mechanics | Keyboard flow, sticky notes, rearranging, renaming discipline | Vol B Ch 8 |
| Filter (and the If family) | Branching, merging, looping, waiting, sub-workflows | Vol B Ch 9 |
| Manual test and activation | Pinned data, mocking, partial runs, tidy-up habits | Vol B Ch 10 |
| The Slack/email credential | Every auth style: API keys, OAuth, service accounts | Vol C Ch 11 |
| The Slack/Gmail app node | Reading any node's resources and operations, catalog-wide | Vol C Ch 12 |
| HTTP Request (bare GET) | Auth, headers, pagination, retries, binary responses | Vol C Ch 13 |
| One item of JSON | Multi-item flows, nesting, item linking, edge cases | Vol D Ch 16 |
| One dragged expression | The full expression language and its built-in helpers | Vol D Ch 17 |
| Filter's condition builder | The whole transformation toolkit: sort, merge, split, dedupe | Vol D Ch 18 |
| The Executions tab | Retention, replays, retries, the system of record | Vol E Ch 21 |
If a step left you curious, that column tells you exactly where to go.
Here is the promise made at the top of the chapter: one table that maps every major capability area of n8n to the part of this compendium that owns it in depth — the home every other chapter points to rather than re-explains. This is your permanent index into the set. When a question comes up six months from now ("how do I stop this workflow double-sending?", "can n8n answer questions from our own documents?", "what breaks at high volume?"), find the capability it belongs to and go straight to the owning volume.
| Capability area | What it covers | Where it lives |
|---|---|---|
| Foundations and the mental model | What n8n is and how it is sold; workflows, nodes, items, executions; the workspace tour | Vol A, Ch 1–5 |
| The editor and building craft | Choosing what to automate; canvas and node mechanics; testing, activating, and keeping workflows tidy | Vol B, Ch 6, 8, 10 |
| Triggers | Schedules, incoming webhooks, app events, manual and chat starts | Vol B, Ch 7 |
| Flow logic | Branching, looping, waiting, sub-workflows | Vol B, Ch 9 |
| Credentials and authentication | Creating, managing, and reasoning about stored logins and keys | Vol C, Ch 11 (team governance: Vol G, Ch 34) |
| Integrations | The node catalog, the HTTP Request node, webhooks in depth, community and custom nodes | Vol C, Ch 12–15 |
| Data | The item model in practice, expressions, the transformation toolkit, code, files, and data tables | Vol D, Ch 16–20 |
| Executions and reliability | The execution record, debugging, error handling, idempotency and pacing, monitoring and proving value | Vol E, Ch 21–25 |
| AI and agents | Cluster-node architecture, single AI calls, the AI Agent node, RAG, evaluations and cost control | Vol F, Ch 26–30 |
| Hosting and operations | Running Cloud like an owner; self-hosting from zero; scaling with queue mode and task runners | Vol G, Ch 31–33 |
| Access and security for teams | Users, roles, projects, sharing, external secrets, hardening | Vol G, Ch 34 |
| Platform APIs and tooling | The public API, the CLI, source control integration, embedding | Vol G, Ch 35 |
| Worked projects and reference | Two end-to-end builds, the recipes cookbook, the troubleshooting encyclopedia, the glossary | Vol H, Ch 36–40 |
A few notes on reading the map well.
The volumes have personalities. Volume A is orientation — you are finishing it now. Volume B is the builder's core loop; most of your first month lives there. Volume C is connecting to the outside world. Volume D is data — the volume people skip and then regret skipping, because nearly every confusing moment in n8n turns out to be a data-shape moment. Volume E is what separates automations that work in a demo from automations you can bet a business process on. Volume F is AI. Volume G is for whoever operates the instance — on Cloud that may still be you, wearing a different hat. Volume H is the applied shelf: projects to imitate, recipes to borrow, and the troubleshooting encyclopedia for when something is on fire.
Some topics deliberately live in two places. Credentials appear in Volume C (how a builder creates and uses them) and again in Volume G (how a team governs them). Webhooks appear as a trigger concept in Chapter 7 and get a full engineering treatment in Chapter 14. When the map lists two homes, the earlier one teaches usage and the later one teaches mastery or governance.
Today's workflow, mapped. As a worked example of
using the index: the Schedule Trigger belongs to Chapter 7; the HTTP
Request node to Chapter 13; the Filter and its family to Chapter 9; the
expression you dragged into it to Chapter 17; the nested data shape that
made current.temperature_2m an address to Chapter 16; the
Slack node to Chapter 12; the credential behind it to Chapter 11; the
executions list you checked this morning to Chapter 21. And when the
freeze alert one day fails at 7 a.m. because the weather API is briefly
down, the retry that quietly saves it will be Chapter 23's business.
Readers arrive at n8n with different jobs to do, and the map supports more than one route:
And if you arrived with one burning, specific problem: strike at it directly through the capability map or Chapter 39's symptom index, and let the cross-references pull you back to whatever foundations the answer assumes.
Whichever path you take, keep the Morning Freeze Alert running. It costs nothing, it exercises the whole machine daily, and it gives you a known-good production workflow to compare against when a future build misbehaves. Somewhere around day three of watching its executions accumulate, the small shift happens that this whole compendium is built on: you stop thinking of n8n as a tool you operate and start thinking of it as a colleague that works while you sleep — one whose work you have learned to check.