n8n: The Complete Guide to Self-Hosted Workflow Automation

n8n (pronounced "n-eight-n") is an open-source workflow automation platform. Like Zapier or Make, it lets you build automations that connect different software services and trigger actions based on events. Unlike those platforms, n8n runs on your own servers, is fully open-source, and allows you to write custom code within workflows.

The core concepts are: Workflows (a collection of connected nodes that define an automation), Nodes (individual steps in a workflow — triggers, operations and logic), Triggers (events that start a workflow, such as a webhook, a schedule or a new record in a database), and Executions (individual runs of a workflow).

n8n was founded in 2019 and has grown to be the most widely adopted self-hosted automation platform. It is available in two forms: self-hosted (open-source, free, run on your own infrastructure) and n8n Cloud (managed hosting with a subscription fee, similar to the pricing model of Zapier).

The choice between self-hosting n8n and using n8n Cloud depends on your priorities around cost, data control and operational capacity.

Self-hosted n8n is free to run (the source code is MIT-licensed). Your costs are infrastructure — a virtual private server adequate for most small-to-medium workloads costs $20–40/month. You own the data: nothing leaves your infrastructure. You can customise freely, including building custom nodes. The trade-off is that you are responsible for uptime, updates, backups and scaling.

n8n Cloud removes the operational burden but reintroduces per-workflow pricing (the Starter plan at $20/month covers 5 active workflows; the Pro plan at $50/month covers 15; Enterprise pricing for more). For organisations running 20+ active workflows at volume, self-hosting quickly becomes the more economical choice.

For organisations without internal engineering capability, n8n Cloud is a reasonable starting point. For organisations with a developer who can manage infrastructure, self-hosting on a provider like Hetzner, DigitalOcean or Render delivers dramatically lower total cost of ownership.

Understanding how n8n processes data makes workflows easier to design and debug.

Every n8n workflow processes items — JSON objects that flow from one node to the next. A trigger node produces a list of items (one per event, or one per row in a spreadsheet). Each subsequent node receives those items, processes them, and passes the results to the next node. By default, a node processes all incoming items; you can filter, transform or branch them using logic nodes.

The IF node branches based on conditions — similar to an if/else statement. The Switch node routes items to different branches based on field values. The Merge node combines items from multiple branches. The Loop Over Items node processes items one at a time, which is useful when downstream APIs have rate limits or when you need to build up a result set iteratively.

The Code node (available in both JavaScript and Python) allows arbitrary computation — string manipulation, data transformation, HTTP requests to APIs not covered by built-in nodes, or any logic that the visual interface cannot express. This is the primary reason power users choose n8n over tools like Zapier: when you hit the limit of what drag-and-drop can do, you write code.

Running n8n in production requires more than a single Docker container. A production-grade deployment must handle: reliable execution (workflows that fail mid-run should be retried or flagged rather than silently skipped), persistent state (workflow definitions and execution history must survive restarts), concurrency (multiple workflows running simultaneously without interfering), and monitoring.

The recommended production architecture uses a queue mode, which separates the n8n main process (handling the editor UI and API) from worker processes (executing workflows). A Redis instance manages the queue. This allows horizontal scaling of workers and prevents a single slow workflow from blocking others.

Storage must use a real database — PostgreSQL for production, not the default SQLite. SQLite is adequate for development but will exhibit data corruption under concurrent writes in production.

For hosting, a managed Kubernetes cluster (Google GKE, AWS EKS) or a container platform (Render, Railway) provides more reliable uptime than a bare VPS. At minimum, configure health checks and automatic restarts.

Monitoring should cover: workflow execution success/failure rates, queue depth (a growing queue indicates workers cannot keep up with load), and latency. n8n's built-in execution log provides per-run visibility; for aggregated metrics, export execution data to a monitoring platform.

Self-hosted n8n stores credentials for all connected services in its database. The security of those credentials depends on the security of your n8n deployment.

Use strong encryption at rest for the n8n database. n8n supports credential encryption using an N8N_ENCRYPTION_KEY environment variable — set this to a strong random value and store it securely (in a secrets manager, not in a .env file committed to source control).

Restrict access to the n8n editor UI. In production, the editor should not be publicly accessible — use a VPN or IP allowlist. Webhook endpoints can be public (they need to be reachable by external services), but should be authenticated where the triggering service supports it.

Implement least-privilege for service credentials. The API tokens and OAuth credentials stored in n8n should have the minimum permissions required for the workflows they support — not admin access.

Audit workflow execution history, particularly for workflows that handle sensitive data. n8n logs which workflows ran and when; combine this with your existing audit logging for a complete picture of data movement through your automation layer.

The most common production issues with n8n workflows are: unhandled errors that cause silent failure, workflows that break when an upstream API changes, and workflows that are too long and monolithic to debug or modify safely.

Error handling in n8n is done through Error Trigger nodes — a special trigger that fires when a workflow execution fails. Wire an Error Trigger to a notification workflow (Slack message, email, PagerDuty alert) so failures surface immediately. For individual nodes, configure the "On Error" setting to either retry automatically or continue with error data rather than halting execution.

For resilience to API changes, use n8n's built-in nodes where they exist (they are maintained by the n8n team and updated when APIs change) rather than building everything with the HTTP node from scratch. When you must use the HTTP node directly, add explicit output validation — if the API response structure changes, you want the workflow to fail loudly rather than silently produce wrong results.

For maintainability, keep workflows focused on a single process. A workflow that handles ten different scenarios in a single graph is harder to understand and maintain than ten focused workflows. Use sub-workflows (n8n's Execute Workflow node) to encapsulate reusable logic and call it from multiple parent workflows.