Every “how to self-host n8n” guide gives slightly different numbers, mostly because “it depends on your workflows” is a true but unhelpful answer. Here’s a more concrete baseline, and the specific things that push you above it.
The baseline for production
For a single production instance running a normal mix of automations, the commonly recommended floor is:
- 2–4 vCPU
- 4–8 GB RAM
- NVMe SSD storage, with automated snapshots
- PostgreSQL, not SQLite, as the database
That’s a starting point, not a ceiling. If you’re planning to run AI-agent workflows, heavier analytics, or CRM-style integrations, treat 4GB RAM and 2 vCPU as the minimum you’d want on day one rather than something to grow into later — AI nodes and larger payloads push memory use up faster than typical webhook-and-transform workflows.
Why PostgreSQL, not SQLite
n8n can technically run on SQLite, and it’s fine for testing. For anything you’d call production, PostgreSQL is the practical requirement: it handles concurrent writes properly, survives crashes without corruption risk, and is what n8n itself recommends and actively supports going forward (MySQL and MariaDB support has been deprecated as storage backends). If you’re planning past a proof-of-concept, start with Postgres — migrating a live SQLite database later is extra work you can avoid entirely by choosing correctly up front.
Docker is the sane default
Running n8n in Docker (or Docker Compose alongside Postgres) isn’t just convenience — it’s what makes the rest of the operational story tractable: clean version upgrades and downgrades, easier scaling, and a portable setup you can move to another server without reinstalling everything by hand. Almost every current self-hosting guide converges on Docker Compose for exactly this reason.
The parts that aren’t “requirements” but you’ll need anyway
- A TLS-terminating reverse proxy. n8n needs to sit behind something handling HTTPS, and webhooks specifically need an always-on, no-arbitrary-timeout endpoint — a serverless/function-style host that sleeps or imposes short request timeouts is a poor fit for this reason.
- Security hardening at the OS level — a non-default SSH port, disabled root login, and a firewall are treated as baseline, not optional, in every credible self-hosting guide.
- A backup job you’ve actually tested, not just configured. See our backup and disaster recovery guide for what that actually needs to cover.
Where this stops being a weekend project
None of the above is exotic — a single competent engineer can stand this up in an afternoon. What tends to erode over months, not days, is the maintenance: watching release notes, applying patches promptly (see this year’s critical CVEs for why that matters), verifying backups still restore, and keeping the reverse proxy and OS current. That ongoing operational load — not the initial setup — is the actual cost of self-hosting, and it’s the specific gap managed n8n hosting is built to close: the resources above, provisioned and kept healthy, while you keep control of your own n8n version and updates.