Self-hosted vs managed automation: when your own server pays off
The useful comparison is not integrations or entry price: it is the pricing model, where your customers’ data lives, and who gets up when it falls over.
The comparison between a managed automation tool and a self-hosted one usually gets settled by looking at integration lists and pricing pages. Both are real, and both are the least important part.
What actually decides this well is three questions: how you will be charged as you grow, where your customers’ data will live, and who gets up if it falls over at eleven on a Tuesday night.
The comparison everyone makes, and why it misleads
Comparing available integrations ends in a practical tie: both connect what a small company needs to connect, and whatever is missing gets solved with an HTTP call. Comparing entry price gives an answer that reverses as soon as there is volume.
The useful comparison is by structural axes, which do not change when the plans do:
| Axis | Managed | Self-hosted |
|---|---|---|
| Pricing model | Per task or execution | Per server, regardless of volume |
| Where the data lives | In the provider’s infrastructure | Wherever you put it |
| Time to start | Minutes | Hours, plus an infrastructure decision |
| When something breaks | You wait for the provider | You fix it, at whatever hour |
| Ceiling | The plan and its limits | Your machine and your patience |
The pricing model matters more than the price
No figures here: plans change and any number would age badly. What does not change is the shape of the charge, and that shape decides the choice.
A managed service charges per task executed. That has an uncomfortable property: cost grows with success. A flow running once per lead is cheap at fifty leads a month and something else at five thousand. And each intermediate step usually counts as a task, so an eight-step flow multiplies by eight.
Your own server charges for existing. It costs the same at a hundred executions as at a hundred thousand, until it runs out of resources. That inverts the arithmetic completely: the expensive part stops being volume and becomes the time of whoever maintains it.
Where the data lives
This is the axis almost no comparison covers, and the heaviest one if you work with people’s data.
In a managed service, the data passing through your flows — names, emails, messages, history — crosses the provider’s infrastructure and usually sits in their execution logs for a while. That is perfectly legitimate, and it also means that provider is one more processor: it goes into your register, it needs its agreement, and you have to check whether it processes abroad so the international transfer can be disclosed.
With your own instance that link in the chain disappears. It is not legal magic — you still need a lawful basis, you still disclose, and now the server is yours with everything that implies for security — but it is one processor fewer and one question fewer to answer.
The full framing is in what changes with Chile’s Law 21.719 and in how we handle data.
What self-hosting actually costs
The licence is free. These are not:
- Updates. They have to happen, and sometimes they break something. Postponing them indefinitely turns the server into debt.
- Backups. Of the flows and of the credentials. A server without backups is an entire operation resting on one disk.
- Monitoring. And not only of errors: of absence. A flow that stopped running raises no error, it raises silence — the same problem described in what to automate first.
- Somebody. A person who can log in, read a log and restart it. If that person leaves, the server becomes a black box nobody touches.
None of these four is hard. All of them are constant, which is why the honest calculation is not “what does the server cost” but “what does the attention it needs cost”.
How to decide
Four questions, in this order:
- Does personal data pass through the flows? If yes and it is sensitive, self-hosting moves up several places.
- How many executions a month will you have in a year? Not today: in a year. The per-task model gets paid for with growth.
- Is there someone who can maintain it? If not, managed, no argument.
- What happens if it is down for six hours? If the answer is “we lose leads”, you need redundancy or alerts wherever it runs.
And an answer almost nobody considers: both. The critical, high-volume work on your own instance; the occasional and peripheral on a managed service. There is no prize for using one tool.
FAQ
- Is self-hosting cheaper? Per execution, usually yes, and by a lot at volume. Overall, only if someone was going to maintain a server anyway. The licence is the part that is free; the attention is not.
- Can I start managed and migrate later? Yes, and it is usually the right sequence. What makes migration painful is not the tool but the accumulated logic: document what each workflow does while you build it, and the move stays a project rather than an archaeology exercise.
- Does self-hosting make it compliant? It removes one processor from the chain, which simplifies the vendor register and the transfer question. It does not give you a lawful basis, does not write your privacy policy and does not secure the server for you.
- What if nobody on the team is technical? Then managed, without hesitation. A self-hosted instance nobody can restart is a single point of failure with your operations behind it.