n8n Review: Self-Hosted AI Workflow Automation With 400+ Integrations

We spent a week running n8n through real workflows: a webhook-driven Slack triage bot, a nightly RAG ingestion pipeline against a Supabase vector store, and a customer-data sync between Postgres and HubSpot. The short version is that n8n earns its reputation as the developer-leaning automation tool, but the trade-offs around licensing, self-hosting, and AI-node maturity matter more than the marketing pages let on.

What n8n actually is (and what fair-code means)

n8n is a workflow automation platform you build by chaining nodes on a canvas. Each node is either a trigger (webhook, cron, queue event) or an action (HTTP call, database query, AI completion, custom code). Workflows execute on a Node.js runtime that you either host yourself or pay n8n to host.

The licensing detail you cannot skip: n8n ships under the Sustainable Use License, which the project markets as "fair-code." The source is on GitHub, you can self-host for internal use, and you can modify it. What you cannot do is offer n8n as a competing hosted product or resell it as a service. For most teams this is a non-issue. For agencies considering a white-label automation-as-a-service play, it is a hard stop — read the license before you build a business on top of it.

Pricing on n8n Cloud starts at $20/month for the Starter plan (2,500 executions, 5 active workflows) and scales up. Self-hosting is free in software terms; the cost shifts to the Docker host, Postgres, Redis queue, and whoever is on call when the worker pod restarts.

Execution billing is per-workflow-run, not per-step. A run that touches forty nodes counts as one execution. That sounds generous until a polling trigger firing every minute hits 43,200 executions a month — and polling is the default pattern for sources that lack webhooks. Plan your triggers carefully or the Cloud bill will surprise you.

The node model and where AI actually fits

The canvas is the part most reviews focus on. It is fine. Drag a node, draw a line, map fields with {{ $json.body.user_id }} expressions. The real story sits behind two specific nodes.

The Code node runs JavaScript by default and Python via Pyodide. You get the previous step's data as items, return an array, and the rest of the workflow continues. This is the escape hatch that separates n8n from Zapier — when the visual nodes do not cover an edge case, you write thirty lines of JS instead of building a custom integration in a separate codebase.

The AI Agent node (and the broader LangChain-derived bundle) is where n8n leans into 2025. You can wire:

• A chat model (OpenAI, Anthropic, Mistral, Ollama, Azure)
• A memory store (in-memory, Postgres, Redis, MongoDB)
• Tools (any other n8n node, exposed as a callable)
• A vector retriever (Qdrant, Pinecone, Supabase pgvector, Weaviate)

The agent decides which tool to call based on the user prompt, the same way an OpenAI Assistants run would. The difference is the tool surface is whatever your n8n instance can talk to — Postgres, Stripe, Notion, a private HTTP endpoint, a shell script.

In our test we built a support-ticket triage agent in about ninety minutes: a webhook trigger receives the ticket, the agent classifies it against a four-label taxonomy, retrieves three similar past tickets from a pgvector store, and posts to Slack with a suggested response. The same flow in raw LangChain would have been a Python repo with its own deployment surface. Here it is one workflow file you can export as JSON and check into version control.

What is not great: the AI nodes lag the underlying SDKs. When new reasoning-model parameters shipped from OpenAI, the n8n nodes took weeks to expose them. If you need the latest model behavior on day one, drop to the HTTP Request node and call the API directly. That works fine — you just lose the typed UI.

n8n vs Zapier vs Make for developers

These three tools occupy the same conceptual space, but the cost model and ceiling are different.

The per-task model in Zapier is what gets expensive. A five-step Zap that runs a thousand times is 5,000 tasks. The equivalent n8n workflow is one thousand executions. For workflows with many steps and high volume, n8n is the cheaper unit. For workflows with few steps and a non-technical ops team, Zapier's polish often wins.

Make sits between them — cheaper than Zapier, more visual than n8n, no self-host option. If your team will never touch code and you want EU data residency without operating servers, Make is a sane pick. If anyone on your team can read JavaScript, n8n gives you more room to grow.

When self-hosting actually makes sense

Self-host is the headline n8n feature, but it is not free in operator-hours. A minimum viable production setup looks like:

1. Docker host (Fly, Hetzner, Railway, or your own k8s) — $5–20/mo
2. Managed Postgres for state — $15/mo
3. Redis for queue-mode workers — $10/mo
4. Backups, log aggregation, an upgrade cadence, and someone who notices when the workflow that pages on-call stops firing

For five-figure-execution months this beats Cloud pricing by a wide margin and gives you data residency, custom env vars, and the ability to pin a version. For workloads under a few thousand executions a month, Cloud is cheaper than your time.

Two operational notes from our run:

• Queue mode (separate worker containers) is the only way to scale past a single CPU. The default main execution mode runs everything in one process and will block on long-running nodes.
• Workflow state lives in Postgres. Back it up the way you back up any production database. The execution history table grows fast — set the EXECUTIONS_DATA_PRUNE env vars or you will be paying for storage on logs you do not read.

If you only need n8n for a few internal workflows, start on Cloud. Export workflows to JSON weekly. The day you outgrow the bill, docker compose up a self-hosted instance and import the JSON. We tested the migration end-to-end and it is a one-hour job.

n8n is the right pick if your team has at least one engineer comfortable with Docker and JavaScript, you need AI agent workflows that talk to internal systems, and you would rather pay in infrastructure than per-step. It is the wrong pick if your automation users are entirely non-technical, you cannot tolerate weeks of lag on new model SDK features, or the fair-code license conflicts with your distribution model. For the developer audience this site writes for, that profile fits well — the 400+ integrations claim holds up in practice, the AI nodes are usable today, and the export-to-JSON workflow format means you actually own what you build.

---

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.