n8n, process automation with self hosting and AI agents

n8n, process automation with self hosting and AI agents

n8n connects services into visual workflows: one node fetches data, the next transforms it, another sends it onward. Two things set it apart. You can run it on your own server with no licence fees, and cloud billing counts runs of the whole workflow rather than individual steps.

Who the tool is for

n8n sits between click together automation and writing your own backend. You build a workflow without code, yet at any point you can drop in a node with JavaScript or Python once clicking stops being enough.

That boundary decides the fit. A marketing team moving leads from a form into a CRM will do just as well in a simpler tool. A technical team wanting to call its own API, process the response, and fan it out to three systems depending on a condition gains room for that logic without standing up a separate service.

The second common reason is sensitive data. An instance on your own server does not send the contents of processed documents to an external vendor, which for personal or medical data is a requirement rather than a preference.

The licence, or what free actually means

n8n is not open source in the sense of OSI approved licences. It uses the fair-code model and the Sustainable Use License, which in practice means three things.

The code is public and you may modify it. You may run an instance on your own server and use it inside your company at no cost, regardless of how many users and workflows you have. You may not sell n8n as a hosted service to external customers or build a competing product on it.

For most teams the restriction is theoretical, since it targets resale rather than internal use. It is still worth knowing before you put n8n into an offer as something sold to a client, because that requires a commercial licence. This trips up agencies that configure automations for clients and want to host them in house.

Cloud or your own server

Since April 2026 the active workflow limit is gone from every plan, so billing rests purely on run count. Previously you had to watch how many automations were switched on at once, which forced artificial merging of processes into a single workflow.

With every figure, mind the payment term, because the price list shows the annual rate by default and the same allowance costs roughly a fifth more on monthly billing. The Pro and Business plans also come in higher run tiers within the same family, Pro at fifty thousand runs for instance, so a step up need not mean changing plan family at all.

The second thing that rarely reaches comparisons is what happens once the allowance runs out. Workflows do not stop: they keep running, and the excess lands on an invoice unless you move to a higher tier. On the Business plan that excess is priced in buckets of three hundred thousand runs, and the invoice arrives with a delay measured in weeks, so you see the bill for an overrun well after it happened. The concurrency limit works separately: runs above the limit are not dropped, they wait in a queue and execute in the order they arrived.

The self hosted bill is only apparently lower. On top of the machine, add upgrades, backups of the execution history database, monitoring, and the time of whoever responds when the instance stops receiving webhooks. At two processes the cloud is cheaper, at twenty the ratio flips.

Billing per run, not per step

This is the most commonly missed difference when comparing tools. Zapier charges for every executed step, so a workflow with ten nodes consumes ten units. In n8n the entire run counts as one execution regardless of node count.

The consequence is practical: in n8n it pays to build workflows in detail. Splitting logic into fifteen legible nodes instead of three overloaded ones costs nothing and makes later changes far easier. In tools billed per step, the same decision multiplies the bill five times over.

It pays to work out the break even point before picking a plan. A process triggered every five minutes around the clock is roughly eight thousand six hundred runs a month, more than the Starter allowance for a single process. Automation reacting to events instead of polling every few minutes can cut that tenfold, so before paying for a bigger plan, check whether a schedule can become a webhook.

Watch out for loops. A node processing a list of a hundred items is still one execution, but a workflow calling itself a hundred times is a hundred executions. With large datasets, check whether the node works in batch mode or spawns a separate run per item.

Your first workflow

A local install takes one command.

docker run -it --rm -p 5678:5678 \
  -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

A typical workflow starts with a trigger. The Webhook node exposes a URL you send a request to, and the rest of the workflow processes its payload.

Take a ticket handling process: a form posts to the webhook, the workflow classifies the text with a language model, writes the result to a database, and notifies the team only when priority is high. Four nodes, one branch.

Conditions live in the If node, where you compare a field against a threshold. References to data from earlier nodes take the form of expressions.

{{ $json.priority }}
{{ $('Classification').item.json.category }}
{{ $now.minus({ days: 7 }).toISO() }}

The first form reaches the current item, the second the output of a named node, the third uses the built in date library. Node names appear inside expressions, so renaming a node after building the workflow breaks the references. Name nodes sensibly from the start.

The Code node and the limits of clicking

When a data transformation gets convoluted, writing it out beats assembling it from five nodes.

const result = []

for (const item of $input.all()) {
  const lines = item.json.order.lines ?? []
  result.push({
    json: {
      number: item.json.order.number,
      total: lines.reduce((sum, l) => sum + l.price * l.quantity, 0),
      lineCount: lines.length
    }
  })
}

return result

The Code node runs in two modes: once for the whole batch or separately for each item. The first is faster and allows aggregation, the second reads better for simple transformations.

A rule that saves trouble: code in n8n should transform data, not hold business logic worth testing. Anything that deserves unit tests belongs in your own API, called from the workflow, because the Code node offers neither versioning nor tests.

AI agents inside workflows

n8n ships nodes for language models, conversation memory, and tools, so an agent becomes part of a workflow rather than a separate application. Billing is the same as for ordinary nodes, with no extra AI tariff.

A practical arrangement looks like this: the agent node gets a model from OpenAI or Claude, a list of tools defined as other nodes, and memory kept in a database. The agent decides which tool to call, n8n executes it and returns the result.

This model suits tasks of a few steps where order depends on the data. For processes with a fixed order, plain nodes are cheaper, faster, and predictable. If the task needs branching, memory across sessions, and human approval, consider building it in LangChain and calling it from n8n as a single step.

Token cost is a separate matter. An agent inside a workflow triggered a thousand times a day will generate a provider bill far larger than the n8n subscription. Before switching such a workflow on permanently, price a single run and multiply by realistic volume.

n8n against the alternatives

The choice usually reduces to two questions. Can the data leave the company, and is there someone on the team who will upgrade the container and restore the database from a backup. A no to the second alongside a yes to the first points straight at the cloud.

Running your own instance

The default configuration stores data in SQLite, which is fine for trials and wrong for production. Under real traffic, switch the database to Postgres, for example from Supabase, and enable queue mode where separate worker processes execute jobs.

Three things deserve setting up on day one. Automatic pruning of execution history, because a table holding the full payload of every run grows faster than expected and can fill a disk in weeks. Database backups, since workflows and credentials disappear along with it. The credentials encryption key stored off the server, because without it a restored backup decrypts no connection at all.

Keep workflows in a repository as JSON files even if you edit them in the browser. Exports let you review changes, roll back bad edits, and move configuration between staging and production.

Monitoring and diagnosis

Execution history is the first place you look when somebody reports that something failed. Every run shows the input and output of each node, so finding the moment a field disappeared or changed type takes a minute.

By default n8n stores every run, successes included, which after a month produces a database larger than the workflows themselves. A sensible arrangement keeps full error history for thirty days and a trimmed success history for a few days.

EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=336
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
EXECUTIONS_DATA_SAVE_ON_ERROR=all

Failure alerts are worth moving outside n8n. An error workflow that sends its alert through another n8n workflow stops working at exactly the moment the instance has a problem. Set the whole instance alert in external monitoring polling a health endpoint every minute.

Under queue mode, watch queue depth rather than only CPU load. A growing queue at low resource usage usually means workers are waiting on a slow external API, and adding capacity will not help. The fix is a concurrency limit on that node or moving the slow call into a separate workflow.

Common mistakes

The first is no error handling. A workflow without a dedicated failure path dies quietly and the customer ticket disappears. Build an error workflow and attach it to every process touching customer data.

The second is keeping keys inside nodes instead of in credentials. A key typed into a URL field lands in the workflow export and in the execution history.

The third is one workflow for everything. A process with forty nodes and six branches is illegible and cannot be tested in pieces. Split it into several smaller ones calling each other.

The fourth is testing in production. n8n separates test and production webhook URLs, so use that split rather than disabling the workflow while you experiment.

The fifth is trusting the shape of an external API response. A node configured around whatever fields happened to arrive during setup breaks the moment the vendor adds a wrapper or renames a key. Check that fields exist with a condition instead of assuming they do.

FAQ

Is n8n free?

The Community edition run on your own server carries no licence fees and no execution limits, you pay only for the machine. The fair-code licence does forbid reselling n8n as a hosted service to clients, which requires a commercial agreement. Cloud plans start at 20 EUR per month billed annually, or 24 EUR billed monthly.

How does n8n differ from Zapier?

In three ways: billing per whole run instead of per step, the option to self host, and the Code node where you write JavaScript or Python. Zapier in turn offers more ready made integrations and an easier start for non technical users.

How much hardware does a self hosted instance need?

For a dozen or so low volume processes, a server with two cores and four gigabytes of memory suffices. Under heavier traffic, move to queue mode with separate workers and a Postgres database, since the default single process setup becomes the bottleneck.

Can workflows be versioned in git?

Yes, by exporting to JSON and keeping the files in a repository. Business plans include built in git sync, on the free edition you do it with a script against the n8n API.

Is n8n suitable for large data volumes?

For batches in the thousands of records, yes, assuming batch processing and adequate resources. At millions of records, a purpose built data pipeline such as one on Airflow fits better, because n8n optimises for how comfortably you build a process, not for throughput.

Current pricing sits on n8n.io, and the documentation at docs.n8n.io.