The cloud vs self-hosted debate has been running for over a decade, and the arguments on both sides have calcified into tribal positions. Cloud advocates point to operational simplicity and infinite scale-on-demand. Self-hosting advocates point to cost control, data sovereignty, and independence from vendor pricing decisions.
Both sides are right — in the contexts where their position applies.
The businesses that make this decision well are not the ones that picked the philosophically correct option. They are the ones that asked the right questions first: what are we actually optimising for, what is our operational capacity, and what are the real constraints in our specific situation?
This article is a framework for making that decision clearly — including the cases where the answer is genuinely neither.
The Decision Is Not Binary
Before the framework: the cloud vs self-hosted framing is a simplification that causes problems.
"Cloud" covers a spectrum from raw virtual machines (where you manage almost everything) to fully managed services (where the provider manages the infrastructure, the runtime, and often the application layer). "Self-hosted" covers everything from a rack in your own data centre to a VM on a third-party host where you control the full stack.
The more useful question is: for each component of your system, how much operational responsibility are you taking on, and is that the right trade-off?
A business can run fully managed databases on AWS while self-hosting certain applications for compliance reasons, while using a SaaS tool for monitoring, while running their development environment on local machines. These decisions do not need to be uniform.
💡Key Insight
The goal is not a consistent answer across your entire infrastructure. It is the right answer for each component, given your team's operational capacity, your cost constraints, your compliance requirements, and the criticality of each system.
The Case for Managed Cloud
For most businesses at most stages, managed cloud services are the right default. The reasons are concrete.
Operational Complexity Is Transferred
Running infrastructure is a specialised skill. Patching operating systems, managing storage durability, configuring network security, handling hardware failure, scaling capacity — each of these is an expertise area in itself.
Managed services transfer this operational complexity to teams who do nothing else. AWS RDS manages database backups, failover, storage scaling, and engine patching. You do not need a database reliability engineer on call at 2 AM when a node fails. That capability is bundled into the service cost.
For a team without dedicated operations engineers, this is not a premium — it is the difference between a system that is maintained correctly and one that is maintained inconsistently by developers who would rather be building product.
Speed to Production
The fastest path from idea to running production system is almost always managed cloud. Spin up a managed database in minutes. Deploy an application via a container platform in minutes. Configure a CDN, a queue, an email service — all within hours, without provisioning a single server.
For early-stage products, this speed is a direct competitive advantage. Every week spent on infrastructure setup is a week not spent on product development and customer learning.
Built-In Resilience
Major cloud providers invest at a scale that no individual business can replicate. The redundancy, geographic distribution, and uptime guarantees of AWS, GCP, or Azure are genuinely hard to match without substantial dedicated infrastructure investment.
Multi-AZ database deployments, automatic failover, managed backups with point-in-time recovery — these are not trivial to build yourself. Managed services package them as defaults.
→Practical Tip
When evaluating whether to self-host a component, ask: what would it take to achieve the same level of operational reliability as the managed version? Include the cost of the engineering time to build it, the ongoing time to maintain it, and the risk premium for the incidents you will have while you are learning.
Predictable Cost Scaling
With managed services, your costs scale roughly with your usage. You pay for what you use, and the cost per unit typically decreases at higher volumes through committed use discounts.
The infrastructure cost for a product with 100 users is genuinely small. You are not paying for capacity you have not yet needed.
The Case for Self-Hosting
Self-hosting is not a legacy position or a cost-cutting shortcut. For specific situations, it is the clearly correct choice.
Cost at Scale
This is the most commonly cited reason, and it is legitimate — at the right scale.
Managed services price in significant margins over the underlying infrastructure cost. At low to moderate usage, this margin is the fair price of operational convenience. At high usage, the cost delta becomes substantial.
A business running Postgres at scale on RDS may find the same database hardware costs 40–60% less on a dedicated host managed by an in-house database team. The savings are real. The question is whether the business has the operational maturity to capture them without introducing unacceptable reliability risk.
⚠️Watch Out
The cost savings from self-hosting only materialise if your team can operate the infrastructure reliably. A self-hosted database managed by developers who are also trying to ship product will cost more in incidents, degraded reliability, and engineering distraction than the managed alternative — at almost any scale.
Data Sovereignty and Compliance
Some data cannot legally or contractually leave certain jurisdictions, or cannot be stored on infrastructure owned by specific third parties. Healthcare data under HIPAA, financial transaction data under certain regulatory frameworks, and personal data under GDPR all carry compliance requirements that can constrain where and how data is stored.
Managed cloud providers have compliance certifications and data residency options that satisfy most of these requirements. But when they do not — when the specific regulatory requirement, contractual obligation, or security posture demands it — self-hosting or private cloud becomes the compliant path.
This is a genuine reason to self-host. It is not always a choice; sometimes it is a requirement.
Customisation and Control
Managed services are opinionated. They expose the knobs that most users need and abstract away the rest. For most use cases, this is fine. For some, the abstracted layer is exactly what you need to change.
Custom storage engines, unusual network topologies, specific hardware requirements (GPUs for inference, high-memory instances for specific workloads), non-standard security configurations — these are situations where the managed service layer is in the way rather than helpful.
If you have engineers with the specific expertise to manage these configurations reliably, and if the control you gain is genuinely necessary for your product, self-hosting is the right call.
Vendor Independence
Cloud concentration risk is real. Businesses deeply coupled to a single cloud provider's proprietary services — their managed queues, their serverless platforms, their proprietary databases — face lock-in that makes changing providers expensive and difficult.
This is not always a problem. But for businesses where cost or compliance requirements might require moving providers in the future, deliberately choosing more portable, self-hostable components reduces that future cost.
💡Key Insight
Vendor independence is rarely worth significant present cost to hedge a future risk you may never face. But when portability is a concrete near-term requirement, building toward it from the start is far cheaper than rebuilding for it later.
The Framework: Deciding Component by Component
Rather than a single cloud vs self-hosted policy, apply this decision framework to each significant infrastructure component.
Step 1: Assess your operational capacity
Does your team include engineers with specific operational expertise for this component? For databases: someone who understands replication, backups, and performance tuning at a deep level. For Kubernetes: someone who can debug node failures, manage upgrades, and handle cluster instability. For networking: someone who can configure and troubleshoot at the network layer.
If the answer is no, the managed service option is strongly favoured. Operational expertise is not acquired quickly under pressure — incidents happen before you have had time to develop it.
Step 2: Quantify the cost difference
Get real numbers. What does the managed service cost at your current usage? What would the same capability cost on self-managed infrastructure, including the engineering time to operate it?
Include the ongoing operational overhead, not just the infrastructure cost. A database that requires 4 hours per month of maintenance attention costs $300–600 of engineering time per month at competitive rates, in addition to the hardware cost. Many businesses discover that self-hosting saves less than expected once this is fully costed.
Step 3: Identify hard constraints
Are there regulatory, contractual, or security requirements that constrain where this data or service can live? These are not preference — they are requirements. If the managed service cannot satisfy them, it is off the table regardless of the other factors.
Step 4: Evaluate reversibility
How difficult is it to move from the choice you make today to the alternative in 12–18 months? Some decisions are easy to reverse: moving from a managed container platform to self-managed Kubernetes is a well-trodden path. Others are harder: migrating petabytes of data from one storage system to another takes months of engineering effort.
For reversible decisions, optimise for what is right today. For hard-to-reverse decisions, factor in where you expect to be in two or three years.
★Remember This
The decision is: given your current operational capacity, the real cost difference, your hard constraints, and the reversibility of the choice — which option has the better expected outcome over the next 18 months? Not the best theoretical outcome. The best expected outcome given your specific situation.
Common Patterns by Stage
These are not prescriptions — every situation is different. But they reflect patterns that hold up across many businesses.
Early-stage (pre-product-market-fit)
Managed everything, almost without exception. Speed to production and reduction of operational overhead matter far more than cost optimisation or architectural purity at this stage. Use the most opinionated, managed deployment platforms available. Your engineering budget should go entirely to product, not to infrastructure.
Growth stage (scaling post-PMF)
This is where the first selective self-hosting decisions often make sense. Specific high-cost components — usually databases or compute at high sustained load — where the managed premium has become a significant line item. Move only what you have the operational capacity to run reliably. Keep everything else managed.
Scale (significant revenue, dedicated engineering teams)
A dedicated platform engineering function justifies more aggressive self-hosting for cost reasons. Specific compliance or security requirements may mandate it for certain components. The team has the operational experience to run infrastructure reliably without it consuming disproportionate engineering attention.
The Hybrid Decisions Worth Knowing About
Managed Kubernetes vs Platform-as-a-Service
Managed Kubernetes (EKS, GKE, AKS) is not the same as fully managed. You still manage the worker nodes, the cluster configuration, the deployment tooling, and the application layer. It is infrastructure-as-a-service with orchestration, not a managed application platform.
For teams without Kubernetes expertise, platform-as-a-service options (Railway, Render, Fly.io) offer significantly more operational simplicity at a higher per-unit cost. The right choice depends on your team's existing Kubernetes knowledge and the scale at which the cost premium matters.
Self-Hosted Open Source vs Managed Equivalents
Many popular open-source tools — Postgres, Redis, Kafka, Elasticsearch — have fully managed equivalents (RDS, ElastiCache, Confluent, Elastic Cloud). The managed versions cost more but remove operational burden. The self-hosted versions give full control but require expertise.
For foundational data infrastructure in production, managed versions are usually right. For development environments and tooling that runs internally without user-facing SLA requirements, self-hosted open source is often the cost-effective choice.
On-Premise for AI Inference
A specific case worth calling out: AI inference workloads can be expensive on managed cloud GPU instances. Businesses with consistent, high-volume inference workloads are increasingly finding that dedicated GPU hardware — either on-premise or in a colocation facility — is significantly more cost-effective than cloud GPU instances for sustained workloads.
This is genuinely a case where the calculus has shifted recently, and the decision deserves fresh analysis rather than a default to cloud for AI infrastructure.
What This Decision Is Not About
It is not about which is more "serious" or "production-grade." Self-hosted infrastructure is not inherently more serious than managed cloud — and managed cloud is not a sign of technical immaturity. The choice is operational, not reputational.
It is not about what the largest companies do. Netflix runs on AWS. Dropbox moved off the cloud for its primary storage. Both decisions were correct for those businesses at those stages with those teams. Neither decision tells you what is right for yours.
It is not a permanent decision. The right answer at year one may be wrong at year three. Make the decision for your current situation, revisit it when your situation changes, and avoid the sunk-cost fallacy when the calculus has shifted.
★The Bottom Line
Default to managed cloud. Move to self-hosting when you have the operational expertise to do it reliably, when the cost difference is concrete and significant, when compliance requires it, or when control of the underlying system is genuinely necessary for your product. Do not self-host to save money you are not actually saving, and do not stay on managed cloud when the cost or compliance case for self-hosting is clear.
If you are making infrastructure decisions for a new product or re-evaluating your current setup, let's talk. The right answer depends on your specific team, scale, and requirements — and we can help you work through it.