n8n: AI Agents and Workflow Automation Guide

n8n is a workflow automation platform with a visual canvas that also builds AI agents. You can self-host it for free under a fair-code licence or pay for n8n Cloud. It connects to 1500+ integrations and lets you drop into JavaScript or Python when the nodes run out. Checked 31 October 2026.

At a glance

What it is

The README title says it: "The Platform for AI Agents and Workflow Automation." In practice you draw a workflow on a canvas. A trigger starts it (a webhook, a schedule, an incoming email), nodes do the work (call an API, run code, ask a model) and the output goes somewhere. The AI part adds agent nodes that can choose which tools to call, and the README lists human approvals and full observability among the pieces.

Its own bullet list of capabilities:

• AI-native automation. Build workflows and multi-step agents using your own data, models and tools.
• No model lock-in. Connect to OpenAI, Anthropic, Google or open-source models and switch without changing your architecture.
• Prototype to production. Logic, tool use, human approvals and observability.
• Code when you need it. Combine the canvas with JavaScript, Python and npm packages.
• Enterprise features. Self-hosting, role-based access, audit trails.
• Reuse. 1500+ integrations and 9,000+ templates.

The name is short for "nodemation", pronounced n-eight-n, per the README.

Licence: what "fair-code" means for you

This is the question that catches people. n8n is not open source in the Open Source Initiative sense. The README says it is "fair-code distributed under the Sustainable Use License and n8n Enterprise License", with three promises: source available, self-hostable and extensible.

The LICENSE file adds two details that matter for planning.

• Source files with .ee. in the file name, or .ee in the directory name, are not under the Sustainable Use License. Using them needs a valid Enterprise License.
• Other branches than master are not licensed, so build from master or a release.

GitHub itself reports the licence as "Other", not an SPDX identifier. If your company has a rule about open-source licences, ask your legal team to read the Sustainable Use License text and the docs page that explains it. The license text says you may use or modify the software only for your own internal business purposes or for non-commercial or personal use, and that you may distribute it to others only free of charge for non-commercial purposes. That is the line to check against your plans.

For many teams, self-hosting for internal automation is exactly what the licence intends. The edge cases are reselling n8n as a service or embedding it in a product, so read before you do either.

Install and first run

The README gives two routes.

# quick try, needs Docker
curl -fsSL https://get.n8n.io | sh

# manual Docker
docker volume create n8n_data
docker run -it --rm --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n

Open http://localhost:5678 and create your first workflow. The n8n_data volume matters: it holds your workflows and credentials, so without it you lose them when the container stops.

For anything beyond a trial, read the Docker hosting guide in the docs and decide on a database, a reverse proxy with HTTPS and backups before you put credentials into it. Business and Enterprise plans add queue mode, which runs multiple instances.

Running it properly

The Docker quick start is for trying it. Before real work, the Docker hosting page gives these settings. They are worth knowing because each one fixes a common surprise.

By default n8n uses SQLite to save credentials. For a team, move to PostgreSQL before you have many workflows, because moving later is a chore. The docs also point to Docker Compose files for different architectures in the n8n-hosting repository and mark the plain Docker page as outdated in favor of the Compose guide. To update a Compose deployment you run docker compose pull, then docker compose down, then docker compose up -d.

A tunnel feature exists for local development, to receive webhooks on your laptop. It is for development only and needs Docker.

For a team install, our checklist is: Compose, PostgreSQL, a persistent .n8n volume, HTTPS in front, a backup of the volume and the database, and a written upgrade routine. None of that is exotic. It is the same discipline as any small internal service.

Plans and prices

The pricing page is built so that its figures are not in the static page source, so the table below comes from a fetched reading of the page.

All plans, per the page, include unlimited users, unlimited workflows and every integration. What changes is how many executions you get:

"An execution is a single run of your entire workflow," and the number of steps or the data volume does not change the count. That is a friendlier meter than per-task pricing used by some rivals: a workflow with 30 nodes costs one execution.

AI features by plan, from the same page:

• Starter: agents, MCP and AI nodes, AI models without your own API keys, and 1,600 assistant credits.
• Pro: more evaluation features, gateway credits and up to 9,600 assistant credits.
• Self-hosted: the assistant is in preview with your own API key; LangSmith tracing is self-hosted only.

The Business plan needs a licence key that pings n8n's licence server daily, which matters if your server is air-gapped.

Building an AI agent in n8n

You build the agent as a workflow, so the design is visual. A typical shape:

1. Trigger. A chat message, a webhook, a form or a schedule.
2. Agent node. Choose a model, write instructions and attach tools.
3. Tools. Other nodes the agent may call: an HTTP request, a database query, a search, another workflow. Exposing tools through MCP is on the Starter plan feature list.
4. Memory. Keep conversation context between runs, if the use case needs it.
5. Approval. Put a human check before any action that sends, pays or deletes.
6. Output. Reply in the chat, write to a sheet, create a ticket.

The AI and LangChain guide in the docs covers the AI nodes.

Keep the same discipline as with any agent. Give it few tools, describe each tool clearly, and test with bad inputs. The safety lessons in our OpenAI Agent Builder page apply here too: keep untrusted text away from privileged instructions and put approval in front of side effects.

n8n and MCP

MCP shows up twice in n8n. The Starter plan's feature list names MCP next to agents and AI nodes, so an agent in n8n can use MCP tools. That puts it in the same world as the coding agents on this site, which share MCP servers such as GitHub MCP and Playwright MCP. The docs list both directions: an MCP Client node lets an agent call tools on an MCP server, an MCP Server Trigger node exposes a workflow as a server, and a page on the n8n MCP server explains how outside MCP clients can build and run workflows.

This is a quiet advantage. A workflow you build once can become a tool that a coding agent calls, for example "create a ticket" or "post to Slack", without giving the agent your credentials for each service. Keep the credentials in n8n and expose only the narrow action.

What an execution count means for your workflows

The pricing meter is one execution per run of the whole workflow, whatever its size. That makes the arithmetic a matter of triggers. Using the plan figures above (Starter 2,500 executions for 20 euros, Pro 10,000 for 50 euros, Business 40,000 for 667 euros), here is what common trigger patterns use in a 30-day month.

Divide the price by the cap and you get the cost per execution: 0.8 cents on Starter, 0.5 cents on Pro and about 1.7 cents on Business, which exists for its self-hosting and controls and not for price. Two habits cut the count. Poll less often, since a check every 15 minutes rarely needs to be every 5. And use a trigger that waits for an event, such as a webhook, instead of a schedule that mostly finds nothing. Self-hosted Community has no execution cap, so a team with many scheduled jobs often finds the server cheaper than the plan, once its upkeep time is counted.

Human approval for agent tools

An agent that can send, pay or delete needs a person in the loop. The docs have a page on human-in-the-loop for tools, which describes requiring approval before an AI Agent executes specific tools, and another on setting a human fallback when the AI cannot answer. Use both patterns as defaults:

• Approval on write tools. Reading a record needs no approval. Sending an email, changing a record or posting publicly does. Approve per tool, not per agent, so safe tools stay fast.
• A fallback path. When the model is unsure, route to a person with the context attached, such as a ticket or a message to a channel, instead of letting it guess.
• A visible record. Log what was approved, by whom and when. Execution history helps, but copy the decision into a sheet or a ticket if you need an audit trail.
• Short approval windows. A request nobody answers should expire and be reported, not hang a workflow indefinitely.

Moving a workflow from test to production

A workflow that works on your canvas is not ready for customers. A short routine closes the gap.

1. Test with real shapes of data. Pin sample input on the first node, then try empty fields, long text and wrong types.
2. Add an error workflow. n8n lets you set a separate workflow that runs when another fails, so a failure sends you a message instead of waiting to be noticed.
3. Handle rate limits and retries. Many app nodes can retry on failure. Set sensible limits, because a retry loop against a paid API costs money.
4. Keep credentials in n8n's credential store, never in a code node or a workflow's text. Use separate credentials for test and production.
5. Export and version. Export workflows as JSON and keep them in git, or use the source control feature your plan offers, so a bad edit can be reverted.
6. Back up the volume and the database before each upgrade, and test a restore once.
7. Watch executions. Check the failed-execution list weekly. A silent failure is worse than a loud one.
8. Set a model spend limit at each AI provider the workflow calls.

Agents in n8n and code agents, side by side

Teams often ask whether to build an agent in n8n or in code. The honest answer is that they suit different people and jobs.

A common pattern is both: an n8n workflow handles the triggers, app connections and approvals, and calls a small code service for the part that needs tests. Our Build an AI agent in n8n guide walks through the first half, and how to build an AI agent shows the second.

When n8n is the right tool

• You want a visual builder you can host yourself. This is its clearest advantage over closed builders, and it matters now that OpenAI Agent Builder is shutting down.
• You need many app integrations and a good template library.
• You want a mix of no-code and code in the same flow.
• You pay per workflow run rather than per step.

When it is not

• You want a code-first framework with tests and type checks in your repository. Look at the OpenAI Agents SDK, LangGraph or CrewAI.
• You need a strictly open-source licence. n8n is fair-code.
• You do not want to run a server. Use n8n Cloud or a hosted tool like Zapier Agents.

Privacy and data

If you self-host, your workflows and credentials stay on your server. Data still flows to whichever model providers and apps you connect, under their terms. On n8n Cloud, n8n hosts them. The pricing page mentions security features such as role-based access and audit trails on higher plans.

Limits

• Execution caps on Cloud plans, with a maximum run time of 5 minutes on Starter.
• Fair-code, not open source.
• Some AI features are plan-limited or self-hosted only.
• Pricing page inconsistencies mean you should confirm before budgeting.
• It is a workflow tool first. A long agent loop may fit better in code.

Alternatives

Our take

This is a reading of n8n's README, licence and pricing page. We did not build a workflow for this page.

n8n's draw is the combination: a canvas, code when you need it, a large integration list, and the choice to host it yourself. For anyone leaving a vendor-locked builder, it is the first place we would look. The licence is the thing to read honestly, because "source available" is not "open source", and the pricing page needs a careful second look before you commit to a plan.

A good first project is small: a workflow that watches something, asks a model to summarize it and posts the result. Add an agent node only after that works.

Checklist

• Decide self-hosted or Cloud
• Read the Sustainable Use License if you plan to resell or embed
• Run the Docker quick start and keep the data volume
• Build one small workflow before an agent
• Add human approval before any side effect
• Confirm plan limits on the live pricing page