Many teams ask the question too late, once the app is already live: should everything have gone to a managed cloud, or should you take back control with self-hosting? The choice is not ideological. It depends on your real costs, the sensitivity of your data and the complexity your team is willing to carry. Here is how we settle it, project by project.
Two models, one promise
Managed cloud rents availability. You pay to stop thinking about servers, updates and backups, and you hand operations to a provider. Self-hosting, by contrast, means hosting your application on infrastructure you control, rented or owned, whose maintenance you take on. Both keep the same promise, serving a reliable application. They simply split the work and the spending differently.
The real cost, beyond the monthly bill
A managed cloud bill is easy to read at the start and climbs with usage. Outbound traffic, storage, managed databases and side services add up fast once the product takes off. Self-hosting flips the curve: a heavier upfront investment, in machines and time, then a low marginal cost. Under a stable, predictable load, it often becomes cheaper within a few months. Under an irregular load, the cloud’s elasticity is hard to beat.
Data control and independence
Some data should never leave a perimeter you master. Health records, financial data, European residency obligations: in these cases, self-hosting gives a clear answer, your data stays with you. Managed cloud offers solid contractual guarantees, but you depend on a third party to honour them. It is also a matter of independence: self-hosting means being able to switch provider, migrate or negotiate without being locked into one ecosystem.
Operational complexity, the real trade-off
This is where the decision is made. Self-hosting means accepting responsibility for backups, security patches, monitoring and night-time wake-ups. Without a team equipped for it, the advertised savings are paid back in incidents. Managed cloud absorbs that load for you, in exchange for a subscription and a share of control. The right question is not which one is best, but how much complexity your team can carry calmly.
To settle self-hosting or cloud, we compare the two options line by line, against the real project.
- Cost: managed cloud bills by usage, with no heavy commitment; self-hosting asks for an upfront investment, then costs little at a stable load.
- Data: cloud relies on contractual guarantees; self-hosting keeps everything inside a perimeter you master.
- Operations: managed cloud handles maintenance, patches and backups; self-hosting hands them to your team.
- Elasticity: cloud absorbs a spike in minutes; self-hosting means sizing ahead of time.
- Reversibility: hosting your application in-house makes leaving easier; a deeply integrated cloud creates a dependency you must anticipate.
No single line decides. It is their combination, weighted by your context, that points to the right architecture.
Self-hosting is not a step backwards, it is a choice of independence earned through discipline.
When each option takes the lead
Self-hosting wins when the load is predictable, when the data is sensitive and when a team knows how to run infrastructure over time. Managed cloud stays wiser for a young product still looking for its market, for unpredictable traffic spikes, or when tying people to operations would cost more than the subscription. Many projects end up hybrid anyway: a self-hosted core for the stable heart, cloud for the elastic parts.
How we work at Liminal
We design and run our platforms and infrastructure on both sides of this border. To take back control of servers without losing our nights, we built RackSitter, our self-hosted server management tool. The backend of the Zou. app is self-hosted too, because data control was decisive there. The right choice always depends on your context: if you are torn between self-hosting and managed cloud, let’s talk about your project.