Managed vs. self-hosted: a decision framework

“Managed or self-hosted?” is one of the most consequential infrastructure decisions a team makes, and it is too often settled by preference rather than analysis. The honest answer is that it depends on a small number of factors you can actually reason about. Here is the framework we use.

Self-hosting almost always looks cheaper on the monthly bill, because the bill does not include your time. The true cost of running something yourself is patching, monitoring, backups, on-call, capacity planning, and the occasional 2 a.m. recovery. Managed services move that burden to a vendor in exchange for a higher sticker price. Before comparing prices, estimate the hours per month each option will demand from your team — that is where the difference usually lives.

Self-hosting wins when you need full control: custom configuration, strict data-residency requirements, network isolation, or the ability to keep running regardless of a vendor’s roadmap. If a system holds data you are contractually obligated to keep in a specific jurisdiction, or it must run inside a private network with no third-party access, that constraint can settle the decision on its own.

Reach for managed services for the undifferentiated heavy lifting — databases, queues, object storage, email delivery, certificate management. These are solved problems where a vendor’s reliability will almost certainly exceed what a small team can sustain, and where the operational savings are largest. Spend your scarce engineering attention on the parts of your product that are actually unique to you.

Many teams land on a hybrid: self-host the application and the components that need control, while leaning on managed services for the commodities around it. You can also start managed to move fast, then bring a workload in-house once its usage and requirements are well understood and the economics clearly favor it. The decision is not permanent — revisit it as scale, team size, and compliance needs change.

Whichever way you go, reduce lock-in: keep data exportable, prefer open formats and standard protocols, and put a thin abstraction between your application and the provider so swapping it later is a contained change rather than a rewrite. The best infrastructure decisions are the ones you can walk back without a heroic migration.