When Managed Hosting Is Actually the Right Call
Self-hosting is not always the answer. Here is when managed hosting is the right call, when it is not, and how to keep the exit cheap either way.
I own my infrastructure and I still tell people to use managed hosting sometimes. That is not a contradiction. The goal was never "self-host everything," it was "never get held hostage." Managed hosting is the right call when the convenience is large, the lock-in is small, and the exit stays cheap. It is the wrong call when a vendor gets to control something you cannot afford to lose control of. Knowing the difference is the actual skill, not blanket self-hosting purism.
I run around twenty companies, and not every one runs the same way. Here is when I reach for managed and when I refuse.
When managed hosting is the right call
When you are pre-traffic and time is the scarce resource. If you are validating an idea with no users, the fastest path to live wins. A managed platform gets you shipping in an afternoon. Spending two days on server setup to save money you are not yet spending is a bad trade. Ship on managed, keep the app portable, move later if it works.
When the service has a clean export and an open equivalent. Managed Postgres is a good example. It saves you real operational work, and if you ever want to leave, you export a standard SQL dump and stand up your own. The lock-in is small because the exit is cheap. Same with S3-compatible storage: the API is a standard, so any provider can replace any other. These are the managed services I use without hesitation.
When the operational burden is genuinely specialized. Some things are hard to run well: certain databases at scale, email deliverability, edge networks. Sometimes the right move is to let a specialist run the hard part while you keep the parts that matter portable. The test is always the same: what does it cost me to leave.
When managed hosting is the wrong call
When the bill climbs faster than your usage. Managed convenience is cheap at the bottom and steep at the top. Past a certain scale you are paying a large premium to not run a box, and that premium only grows. I mapped that curve in why your cloud bill climbs. When the numbers cross, owning the box wins by a wide margin.
When there is no export and no open equivalent. A proprietary datastore with a closed format and no clean export is a cage, no matter how good the product is. The convenience is a hook, and the day you want to leave you cannot. That is the lock-in I refuse regardless of how nice the demo looked.
When the workload is core and you need control. For the things my companies are actually built on, I want root, the runtime, and the deploy. I do not want a platform outage to become my outage or a proprietary config deciding my architecture. That is why the core of the portfolio runs on owned boxes, described in what a deploy you actually control looks like.
How to decide without dogma
Run the same test every time: what does it cost me to leave, and what does it cost me to stay. If leaving is cheap and staying saves real time, use managed and move on. If leaving is expensive or staying means losing control of something core, own it. Do not self-host out of pride and do not use managed out of laziness. Make the trade on purpose, with the exit cost in front of you. I laid out that framework in full in self host vs managed cloud, how to decide.
Keep the exit cheap either way
The trick that makes this whole approach work is keeping your app portable no matter where it runs today. Standard runtimes, open data formats, no deep proprietary hooks. When your app is portable, choosing managed is not a commitment, it is a convenience you can walk away from. When it is not portable, every managed choice is a one-way door.
I run the parts that need control on infrastructure I own through HostSSH, and I let managed services handle the specialized pieces where the exit stays cheap. That mix, not purism in either direction, is what keeps a twenty-company portfolio both fast to run and impossible to hold hostage. Managed hosting is a tool. Use it where it earns its keep, refuse it where it takes control you cannot get back, and always know the price of leaving before you pay the price of staying.