Self-hosting n8n on Hetzner for multiple clients

A Hetzner box starts around €4 a month. That number gets thrown around a lot in n8n communities as the answer to 'how do I run this for clients cheap' — and it's not wrong, exactly. It's just not the whole answer. The box is the easy part. What you do with it once you have more than one client on it is where the real decisions live.

The box itself

Hetzner, Hostinger ($6.49/mo), DigitalOcean and AWS are the providers agencies actually reach for to self-host n8n — commoditised, one-click, abundant. None of them are the hard part. The box you provision is rarely the bottleneck. The way you organise what runs on it is.

Shared instance vs isolated instance

Two patterns show up in practice. Put every client's workflows on one shared n8n instance, tagged by client — cheapest, fastest to stand up, one thing to patch. Or give every client their own isolated instance — separate credentials, separate failure domain, a clean handover if the client leaves.

The shared pattern holds up fine at two or three clients. It stops working the same day it stops working: one runaway workflow, one rate limit, one bad deploy, and it's not one client's problem, it's everyone's. That's the failure mode that pushes agencies toward isolation — usually after it's already happened once.

What isolation looks like when you build it yourself

Container-per-client on a shared box is the DIY answer: one Hetzner instance, n8n running in a separate container per client, a shared base stack underneath. It's a real pattern — a builder on the n8n community forum, going by SiennaBase, built exactly this after describing the alternative as 'every new client meant the same 2-3 days of manual work.' That's the tax isolation is solving for: not server cost, but the redone setup work every time you onboard.

Where it gets painful

The pain doesn't show up at client one or two. It shows up around client six or seven, in the overhead of having that many separate things to look after. One practitioner put the worry directly on r/n8n:

“After a while the more client instances the more overhead?”

r/n8n, Jul 2026

Another was already living it:

“We've got 7 client instances and i'd rather not add an 8th line to that notepad.”

r/n8n, Jul 2026

Two specific things compound the overhead. First, per-client OAuth: a thread on community.n8n.io in July was still asking, unresolved, how to handle per-client Google OAuth on self-hosted n8n cleanly — every isolated instance needs its own credential setup, and there's no standard answer yet. Second, patching: CVE-2026-59208, a cross-issuer account takeover bug disclosed in n8n's auth system, is trivial to patch once on a shared instance and a chore to patch across N isolated ones.

The honest tradeoff

Isolation is the correct architecture. It's also more instances to update, monitor, back up and log into, multiplied by every client you add. Nobody in these threads argues isolation is wrong. They're describing what it costs once you're doing it by hand at seven, ten, fifteen clients.

Where a control plane fits

This is the layer we're building at Tenvik: an agency connects the Hetzner, Hostinger or DigitalOcean account they already run, we deploy and manage n8n on it — same isolation shape, same infrastructure they already trust — and give you one place to see across every instance instead of a notepad with eight lines on it. We never host n8n ourselves; it runs on your infrastructure, under your account, as itself. Disclosure: we're building this, so weigh the recommendation accordingly. The ops burden described above is real whether or not you ever use it.