I Self-Host My Automation. Here's Why My Clients Should Too.

Most automation advice comes from people who’ve never maintained the server it runs on. I have — for years, in production, for my own companies — so let me give you the honest version, including the parts where self-hosting is the wrong answer.

My core automation runs on a self-hosted n8n instance, deployed with Docker on my own server infrastructure, alongside the other tools my companies depend on: Postiz for social scheduling, Chatwoot for chat, Umami for analytics. This stack runs FlowRevo, BotPori and MegaHut every day. When I recommend self-hosting to a client, I am not recommending a theory. I am recommending my own daily reality.

The case against renting everything

Hosted automation platforms are genuinely good products, and for a first workflow they are the fastest way to start. The problem appears as you succeed. Pricing is usually tied to volume — tasks, executions, seats — which means the better your automation works, the more rent you pay on your own processes. Your most valuable operational knowledge — exactly how a lead becomes a customer in your business — ends up written inside somebody else’s product, in a format you cannot take with you.

Then one day the pricing changes, or a feature moves to a higher tier, or the integration you depend on is deprecated. Nothing about your business changed. Your operations still pay. A self-hosted hub removes that whole category of risk: the workflows are files and configuration you own, running on infrastructure you control, at a cost that stays roughly flat while your volume grows.

What self-hosting actually involves — honestly

Now the part the self-hosting advocates skip. A server is a responsibility. Somebody has to apply updates, renew certificates, watch disk space, and — the one everyone forgets — test that backups actually restore. Docker and a deployment tool like Dokploy make this dramatically easier than it used to be, but “easier” is not “nothing”. If nobody in your business is technical, an unmanaged server will eventually become an unmaintained server, and an unmaintained server is worse than a subscription.

This is exactly why I sell n8n hosting and support as a service instead of just telling clients to go and install it. Self-hosting works when an operator owns the boring parts. The question is never really “SaaS or self-hosted?” It is “who maintains this, and what happens when they are on holiday?”

In my own stack, the boring parts are written down: how each service is deployed, how it is updated, and how it is recovered — the same documented deployment and recovery practices I hand over to clients. And the rule from my own audit checklist applies to me first: a backup that has never been restore-tested is a hope, not a backup. That discipline is most of the difference between self-hosting that saves you money and self-hosting that eventually costs you a weekend.

When SaaS is still the right choice

Rent without guilt when the volume is tiny and likely to stay tiny — the subscription is cheaper than anyone’s attention. Rent when the tool is the product itself, like a payment gateway, where the provider’s compliance and uptime are the value. And rent while you are still testing an idea: never build infrastructure for a process you have not proven by hand first.

My verdict

For a technical founder or a business with an operator on the team: self-host the hub — the automation layer at the centre — and rent the edges. For a growing business without technical staff: get the hub hosted and maintained for you; ownership without maintenance is a liability, maintenance without ownership is the sweet spot most businesses actually need. And for everyone: design your processes as if you will migrate one day, because the businesses that can move are the ones that never have to beg.

Your automation is becoming the operating system of your company. Operating systems are worth owning.