Self-hosting n8n: the configuration decisions that matter
Most n8n tutorials get you to a running container. These are the decisions that determine whether it is still working, and still yours, in six months.
Use Postgres, not the default file database
A fresh instance stores everything in SQLite inside the container volume. It works, and it will keep working right up until concurrent executions start locking, or the volume is lost. Point it at Postgres from day one. Migrating later is possible and unpleasant.
Separate the editor from the webhooks
This is the single most useful thing you can do. The editor is a full administrative interface over everything the instance can reach. The webhook endpoints have to be public because external services call them.
So treat them as two different exposures. Route the editor behind an IP allowlist, or an auth layer, or a VPN. Leave only the webhook path prefix reachable from the internet. If your reverse proxy supports it, restrict further to an explicit list of the webhook paths actually in use rather than the whole prefix.
Make webhook paths unguessable
A webhook path is a credential. Anyone who knows it can trigger the workflow. Use a long random component in the path, do not reuse it across environments, and add a shared secret header the workflow checks before doing anything.
Do not rely on the path being secret alone. Paths leak through logs, browser history, and screenshots.
Decide what happens when a run fails
The default is that a failed execution is recorded and nothing else happens. For anything that matters, wire an error path that pushes a notification somewhere you actually read. A workflow that has been failing for a week is worse than one that was never built, because you have been trusting it.
Prune execution data
Execution history grows quickly and is the usual cause of a database that will not stop expanding. Set a retention policy early. You almost never need executions older than a couple of weeks, and if you do, you want them exported rather than accumulating in the operational database.
Back up the database, not the container
Your workflows, credentials and history live in the database. The container is disposable. A backup strategy that snapshots volumes but not the database will restore an empty instance beautifully.
Version control is not built in
There is no meaningful diff or rollback out of the box on a self-hosted instance. Export the workflows you care about on a schedule and keep them somewhere with history. The point is not to reimport them, which has its own hazards, but to be able to see what a workflow looked like before somebody changed it.
Need help with any of this?
These notes are free and always will be. If you would rather someone just set it up, or you are stuck on something similar, get in touch at hello@opsira.io.