Getting n8n running on a server takes about ten minutes. Getting a self-hosted n8n setup that you can trust with real business processes takes rather more, and the gap between the two is where people lose credentials, drop webhook events and discover their backups were never running.
This is the checklist we work through when we stand one up for a client, in the order the decisions actually matter.
First, be honest about why you're self-hosting
Self-hosting is the right call in three situations: your data can't legally pass through a third-party processor, your execution volume makes per-run cloud pricing painful, or you need capabilities the cloud sandbox restricts — arbitrary code, custom dependencies, or reaching systems inside your own network.
If none of those is true, n8n Cloud is very likely the better decision. Self-hosting means you now own uptime, upgrades, security and backups. Plenty of teams take that on and then wish they'd paid for the hosted version. Decide this deliberately, not by default.
Run it in Docker, not npm
You can install n8n globally with npm, and for a laptop experiment that's fine. For anything that has to stay up, use the Docker image. It pins the runtime, isolates dependencies, and makes upgrades a matter of pulling a new tag rather than fighting Node versions on the host.
Use Docker Compose from the start, even for a single container. You'll be adding a database and probably Redis, and Compose keeps that reproducible instead of living in your shell history.
Use PostgreSQL, not the default SQLite
Out of the box, n8n stores everything in a SQLite file. It works, and it will quietly become your biggest regret. SQLite locks under concurrent writes, doesn't handle a busy instance gracefully, and is awkward to back up while the process is running.
Point n8n at PostgreSQL before you build anything real. Migrating later means exporting and reimporting every workflow and credential, and it's the kind of task that gets postponed until the SQLite file corrupts. Do it on day one.
Protect the encryption key like a password
This is the single most important line in this post. n8n encrypts all stored credentials with an encryption key (N8N_ENCRYPTION_KEY). On first run it generates one automatically and writes it into the container.
If you lose that key, every saved credential is unrecoverable. Rebuild the container without persisting it and n8n comes back up with all your workflows intact and every credential un-decryptable — you re-enter all of them by hand.
So: set the key explicitly as an environment variable, store it somewhere safe that is not the server, and include it in your backup. A backup of the database without the encryption key is only half a backup.
Put it behind HTTPS and set the webhook URL
n8n's editor and webhooks should never be exposed over plain HTTP. Run a reverse proxy — Caddy, Nginx or Traefik — terminate TLS there, and let it handle certificate renewal.
Then set the environment so n8n knows its own public address: N8N_HOST, N8N_PROTOCOL=https, and crucially WEBHOOK_URL. Behind a proxy, n8n can't reliably infer the external URL, so the webhook addresses it hands to third-party services will be wrong — pointing at an internal hostname or the wrong port. The webhook registers, the external service calls back, and nothing arrives. Setting WEBHOOK_URL to your real public URL fixes it.
Turn on authentication and don't expose the editor
Enable n8n's built-in user management so the editor sits behind a real login. An open n8n editor on the public internet is a remote code execution surface — the Code node runs whatever it's given.
If the instance only needs to receive webhooks and doesn't need a public editor at all, restrict the editor to your VPN or an IP allowlist at the proxy, and expose only the webhook paths. The smaller the public surface, the less there is to worry about.
Plan for scale before you need it
A single n8n process runs workflows in the same process that serves the editor. That's fine until a few heavy or long-running executions start blocking everything else.
When you get there, n8n's queue mode separates the main process from worker processes using Redis, so executions are distributed and one slow run doesn't stall the rest. You don't need it on day one, but know it exists — the symptom is webhooks timing out under load, and the fix is architectural, not a bigger server.
Back up all three things, and test the restore
A complete backup is three parts: the PostgreSQL database (workflows, executions, credentials), the encryption key, and any persisted files or environment configuration. Miss the key and the database restore gives you locked credentials. Miss the database and you have a key to nothing.
Automate it, store it off the server, and — this is the part everyone skips — actually run a restore into a throwaway instance once. An untested backup is a hope, not a plan.
The checklist, condensed
| Step | Why it matters |
|---|---|
| Docker + Compose | Reproducible, upgradeable, isolated |
| PostgreSQL from the start | SQLite locks and corrupts under real load |
| Explicit, backed-up encryption key | Lose it and every credential is gone |
| Reverse proxy + HTTPS | Never expose the editor or webhooks over HTTP |
WEBHOOK_URL set correctly |
Otherwise callbacks silently go nowhere |
| Authentication on, editor locked down | The Code node is a code-execution surface |
| Queue mode when volume demands it | Stops slow runs blocking everything |
| Three-part backup, restore tested | The key and the database are both required |
When to let someone else run it
If the workflows are load-bearing — billing, onboarding, anything a customer notices when it breaks — the operational side is worth taking seriously, or handing off. The setup is the easy part; it's the upgrades, the monitoring and the 2am webhook failure that make self-hosting a real commitment.
We build, deploy and maintain self-hosted n8n for teams that need it done properly — including deciding honestly whether you should self-host at all. Tell us what you're automating and we'll give you a straight answer.
Related: n8n workflow automation services · Make.com automation · n8n vs Zapier