Running n8n in production: a security and reliability checklist

Getting n8n running takes ten minutes. Running it so that lead capture, order syncs and invoices keep working for years takes a few deliberate decisions. This checklist is what we go through before a self-hosted n8n instance handles real business data.

It’s based on n8n’s documentation (checked 23 October 2026) and on what we hit while installing n8n 2.44.5 for testing.

1. Install the supported way

• Use the official Docker image unless you have a reason not to. In our test, installing n8n 2.44.5 through npm needed Node.js 24 or newer, and its expression engine depends on a native module (isolated-vm) that had to be compiled for that Node version before n8n would start. The Docker image ships with all of that already working.
• Pin the version (a specific image tag, not latest), so updates happen when you choose.
• Task runners: n8n runs Code nodes in task runners. If you use Python in Code nodes, follow n8n’s guidance to run the Python runner in external mode. The internal mode is intended for debugging.

2. Protect the encryption key

n8n encrypts stored credentials (API keys, passwords) with an encryption key. It generates one on first launch and stores it in the .n8n folder, or you can set it with N8N_ENCRYPTION_KEY.

• Set it explicitly with N8N_ENCRYPTION_KEY and store it in your password manager.
• Back it up separately from the database. A database backup without the key means every credential has to be re-entered.
• In queue mode, every worker needs the same key.

3. Choose the database deliberately

Self-hosted n8n uses SQLite by default and also supports PostgreSQL. n8n supports the two latest PostgreSQL major versions plus one older one (16, 17 and 18 as of July 2026).

• SQLite is fine for light use on one server. Note that pruned space isn’t automatically freed (see DB_SQLITE_VACUUM_ON_STARTUP).
• PostgreSQL is the better choice for anything business-critical: easier backups and restores. It’s also what n8n itself uses for its Enterprise Scaling cloud plans (Starter and Pro use SQLite).

4. HTTPS, domain and the webhook URL

• Put n8n behind a reverse proxy with HTTPS (Caddy, Nginx, Traefik or your cloud’s load balancer) on its own subdomain, for example n8n.yourdomain.com.
• Set N8N_WEBHOOK_URL to the public URL. Otherwise n8n builds webhook URLs from its internal host and port, and external services get the wrong address. N8N_WEBHOOK_URL replaced the older WEBHOOK_URL from n8n 2.35.0.
• Set N8N_PROXY_HOPS=1, and have the proxy pass X-Forwarded-For, X-Forwarded-Host and X-Forwarded-Proto.
• Don’t expose the editor to the internet without authentication. n8n’s user management covers this, and you can restrict access further by IP or VPN if you want.

5. Access and accounts

• Individual accounts for each person. No shared admin login.
• Two-factor authentication for everyone with access. n8n supports it.
• Credentials owned by the company: connect services with accounts on company email addresses, not personal ones. See who owns your accounts?
• Give people the narrowest access they need. Not everyone needs to edit production workflows.

6. Execution data: keep what you need, not everything

By default n8n prunes executions older than 14 days (EXECUTIONS_DATA_MAX_AGE = 336 hours) or beyond 10,000 executions (EXECUTIONS_DATA_PRUNE_MAX_COUNT), whichever comes first.

• Always save failed executions (EXECUTIONS_DATA_SAVE_ON_ERROR=all). You need them to investigate.
• Consider not saving successful executions for high-volume workflows (EXECUTIONS_DATA_SAVE_ON_SUCCESS=none), or saving them only for workflows where you need an audit trail.
• Remember execution data can contain personal data from forms and CRMs. Keep only as long as you need it.

7. Backups and restores

• Back up the database daily (and the .n8n folder if you use SQLite or store files locally).
• Export workflows to version control or storage as a second line of defence. The CLI’s export:workflow command does this.
• Test a restore onto a fresh server at least once. An untested backup is a hope, not a backup.

8. Monitoring and alerts

• Error workflow on every production workflow, alerting a channel someone reads.
• Heartbeat checks for critical flows.
• Server monitoring: disk space (execution data grows), memory and uptime of the /healthz endpoint.

Details and tested patterns: error handling in n8n.

9. Updates

• Read the release notes before updating. Major versions can change behaviour and requirements.
• Update on a schedule, for example monthly, after taking a backup.
• After updating, run each critical workflow once with test data.

10. Documentation and handover

Write down where n8n is hosted, how to log in, where backups and the encryption key live, and what each production workflow does. See how to document and hand over automations.

Self-host or use n8n Cloud?

Everything above is your job when you self-host. n8n Cloud handles hosting, updates and backups for you, at a price per execution. See self-hosting n8n: the real monthly cost to compare.

If you’d like n8n set up and maintained properly, that’s part of our tech stack service.

Frequently asked questions

Is SQLite really not enough?

For a hobby setup or light internal use on one server, it’s fine. For workflows your business depends on, PostgreSQL makes backups, restores and future scaling simpler.

What size server do we need?

It depends on volume and what the workflows do. Long-running or memory-heavy workflows (large files, big data sets, AI steps) need more. Start small, watch memory and execution times, and scale up when you see pressure.

What’s the single most common mistake?

Losing the encryption key. Rebuilding a server from a database backup, then finding every saved credential unreadable, turns an hour’s recovery into a day’s work.