n8n

What is n8n?

n8n is a workflow automation tool that connects hundreds of apps and services. It combines a visual builder with the option to drop into JavaScript, and can be self-hosted so your automation data and credentials stay on your own infrastructure.

Best for

Automating repetitive tasks without paying per-operation fees

Why choose n8n

n8n occupies the space between a no-code automation product and writing your own scripts. It has hundreds of integrations, a visual builder that makes a workflow legible at a glance, and the option to drop into JavaScript when a node does not exist or the transformation is awkward in the UI. Crucially, you can self-host it, which means credentials for your services stay on your own infrastructure and there is no per-operation billing that turns a busy workflow into a monthly surprise. It handles genuinely useful work — syncing data between systems, watching for events and triggering notifications, scraping and transforming content on a schedule — and it does so with a workflow representation you can export, review and version. For anyone automating repetitive tasks whose data should not pass through a third-party SaaS, it is the strongest self-hosted option.

Replaces

• Zapier
• Make
• IFTTT

Key features

• 400+ integrations
• Visual workflow editor
• Custom JavaScript and Python nodes
• Self-hosted execution

What to watch out for

It is a stateful application with a database holding your workflows, credentials and execution history, which means a backup routine and a real upgrade path rather than a container you replace casually. Execution history grows, and the default settings can accumulate data and slow the instance until retention is configured deliberately. Credentials are stored in the database, so the database's security and its backups are as sensitive as the services those credentials unlock. Complex workflows built visually become difficult to reason about, and there is no substitute for understanding the data flowing through each node. Self-hosting means you own queue mode, worker scaling and failure handling once workflows matter, and some nodes expect external services that must be procured separately.

How to deploy

• Docker
• npm

Getting started

Install it with an external database and a persistent volume, and confirm that both are in your backup routine before building anything you would miss. Set the encryption key explicitly and store it safely, because it protects the stored credentials and losing it breaks every saved connection. Configure execution data retention from the start rather than discovering months later that the instance has slowed down. Build one small workflow end to end and confirm it runs on a schedule, then treat it as a template for how you structure the rest. Use version control for exported workflows, and test the failure path — what happens when the API you call is down — because silent failures are the characteristic problem with automation.

Typical setup

It runs with an external database and a persistent volume, both included in the backup routine before any workflow worth keeping is built. The encryption key is set explicitly and stored safely, because it protects the saved credentials and losing it breaks every connection. Execution data retention is configured from the start so the instance does not slow down months later. One small workflow runs end to end on a schedule before it becomes a template for the rest. Workflows are exported into version control, and failure paths are tested so a silent breakage is discovered by an alert rather than by its absence of effect.

Who should look elsewhere

Do not self-host it if you are not prepared to own a database, backups and upgrades, because it is an application rather than a script. Avoid it for workflows where a missed run has serious consequences unless you build proper alerting on failures, since silent breakage is the norm in automation. And if your workflows are simple enough that a cron job and a script would do, the visual builder is overhead rather than an advantage.

Project health

• GitHub stars: 206,389
• Last code push: 2026-10-01
• Open issues: 1,113
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.