Containers and persistence
n8n recommends Docker for most self-hosting. Persist /home/node/.n8n; even with PostgreSQL, that directory can still hold encryption keys, logs, and other instance data.
Automation Cluster · Deployment requirementsE0 · official public sources
n8n self-hosted requirements: what you need before production
Self-hosting does not end when the n8n container starts. The real decision is whether your team will continuously own persistence, databases, credential keys, webhooks, HTTPS, security, upgrades, backups, and recovery.
Decision first
Without an operations owner, free self-hosting is not the default choice
Community Edition can have a zero subscription price, but infrastructure and engineering responsibility do not disappear. Self-hosting becomes an advantage only when deployment control, data boundaries, scaling, or long-run cost matter and the team can own operations.
Production checklist
Five baseline responsibilities you cannot skip
Database and backups
SQLite is the default. Evaluate PostgreSQL for continuously running or scaling production, and back up the database, instance configuration, and encryption key separately; the container image alone is not a backup.
Credential encryption key
n8n generates a key on first launch, or you can set N8N_ENCRYPTION_KEY. Losing it affects stored credentials; the main instance and every queue-mode worker must share the same key.
Public webhooks and proxying
External triggers need a stable, reachable HTTPS URL. Behind a reverse proxy, set N8N_WEBHOOK_URL and N8N_PROXY_HOPS and forward the required headers; the local tunnel is for development and testing only.
Security and maintenance ownership
Someone must own TLS, upgrades, permissions, risky nodes, the public API, execution data, and security audits. n8n explicitly recommends self-hosting for users experienced in managing servers and applications.
Scaling is not the starting point
When queue mode becomes relevant
n8n describes queue mode as its best scalability path: the main instance receives triggers, Redis holds the queue, workers execute jobs, and the database stores results. It adds Redis, workers, shared keys, monitoring, and storage design, so do not adopt it before a single instance shows a real bottleneck.
- Use PostgreSQL rather than SQLite for distributed queue mode.
- Share one encryption key across the main instance, workers, and webhook processors.
- Queue mode cannot rely on local filesystem for binary-data persistence; plan storage separately.
- Measure concurrency, backlog, duration, and recovery before adding workers.
Self-host or Cloud
Decide by ownership, not list price alone
| Decision question | Self-hosting fits | Cloud is safer |
|---|---|---|
| Why self-host? | You need deployment, network, or data-boundary control | The only reason is that Community Edition looks free |
| Who owns it? | Named owners cover operations, security, and recovery | Nobody owns upgrades, backups, or incident response |
| How will you validate it? | Pilot real workflows, recovery, concurrency, and maintenance time | You are only comparing subscription and server list prices |
Official evidence
This page uses E0 public sources only
Checked 2026-10-26. We did not run n8n in your account, on your servers, or under your production load, so this is not a universal performance or cost benchmark.
Frequently asked questions
How much RAM and CPU does self-hosted n8n need?
n8n does not publish one universal production minimum for every workflow. Its specific Docker Compose Assistant stack lists at least 4 GB RAM and 2 vCPUs, but that is not a universal promise for every core n8n deployment. Load-test your concurrency, execution duration, binary data, and Code or AI nodes.
Is SQLite suitable for production?
SQLite is the default and can suit trials or small single-instance setups. The official Compose guide recommends PostgreSQL for production that runs continuously or serves more than a handful of users or workflows, and queue mode should not use SQLite.
Does self-hosted n8n mean zero software cost?
Community Edition can be self-hosted without a subscription, but servers, databases, backups, monitoring, upgrades, recovery, and engineering time still cost money. Some collaboration, governance, or scaling capabilities also vary by edition and plan.
When should I choose n8n Cloud instead?
If nobody clearly owns servers, security, backups, and upgrades, or self-hosting does not provide necessary deployment control, data boundaries, or cost advantages, Cloud is usually the lower-risk starting point.