How to Self-Host n8n Without Regretting It

Running It Is Easy, Keeping It Is the Job

You can have n8n up in about twenty minutes. Docker command, point a domain at it, done. Plenty of guides stop there, and that's why we get called about instances that died six months later with no backup and a database nobody pruned.

The install isn't the interesting part. These five decisions are, and making them at the start costs nothing while retrofitting them costs a weekend.

1. Pick the Database Deliberately

n8n defaults to SQLite, which is a single file and works fine for light use. It's also the reason a lot of instances become hard to move later.

Use Postgres from the start if you expect real volume, more than one workflow running concurrently, or any chance of needing queue mode later. It's one extra container and it removes a migration you'd otherwise do under pressure.

SQLite is a reasonable choice for a personal instance running a handful of workflows. Just decide, rather than accepting the default without noticing.

2. Put It Behind HTTPS Properly

n8n needs to be reachable for webhooks, which means it's exposed to the internet, which means it needs TLS and it needs the URL settings to match.

Two settings cause most of the support questions. The webhook URL must be the public HTTPS address, or the webhook URLs n8n generates will point somewhere unreachable and you'll get "works in test, fails in production" with no obvious cause. And the protocol and host settings need to agree with what your reverse proxy is actually serving.

Caddy or Traefik in front handles the certificate automatically. Nginx works too with a bit more configuration.

3. Set Execution Data Pruning Before You Need It

This is the one that kills instances.

n8n saves the data from every execution. At a few runs a day you'd never notice. At a few thousand, the database grows steadily until the disk fills, and when the disk fills everything stops at once with no warning.

Set a retention window on day one. Keep enough history to debug something from last week, not enough to store every payload since March. If you handle personal or patient data, turn execution logging down further, because those saved payloads are copies of that data sitting in your database.

4. Decide Where Credentials Live

n8n encrypts stored credentials with a key. If you lose that key, every credential in the instance is unrecoverable and you re-authenticate everything by hand.

Set the encryption key explicitly in your environment rather than letting it be generated and forgotten, and store it wherever your other secrets live. This is the single most common way a restored backup turns out to be useless.

Also, connect services using accounts the business owns rather than someone's personal login. Same principle as why connections keep disconnecting, and it matters more here because you own the recovery.

5. Build the Alerting You No Longer Get for Free

Hosted platforms email you when something errors. Self-hosted does not, unless you build it.

Three things need watching, and none of them are automatic.

Workflow failures. n8n has an error workflow setting: nominate one workflow that runs whenever another fails, and have it post to a channel a human reads daily. Set this once and apply it to everything.

The server itself. Disk, memory, and whether the container is actually running. A cheap uptime monitor pinging the health endpoint covers most of it.

Silence. A scheduled workflow that stops firing produces no error at all, because nothing ran to fail. Something has to notice the absence, which is the pattern in detecting silent automation failures.

Of everything in this article, skipping this one is what turns a working instance into a business problem, because the failure is invisible until a customer surfaces it.

The Backup That Actually Restores

Two things: the database, and the encryption key. Workflows without credentials are inert, and credentials without the key are noise.

Test the restore once, on a throwaway server, before you need it. An untested backup is a belief rather than a backup, and this is the cheapest hour of insurance available.

What This Costs in Attention

Honestly, a few hours a month once it's settled. Applying updates, glancing at disk usage, occasionally fixing something a new n8n version changed.

That's cheap if you or someone on the team doesn't mind servers. It's expensive if nobody does, because it becomes one person's unpaid second job and a single point of failure. In that case pay for hosted and spend the attention on workflows instead. n8n self-hosted limitations covers what else you're accepting, and self-hosted n8n server requirements covers the hardware.

A Sensible First Week

Get it running with Postgres and HTTPS. Set the encryption key and pruning immediately. Build one low-stakes workflow and let it run for a few days. Add the error workflow and an uptime check. Take a backup and restore it somewhere else to prove it works.

Then start moving real work onto it. If you're migrating off something, moving off Zapier: what actually breaks covers the order to do it in.

Book a free 60-minute call and we'll tell you whether self-hosting fits your volume and your team, and set it up properly if it does.