n8n: workflow automation with 600+ integrations, self-hostable under EU law

What is n8n?

n8n is a visual workflow automation platform from Berlin, started in 2019 by Jan Oberhauser. Similar to Zapier or Make.com, but with one core difference: n8n ships as fair-code (Sustainable Use License) and can run on your own infrastructure. That makes it the default choice when client data must not flow through US SaaS platforms.

The platform has three parts: a browser-based workflow editor, a Node.js server backend, and a growing library of connectors – as of May 2026, more than 600 official nodes including Gmail, Microsoft 365, Slack, PostgreSQL, Stripe, HubSpot, SAP, ERP systems, plus webhook, HTTP, and cron triggers. Since version 1.20 (end of 2024), there is a dedicated AI node family: chat models, embeddings, vector stores, and agent patterns.

Commercially, n8n offers three paths: self-hosted (free, fair-code), n8n Cloud (Starter from EUR 20/month, Pro from EUR 50, Enterprise on request), and Embedded (own n8n instance inside a third-party product with white-label). For a Swiss fiduciary, self-hosted is the regular pick: a Docker-Compose stack on Hetzner, Postgres as database, behind Nginx with Cloudflare WAF.

In our stack, 21 production workflows run: client onboarding, invoice triage, VAT receipt collector, appointment reminders via SMS, lead routing, sentiment classification of incoming mail. Each workflow has triggers, processing steps, and at least one error handler.

Why it matters

Workflow tools are the glue between LLMs and business systems. Without them, every AI implementation stays an isolated toy: the model finds an answer, but nobody enters it into CRM, ERP, or calendar. With n8n, the answer runs through a defined chain of steps – traceable from entry to exit.

Three concrete levers in the fiduciary and SME context: First, automated triage. An incoming email is classified by the AI node (client request, invoice, spam, supplier dunning), the workflow branches into auto-reply, CRM entry, or escalation. What used to take 15 minutes of human reading is classified in 8 seconds; with careful prompt design, accuracy stays above 95%.

Second: confirmed human-in-the-loop logic. n8n lets a workflow wait for a human decision – via webhook, Slack reply, or form submit. AI is not an autopilot, but a proposal generator; an employee confirms, then the output flows into the target system. For client communication and bookkeeping, that is the right balance.

Third: audit capability. Every workflow run is logged to Postgres: input, output, duration per step, errors. Under a compliance review that is traceable – no black-box SaaS, but a local database with documented schema. n8n exports workflow definitions as JSON, so they can be versioned in Git and diffed across versions.

How it works

An n8n workflow is a directed graph of nodes. Each node has inputs (from predecessors), a function (HTTP request, database query, AI call, code eval, branch), and outputs. The graph always starts with a trigger node: cron (time-based), webhook (external HTTP POST), or app-specific (new Gmail mail, new Stripe charge, new HubSpot deal).

Key patterns: branch logic via IF or Switch node, parallel execution through multiple outgoing connections, iteration over lists with SplitInBatches, error handling via the Error-Trigger workflow (a separate workflow that fires on every error).

The AI nodes since version 1.20 bring chat-model interfaces (OpenAI, Anthropic, Mistral, local Ollama endpoints), embedding generation, vector-store wiring (Qdrant, Pinecone, Postgres pgvector), and agent patterns with tool use. A typical n8n RAG workflow: webhook -> embed the question -> Qdrant search -> prompt composition with hits -> chat completion -> answer to the webhook.

Sub-workflows are reusable building blocks: a sub-workflow "VAT receipt validation" is called by three larger workflows, every change takes effect centrally. Workflow versioning has been in since version 1.15; older workflows can be diffed and rolled back.

The self-hosted variant runs on Docker with three containers: n8n itself, Postgres (as workflow DB), Redis (as queue for worker scaling). Under high load, queue mode kicks in: multiple worker containers pull jobs from Redis so the main process does not block. Backup via pg_dump plus the workflow JSON exports in Git.

n8n self-hosted in 6 steps

1. 01Prepare the Docker-Compose stack: n8n container, Postgres as DB_TYPE, Redis for queue mode, volume for /home/node/.n8n.
2. 02Configure the reverse proxy: Nginx in front of n8n, Cloudflare WAF in front of that, HSTS and rate limit on /webhook/*.
3. 03Create the base workflows: webhook receiver, cron scheduler, error-trigger workflow with Slack/mail notification.
4. 04Use the credential store: every API key (LLM, SMTP, ERP) lives in n8n credentials, not in the workflow JSON.
5. 05Set up workflow versioning: regular export of all workflows as JSON to Git, compare-diff on changes.
6. 06Wire up monitoring: Prometheus scraper on /metrics, alert when workflow error rate exceeds 5% over the last 60 minutes.

When to use n8n

n8n is the right pick as soon as (a) multiple systems are connected, (b) client data must not flow through US SaaS, or (c) a workflow has more than one step and should not be re-coded every week.

Concrete use cases: classify incoming mail and file into CRM, register new clients in Postgres plus welcome mail plus calendar invite, parse VAT receipts from the inbox and push into the bookkeeping system, appointment reminders via SMS and WhatsApp, automatic lead qualification with an AI classifier. Also fits internal workflow chains without AI – anyone running the same 5-step process twenty times a day can model it in n8n in 30 minutes.

For complex RAG and agent patterns, n8n is a fair option when the logic should stay visually traceable. For pure code-driven RAG pipelines (e.g. with LangChain in Python), straight code is often clearer; the moment client operations and workflows wrap around the LLM logic, the balance tips towards n8n.

When not to use

For a single, well-bounded script task – a cron that fetches a file once a night and writes it to a DB – n8n is overhead. A Python script with cron or a Trigger.dev job is faster to write and easier to maintain.

Unsuited for very high event volume with real-time constraints. Anyone processing millions of events per hour builds on Kafka, Apache Flink, or a custom streaming pipeline; n8n sits comfortably in the dozens-to-thousands-of-events-per-hour range.

For pure BI pipelines without external triggers (database-to-database replication, data cleansing), dbt, Airbyte, or Dagster are the natural choice. n8n can do that too, but the specialised tools are more productive there.

Trade-offs

FAQ

Related topics

Sources

1. n8n documentation – workflows, nodes, self-hosting · 2026-05
2. n8n changelog and release notes · 2026-05
3. n8n AI nodes – LangChain integration and agents · 2026-04
4. n8n Sustainable Use License (fair-code) · 2026-01