Pillar Guide · Updated May 2026

n8n Automation: The Complete Guide

n8n is the automation platform we reach for first when a workflow is going to outgrow Zapier. It's a node-based workflow engine you can self-host on your own servers, write real JavaScript or Python in, and connect to almost anything with an API. For teams that have hit the ceiling of consumer automation tools — fragile zaps, surprise overage bills, no version control, no way to handle anything tricky — n8n is usually the answer.

This guide is what we wish every client read before kicking off a project. It covers what n8n actually is, how the engine works underneath the visual editor, where it fits in a serious automation stack, and how to run it in production without it falling over. No marketing fluff. If you're going to build operations on top of this thing, you should know what it is.

What n8n actually is

n8n is a workflow automation platform. You drag boxes onto a canvas, wire them together, and each box (called a node) does one thing — fetch data from an API, transform it, call an LLM, write to a database, send a message. A connected chain of nodes is a workflow, and a workflow is triggered by something: a webhook, a schedule, a manual click, a queue message, an email, a file landing in a folder.

That description fits Zapier and Make too. The differences that actually matter:

• Source-available and self-hostable. The Community Edition runs on your own infrastructure — Docker, Kubernetes, a bare VM. You own the database, the credentials, the data in flight, and the runtime. You're not renting compute from someone else.
• Real code, not pseudo-code. Every node accepts JavaScript expressions inline. A dedicated Code node runs full JavaScript or Python with access to the items flowing through the workflow. There is no artificial ceiling on what you can do once you need to write logic.
• Per-execution pricing, not per-task. A workflow that processes 200 records in one run counts as one execution on n8n, not 200 tasks. This single difference often turns a $2,000/month Zapier bill into a $50/month n8n bill.
• Workflow as data. Every workflow is JSON. You can put it in Git, diff it, code-review it, and promote it between environments. It's the closest thing to "infrastructure-as-code" in the no-code automation world.

n8n the company was founded in Berlin in 2019 by Jan Oberhauser. The platform is source-available under the Sustainable Use License (a switch from Apache 2.0 with the Commons Clause that took effect in late 2022). Practically: you can run it for any internal business purpose without paying. You can't take the code and stand up a competing managed-n8n SaaS. For the use case 99% of operations teams are in, that distinction never comes up.

How the workflow engine works

Under the visual canvas, n8n is a Node.js application that executes a directed graph of nodes. When a workflow starts, the trigger node emits one or more items. An item is just a JSON object — an HTTP webhook body, a row from a database query, a row from a CSV. Each item flows to the next node, which executes once per item by default, and the output items flow to the next node, and so on.

That "once per item" detail is the single biggest source of confusion for people coming from Zapier. In Zapier, a Zap typically processes a single record at a time. In n8n, a node receives an array of items and can return an array of items — possibly more, possibly fewer than it received. This is what lets a single execution touch hundreds or thousands of records efficiently.

A few things follow from that:

• Branching is real branching. An IF node sends some items down one path and others down another. A Switch node fans out to many. The two paths re-merge at a Merge node if you need to recombine them.
• Loops are usually unnecessary. If you're tempted to add a loop, you're probably fighting the data model. The right move is usually to let items flow through the chain in parallel.
• Error handling is per-node, with optional global error workflows. Every node has a "Continue on Fail" toggle that lets the workflow keep running with the error captured as data instead of halting. Separately, you can attach an error workflow to any workflow — when something fails, that error workflow runs with full context (workflow ID, failed node, error message), so you can alert Slack, log to Sentry, or fire a recovery process.

Executions are stored in the database with their full input/output history (you can turn this off per-workflow for privacy or storage reasons). This is where n8n earns its keep operationally: when something breaks, you go to Executions, find the run, see exactly what data hit which node, and re-run from any failed step.

Nodes, expressions, and the data model

n8n ships with several hundred pre-built nodes covering the standard SaaS catalog — HubSpot, Salesforce, Slack, Notion, Airtable, Google Sheets, Stripe, Shopify, GitHub, Postgres, MySQL, MongoDB, S3, and so on — plus generic primitives like HTTP Request (call any API), Webhook (receive any HTTP), Schedule Trigger, Code, Set, Merge, IF, Switch, and Function-style helpers like Split In Batches and Item Lists.

There are three layers of "programming" inside n8n, in increasing order of power:

1. Expression mode. Any field on any node can be flipped from a literal value to an expression — a snippet of JavaScript wrapped in {{ ... }}. References to data look like {{ $json.email }} for the current item, or {{ $node["HubSpot"].json.id }} for the output of a specific upstream node. Plenty of useful work fits in expressions alone.
2. Code node. When you need real logic — looping over items, reshaping data, calling internal libraries — drop in a Code node. JavaScript is the default; Python is available too. You get the full array of items in and return the array out. This is where most of our advanced workflows live their actual logic.
3. Custom nodes. When a piece of logic recurs across dozens of workflows, you write a custom node. It's a TypeScript package, deployed to your n8n instance, and from then on it's just another box on the canvas. We do this for clients who have internal APIs they call from twenty different workflows — package it once, get autocomplete and validation everywhere.

The expression language is small and well-defined. Useful built-ins like $now, $today, $workflow, $execution, plus the Luxon DateTime library and a handful of string/array helpers, cover most of the work. When you need more, you go to the Code node.

Credentials and security

n8n keeps credentials separate from workflows. A credential is a named, encrypted record — your HubSpot API key, your Slack OAuth tokens, your AWS access keys — that nodes reference by name. The actual secret values live in the database, encrypted at rest with an instance-level encryption key.

A few things to know:

• Credentials can be shared with specific users or roles. You don't have to grant everyone access to every API key.
• OAuth is built-in for most major providers. n8n handles the redirect flow and token refresh transparently.
• External secrets are supported on Enterprise. If you'd rather keep credentials in AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault, you can — n8n pulls them at execution time.
• The encryption key is the single most important thing to back up. Lose it and the encrypted credentials in your database are unrecoverable. We see this go wrong roughly every time someone migrates an n8n instance without thinking about it.

On the network side: n8n is just an HTTP server. You put it behind your reverse proxy of choice, terminate TLS there, and treat it like any other internal application. Webhook URLs are public by default — if you're exposing them to third parties, you authenticate the webhook itself (HMAC signatures, basic auth, header tokens) using nodes inside the workflow.

Self-hosting vs Cloud

There are two ways to run n8n.

n8n Cloud is the managed SaaS offering at n8n.io. Multiple tiers — pricing is per-workflow-execution rather than per-task, with starter, pro, and enterprise tiers that scale executions, included active workflows, and feature access (SSO, audit logs, log streaming, etc.). Check n8n.io/pricing for current numbers; they update. The Cloud product is the right answer for teams that want zero infrastructure overhead and don't have a strong data-residency or compliance requirement to keep things on-prem.

Self-hosted means you run the Docker image yourself. The Community Edition has no software fee. You provision a VM or a Kubernetes cluster, give it a Postgres database, optionally a Redis for queue mode, and you're live. Self-hosting is the right answer when:

• You're going to run a lot of executions and Cloud's per-execution price gets uncomfortable
• You have data that can't leave your infrastructure (regulated industries, customer PII, internal systems behind a firewall)
• You want to write custom nodes against internal libraries that aren't going to be packaged for Cloud
• You already have a competent ops team and the marginal cost of running one more service is near zero

The honest tradeoff: Cloud is one less thing to maintain. Self-hosted gives you more power and (usually) lower cost at scale, in exchange for owning the operational reality of a Node.js application that needs upgrades, backups, monitoring, and occasional debugging at 2am. We deploy both for clients — the choice depends on what their ops team already operates and how much execution volume they're going to push through.

Running n8n in production

n8n out of the box ("single-process mode") runs the editor UI, the webhook server, and the workflow executor in one Node.js process backed by SQLite. That's fine for prototyping. It is not what you run in production.

A production deployment looks like this:

• Postgres as the database. SQLite locks badly under load and dies the first time you try to scale horizontally. Postgres is the recommended production DB, full stop.
• Queue mode with Redis. In queue mode, the main process accepts webhook calls and writes executions to a Redis queue. A pool of separate worker processes pulls executions off the queue and runs them. This is how you scale beyond what one CPU core can handle, and how you keep a slow execution from blocking the rest of the system.
• A dedicated webhook process. For high-volume webhook endpoints, you run a separate process whose only job is to accept inbound HTTP and enqueue work. The main editor process never has to handle production traffic.
• Externalized encryption key. Set N8N_ENCRYPTION_KEY as an environment variable and back it up somewhere safe. Never let it live only on the instance filesystem.
• Monitoring. Watch the Redis queue depth (sustained backlog = under-provisioned workers), worker CPU, Postgres connections, and execution failure rate. n8n exposes Prometheus metrics on Enterprise; on Community we typically scrape via a sidecar.
• An error workflow that pages someone. Every production workflow points at the same error workflow, and that error workflow routes failures to whoever owns the system — Slack channel, PagerDuty, an internal ticketing inbox. Silent failures are the worst kind.

Backups: dump Postgres on a schedule (everything except executions data can come back from the workflow JSON in Git; the executions table is the heavy one). Snapshot the disk if you want to be paranoid. Test the restore at least once before you need it.

AI, agents, and LangChain inside n8n

n8n has shipped a substantial AI layer over the past two years. It's not a wrapper — it's a real integration of LangChain primitives as native nodes. You build agents on the canvas the same way you build any other workflow.

The pieces:

• Chat model nodes. OpenAI, Anthropic, Google Gemini, Mistral, Groq, Ollama (local), plus a generic "OpenAI-compatible" node for self-hosted endpoints like vLLM or LM Studio. You can swap models without rewiring the workflow.
• Tools. Any n8n workflow can be exposed as a tool the model can call. Want the agent to query your CRM? Build a "Get HubSpot contact" workflow, mark it as a tool, and the agent can call it during reasoning. This is the killer feature — your existing automation library becomes the agent's toolbox.
• Memory. Short-term memory (in the workflow execution), Postgres-backed memory, Redis memory, or a managed memory store. You wire the memory node into the agent and it handles conversation context automatically.
• Vector stores. Pinecone, Qdrant, Supabase, PGVector, Weaviate, plus an in-memory store for testing. Combined with the embedding nodes, you have RAG (retrieval-augmented generation) without leaving the canvas.
• Structured output. Force the model to return JSON matching a schema you define. The platform handles retry-on-malformed-output automatically.

The honest take: n8n's AI layer is the fastest way we've found to ship a real agent that does real work for a real business. You don't have to write a Python service, host a vector DB, build a tool-routing layer, or stand up an observability stack. You build it on the canvas, test it on the canvas, and when something misbehaves you open the execution history and see exactly what the model returned at every step. We've replaced multi-thousand-line LangChain apps with n8n agents that do more, more reliably, with one engineer maintaining them instead of three.

Where n8n fits — and where it doesn't

Good fits:

• Cross-tool data flow. Sync HubSpot to Salesforce to Postgres to a dashboard. Push Stripe webhooks into your invoicing system and your data warehouse. The bread-and-butter work that lives in twenty places across most companies.
• AI agents and assistants. Internal Slack bots that answer questions from your SOPs, customer-support triagers that read tickets and draft replies, sales-research agents that enrich leads before they hit a rep.
• Internal "glue" services. The thing that used to be a 200-line script on a cron — fetch from API A, transform, push to API B, log to Slack on failure. n8n is a better home than a half-maintained Python repo.
• Customer-facing webhooks at moderate scale. A webhook endpoint backed by an n8n queue can comfortably handle tens of thousands of requests per day on a small VM. Past that, you scale workers.
• Data pipelines that don't justify a real ETL stack. Pulling a few APIs into a warehouse, transforming, and refreshing dashboards — n8n covers the use case without you provisioning Airflow.

Bad fits:

• High-throughput, low-latency request handling. If you need to process millions of events per hour with sub-100ms latency, n8n isn't the right tool. Use a real message broker and a service written for the job.
• Stateful, long-running orchestration with complex retry semantics. Temporal or AWS Step Functions are designed for this. n8n can do a lot, but workflow orchestration with strict exactly-once guarantees and durable state across days is not its sweet spot.
• User-facing application logic. n8n is for back-of-house plumbing, not for handling synchronous requests from a customer-facing product where latency directly affects UX.

Common mistakes we see

• Running production on SQLite. It works until it doesn't. Move to Postgres before you put it in front of any real workload.
• No error workflow. A workflow fires every hour, fails silently for three weeks, and nobody notices until a customer asks why their data is stale. Every production workflow needs to route failures somewhere a human will see.
• Hardcoded credentials. People paste API keys into HTTP Request headers as literal values and then commit the workflow JSON to a public repo. Always use the credential system.
• Treating it like a one-shot script repository. Every workflow accumulates state, dependencies, and assumptions. Without naming conventions, ownership, and documentation, you end up with a 400-workflow instance and nobody knows what most of them do.
• Skipping environments. Edit in production, break production. Use n8n's environments feature (or run a separate staging instance) and promote workflow JSON between them through Git.
• Letting executions data grow unbounded. By default, n8n keeps every execution forever. On a busy instance this kills Postgres performance after a few months. Set a retention policy.

n8n vs Zapier, Make, and the rest

The short version, with no axe-grinding:

Where Zapier still wins: speed to first running automation, breadth of consumer-app integrations (Notion, Loom, Calendly, every fitness app on earth), and total beginner-friendliness. If your team needs to wire a Google Form into a Slack channel by lunch, use Zapier.

Where Make still wins: the canvas. Make's visual representation of scenarios with bundles and iterators is genuinely beautiful and can be easier to reason about than n8n's flow for certain branching shapes. Mid-complexity workflows by non-developers often land in Make.

Where n8n wins: everything once you cross the threshold of "this is real business infrastructure." Lower cost at scale, full ownership, real code, real Git, real observability, real AI primitives. For the workflows that run your operations, this is where we land. We've written a longer head-to-head in n8n vs Zapier: the complete comparison and the three-way version in n8n vs Make vs Zapier.

Getting started without painting yourself into a corner

If you're trying n8n for the first time, the lowest-regret path looks like this:

1. Start on Cloud or with Docker locally. Don't try to set up Postgres, Redis, queue mode, reverse proxy, and SSL on day one. Get a feel for the platform first.
2. Pick a real workflow with real volume. Not a hello-world "send myself a Slack message when a webhook fires." Pick something that runs every day and currently costs your team time.
3. Build it once, naively. Don't over-engineer. Get it working end-to-end.
4. Add error handling. Wire an error workflow. Add Continue on Fail where appropriate. Make failures loud.
5. Decide on hosting before you scale. Once it's working, decide whether you're staying on Cloud or moving to self-hosted. Migrating later is possible but annoying.
6. Put workflow JSON in Git. Even if you don't use n8n's environments feature, export workflows as JSON and check them in. It's your only real audit trail.
7. Define naming and ownership conventions. Every workflow has a clear name, a tag for the team that owns it, and at minimum a Notion doc describing what it does. Without this, instances become unmanageable inside a year.

If you'd rather not climb that curve yourself, this is most of what we do as an AI automation agency. Our typical engagement starts with the Efficiency Scorecard, which surfaces where automation will pay back first. We then install the production infrastructure, build the first system, and hand it off with documentation. By the time we're done your team owns the platform; we just maintain it under a retainer if you want us to.

Related reading

• Sales automation — what n8n looks like wired through a CRM pipeline
• Marketing workflow automation — campaign and lead-flow plumbing
• Operations automation — the back-office side of the same problem
• What is n8n? — the short version
• n8n pricing in 2025
• How to migrate from Zapier or Make to n8n
• Workflow cost calculator — compare Zapier vs n8n cost at your volume
• Automation ROI calculator — quantify the payback before you commit

FAQ