Self Host vs Managed Cloud: How to Decide
A grounded decision guide for owning your stack versus renting it: cost, control, lock-in, on-call burden, and when managed services become a liability.
The default advice is to never touch a server. Rent the managed platform, the managed database, the managed everything, and trade money for not thinking about it. For a lot of teams that is the right call, and I will not pretend otherwise.
But it is advice, not a law. I run an entire portfolio on infrastructure I control, on purpose, and the decision was not ideological. It came from asking a few specific questions about each piece of the stack. Here is the framework, including the cases where renting wins.
Start with what you are actually buying
Managed cloud sells you one thing above all: not having to carry the operations. Backups, security patches, the night something breaks at 2am. That is real value, and at small scale it is often worth every dollar. If you have one product and a thin team, paying someone else to hold the pager is usually the correct trade.
So the honest starting point is that managed wins by default when your time is the scarce resource and the bill is small. The question is when that stops being true, because it does stop. Owning the stack means carrying the operations yourself, and that cost is real. I am not going to wave it away.
Run the cost curve, not the current bill
The trap is comparing today's prices. Managed services are cheap when you are small and get expensive in a particular shape as you grow. Usage-based pricing that felt trivial at launch becomes a line item that scales with your success, which is exactly when you can least afford a tax on every transaction.
Owning the stack bends the cost curve the other way. The fixed cost of the hardware and the operations is paid once, and more usage rides on top of it without the meter spinning. Plot both curves out two or three years at your real growth rate. The crossover point is where the decision actually lives, not in this month's invoice.
Find the moment lock-in becomes a liability
The quiet danger of managed services is not the price. It is the exit. The deeper your product is wired into a provider's proprietary features, the harder it is to leave when the terms change, and they do change: the price goes up, a tier gets killed, a policy update breaks your deploy on a Tuesday.
At one product that is a manageable annoyance. Across a portfolio it is a single point where someone else can change the rules on all of your companies at once. That is the moment managed quietly becomes a liability you cannot exit. If a service holds something you could not rebuild and could not walk away from, you do not own your business at that layer. You rent it back from them.
Be honest about the on-call burden
Self-hosting is not free, and the bill is paid in operations. You own the backups, the security posture, the monitoring, and the incident at the worst possible hour. If that work would pull your only engineers off the product, managed is the right answer and you should take it without guilt.
The reason it works for me is amortization. The whole portfolio runs on one shared foundation, so the operations cost is paid once and spread across every company on top of it. One product carrying that load alone is a different math problem than twenty sharing it. Be honest about which situation you are in.
The decision, in one line
Rent the things you could replace by Friday. Own the things your business depends on. If a service is cheap, easily swapped, and not holding anything critical, managed is fine and probably better. If it is expensive at scale, hard to leave, and load-bearing, that is where ownership pays.
That is the whole logic behind HostSSH and how I run the rest of the stack: do the hard, boring, durable thing once, then let every venture inherit it. The convenience of renting is real. Just make sure you are not quietly renting your own business back to yourself.