Why self-host

Three reasons, and any one of them can decide it.

Data residency. If customer data cannot leave your network, a cloud automation tool is not an option. This settles it outright for some businesses.

Internal systems. If your workflows connect to a database or an application not exposed to the internet, self-hosting is far simpler — the tool runs inside your network and reaches them directly.

Cost at volume. Cloud automation is typically priced per task or operation. A workflow processing every order every day adds up. Self-hosted, you pay for a server and the cost does not rise with usage.

Against that: somebody has to run it. That is the whole trade-off.

What running it involves

Not a one-time setup. An ongoing job.

The server. Keeping it up, and sized appropriately.

Updates. N8N releases regularly, including security fixes.

Backups. The database holding your workflows and credentials. And testing that they restore — an untested backup is not a backup.

Monitoring. Knowing when the service stops. Not “somebody will notice”.

Debugging. When something breaks at an inconvenient time.

If nobody in your company does this today, the licence saving is not a saving. You are trading a predictable subscription for an unpredictable cost that arrives as an incident.

If you already run servers, the marginal cost is small and self-hosting makes obvious sense.

Docker

Most self-hosted N8N runs in Docker — a container holding the application and everything it needs.

Why that is the sensible default:

Consistent. The same container behaves the same way on any machine.

Clean upgrades. Pull a new image, restart. No dependency conflicts.

Easy rollback. If a new version misbehaves, run the previous image.

Portable. Moving to a different server is straightforward.

What you need alongside it:

A database. N8N stores workflows, credentials and execution history. PostgreSQL for anything beyond experimentation.

Persistent storage. So data survives a container restart.

A reverse proxy with HTTPS in front of it.

A backup routine covering the database.

Making it reachable

If your workflows receive webhooks — and most useful ones do — the instance needs to be reachable from the internet.

Which means:

A domain name pointing at it.

HTTPS, with a certificate that stays valid.

A reverse proxy handling the traffic.

And this is where care is needed. An automation platform holding credentials to your ERP, your e-commerce store and your messaging accounts is a valuable target.

Four things that matter:

Strong authentication on the N8N interface itself.

Only the webhook path exposed where possible, rather than the whole interface.

Updates applied promptly, particularly security ones.

Credentials scoped narrowly — each integration account with the minimum access it needs.

Environments

Once workflows matter, you want more than one instance.

Production. The live one your business depends on.

Staging or test. Where you build and test changes.

Why it matters: a workflow being built will fail, loop, and send test messages. You do not want that happening against live systems — real customers receiving test notifications, or test records appearing in your ERP.

Two practices:

Build in test first. Move to production when it works.

Point test workflows at test systems. Not your live ERP.

Credentials

N8N stores credentials encrypted, separately from workflows.

Four habits:

A dedicated account per integration. Not a real person’s login — when they leave, the workflow should not break.

Minimum permissions. A workflow that only reads orders should not be able to delete them.

API keys rather than passwords where the target system supports them. Revocable individually, and they survive two-factor authentication being enabled.

Documented. Which workflow uses which account, and who owns it.

Backups

Worth being specific, because this is the thing people get wrong.

What to back up: the database. It holds your workflows, credentials and execution history.

How often: at least daily if workflows change regularly.

Where: somewhere other than the server running N8N. A backup on the same machine does not survive the machine.

And test a restore. Quarterly. Restore into a separate instance, open it, check the workflows are there and the credentials work.

When cloud is the better answer

Be honest about this.

No server operations today. If nobody runs servers, the maintenance burden outweighs the licence saving.

Low volume. Per-task pricing is cheap at low volume, and you get reliability somebody else maintains.

No data residency requirement. If the data can leave, one reason to self-host disappears.

A reasonable path for most businesses: start on cloud, run real workflows for two or three months, then decide with actual numbers rather than a guess.

The short version

Self-hosting gives you data control, internal system access, and cost that does not rise with usage.

It costs you a real ongoing job — server, updates, backups, monitoring, and somebody available when it breaks.

Docker with a proper database is the sensible setup. HTTPS, strong authentication, narrowly scoped credentials, and backups you have actually restored.

And keep a separate instance for building, so half-finished workflows never touch live systems.