n8n is a node-based workflow automation platform in which users build workflows by connecting nodes on a visual canvas, combining ready-made integrations with custom JavaScript or Python code. Among automation platforms, it occupies the space between no-code tools such as Zapier and Make and engineering tools such as Airflow: it is visual enough for analysts, yet flexible enough for developers who need loops, branching, HTTP calls and data transformation.
Its defining characteristic is the choice of deployment: n8n can run as a managed cloud service or be self-hosted on a company’s own server or Kubernetes cluster. It is distributed under a fair-code, source-available license called the Sustainable Use License, which allows free internal use and modification but restricts offering n8n itself as a commercial hosted product. The name is a numeronym of “nodemation”, with 8 standing for the eight letters between the first and last n.
How n8n executes a workflow
An n8n workflow is a directed graph of nodes, stored as JSON, that starts at a trigger node and passes data from node to node along connections. Each node receives data, performs one operation and outputs data for the next node.
The central concept is the item. Data travels between nodes as a list of items, each a JSON object, and most nodes run their operation once per item. A trigger that receives 50 new rows from a spreadsheet therefore produces 50 items, and a following email node sends 50 messages without an explicit loop. Values are referenced through expressions in double curly braces, for example {{ $json.email }}, which read fields from the current item or from earlier nodes.
The table below lists the main node categories and what each is used for.
| Node category | Purpose | Examples |
|---|---|---|
| Trigger nodes | Start a workflow on an event or schedule | Webhook, Schedule Trigger, app-specific triggers |
| App nodes | Call a specific service with prebuilt operations | CRM, spreadsheet, chat and database nodes |
| Core nodes | Control flow and generic integration | IF, Switch, Merge, Loop Over Items, HTTP Request |
| Data nodes | Reshape and transform items | Edit Fields, Aggregate, Split Out, Code |
| AI nodes | Add language models, agents and memory | AI Agent, chat model, vector store nodes |
When no prebuilt node exists, the HTTP Request node can call almost any REST API, and the Code node runs custom JavaScript or Python against the items. This combination is the main reason developers choose n8n: the platform rarely becomes a dead end.
Deployment, hosting and scaling options
n8n can be deployed as a managed cloud service, a self-hosted single instance or a scaled self-hosted cluster, and the choice determines data control, operational effort and throughput.
| Option | How it runs | Best fit | Main trade-off |
|---|---|---|---|
| n8n Cloud | Managed by the vendor, billed per plan | Teams without infrastructure staff | Less control over data location and limits |
| Self-hosted, regular mode | One process with Docker or npm | Small teams and internal tools | Single point of failure, limited throughput |
| Self-hosted, queue mode | Main instance, Redis queue and workers | High volume and production workloads | Requires Redis, PostgreSQL and monitoring |
A default installation stores workflows, credentials and execution history in SQLite, but PostgreSQL is the recommended database for production. In queue mode, the main instance receives triggers and places executions on a Redis queue, from which separate worker processes pick them up, so capacity grows by adding workers. Credentials are encrypted with an instance encryption key, which must be backed up, because losing it makes stored credentials unreadable.
Comparison with other automation platforms
n8n differs from other automation platforms mainly in its hosting flexibility, code access and pricing model. Its closest neighbors are Zapier and Make for business automation, Power Automate in Microsoft environments, Node-RED for event and device flows, and Airflow for data pipelines.
| Platform | Primary model | Self-hosting | Typical strength |
|---|---|---|---|
| n8n | Visual node graph with code nodes | Yes, source-available | Developer flexibility and data control |
| Zapier | Linear trigger and action steps | No | Widest app catalog, easiest start |
| Make | Visual scenarios with modules | No | Visual data mapping and routing |
| Power Automate | Cloud and desktop flows | No, cloud service | Microsoft 365 integration and desktop RPA |
| Node-RED | Flow-based message wiring | Yes, open source | IoT, MQTT and edge devices |
| Airflow | Python-defined DAGs | Yes, open source | Scheduled batch and data pipelines |
The billing unit matters as much as features. Zapier counts tasks, roughly one per successful action step, and Make counts operations per module run, whereas n8n Cloud counts executions, one per complete workflow run regardless of how many nodes it contains. A workflow with 20 steps that runs 1,000 times a month is therefore 1,000 executions in n8n but can be close to 20,000 billable tasks on a per-step model. A self-hosted instance has no execution fee at all, only infrastructure and maintenance costs.
Building reliable workflows in n8n
Reliable n8n workflows depend on explicit error handling, testable data and modular design rather than on the editor itself. The platform provides the tools, but they must be used deliberately.
- Error workflows: a separate workflow that starts with the Error Trigger node can be assigned to production workflows to send alerts whenever an execution fails.
- Retry on fail: individual nodes can retry a failing call several times with a wait between attempts, which absorbs short API outages.
- Pinned data: sample output can be pinned to a node during development, so later steps can be tested without calling the external service repeatedly.
- Sub-workflows: the Execute Workflow node calls another workflow, which keeps large automations modular and reusable.
The table below lists frequent problems seen in production n8n instances.
| Problem | Cause | Fix |
|---|---|---|
| Node runs more often than expected | Per-item execution on a multi-item input | Aggregate items first or set the node to run once |
| Database grows quickly | Execution history saved for every run | Enable pruning and save only failed runs |
| Webhook works in tests but not live | Test URL used instead of production URL | Activate the workflow and use the production URL |
| Credentials lost after migration | Encryption key not carried over | Back up and reuse the same encryption key |
| Instance slows under load | Long executions in regular mode | Switch to queue mode with workers |
A non-technical view
n8n is a digital workbench for connecting the apps a business already uses. On a screen, you place boxes for each step, such as “when a form is submitted”, “add the person to the customer list” and “send a welcome email”, and draw lines between them. The system then repeats those steps on its own every time.
What makes it different is that a company can run it on its own computers instead of renting it, and technical staff can add their own small pieces of code when a ready-made box does not exist. It trades a little extra setup for more control and flexibility.
A concrete example
A software company with a support team of eight receives about 600 support emails a week. It runs n8n in queue mode on its own servers, because customer messages must stay inside its infrastructure.
A workflow starts whenever a new email arrives. An AI node classifies the message as billing, bug report or how-to question and extracts the customer ID. A Switch node routes each category: billing requests create a ticket for finance, bug reports create an issue in the engineering tracker with the extracted details, and how-to questions receive a drafted reply that an agent approves before sending. An error workflow posts any failed execution to the team chat.
Because the flow has 14 nodes and runs about 2,600 times a month, a per-step billing model would have counted tens of thousands of tasks, while the self-hosted instance costs only its server. Routing time per email fell from about 3 minutes to a few seconds, and agents spent their time on answers rather than sorting.