Self-Host n8n: Requirements, Options & Setup

What n8n 2.0 changed for self-hosters

If your mental model of self-hosted n8n predates version 2.0, four things are different enough to break a setup built from an older guide.

The Docker tags were renamed. What used to be latest is now stable, and next is now beta. The old tags still resolve today but n8n's changelog says they will be removed, and the documentation now recommends pinning a specific version rather than following a moving tag at all. Every tutorial written before 2.0 tells you to use latest.

MySQL and MariaDB are gone as storage backends. Self-hosted n8n now supports SQLite, which remains the default, and PostgreSQL. If you are running n8n on MySQL, migrating is a prerequisite for upgrading, not an optional tidy-up.

Task runners are on by default and all Code node execution happens on them. The main image no longer bundles the external-mode runner, so a production setup runs a separate runners container at a version matching n8n itself. Internal mode still exists and is described in n8n's own documentation as insecure by design, with removal planned. Python in the Code node now requires external runners, since the previous in-browser Python engine was removed.

WEBHOOK_URL is deprecated in favour of N8N_WEBHOOK_URL. It still works as an alias and logs a warning at startup, which is the kind of thing that sits in your logs unnoticed for a year.

How much server do you need?

Plain answer: n8n does not publish hardware requirements, and anyone quoting you "n8n needs 2 vCPU and 4GB" is repeating a host's recommendation rather than a vendor specification. The only figures n8n publishes appear on an integration page, labelled illustrative, and suggest memory in the hundreds of megabytes to a couple of gigabytes, with memory mattering more than CPU.

What that means practically: a small instance running a handful of scheduled workflows is undemanding and will sit happily on an entry-level VPS. What drives real resource use is not workflow count but payload size, because n8n holds workflow data in memory as it passes between nodes. A workflow processing large files or thousand-row API responses will want more memory than a dozen workflows passing small JSON objects. Size for your heaviest workflow, not your workflow count.

When you need queue mode

By default n8n runs everything in one process. Queue mode splits that: a main instance handles triggers and webhooks, and separate worker processes run the executions. n8n describes it as the best option for scalability.

It is a meaningful step up in complexity. Queue mode requires Redis, requires PostgreSQL because a distributed setup over SQLite is unsupported, requires the same encryption key across every process, and requires binary data to move to S3-compatible storage rather than the filesystem. n8n does not publish a threshold at which you need it, so the practical signal is behavioural: executions queueing up behind each other, or long-running workflows blocking short ones.

Start single-process. Most instances never outgrow it, and arriving at queue mode because you measured a problem is a much better position than arriving there because a tutorial said to.

The maintenance you are signing up for

Self-hosting trades money for responsibility, and the responsibility is real but modest: update monthly so version jumps stay small, read release notes before major versions, keep backups of your data volume and database, and keep the host patched. n8n's own guidance is to update at least monthly and to test in a separate environment first.

Our own advice, which n8n's current update documentation does not state: take a backup before every upgrade. Database schema changes are not generally designed to be reversed, so a backup is the only reliable way back if an upgrade goes wrong.