Stop Asking "Cloud or Self-Hosted." That's Not the Question Anymore.

I'll say the unpopular thing first: most infra debates I see on Twitter/X and in Slack threads are arguing about the wrong axis. People fight "cloud vs. self-hosted" like it's a religion: Terraform-slinging cloud purists on one side, homelab-brained self-hosters on the other, and both of them are optimizing for vibes, not for the actual failure mode they're trying to prevent.

Here's the question I actually care about when I'm looking at a system design doc:

If this gets popped, who else is in the blast radius, and did we choose that, or did we just inherit it from whatever the last person set up?

That's it. That's the whole post, if you want the TL;DR. Everything below is just me unpacking why that question matters more than "AWS or bare metal."

The uncomfortable stat that made me actually care about this

I used to think "supply chain risk" was a phrase security-compliance people used to justify their headcount. Then I actually sat down with the numbers instead of rolling my eyes at the phrase.

Verizon's 2026 DBIR crunched over 22,000 confirmed breaches. Vulnerability exploitation was the top initial-access vector at 31%. Third-party involvement, up 60% year-over-year, showed up in 48% of breaches. Not "a notable minority." Basically a coin flip.

And it's not abstract. In 2025, attackers went after a third-party SaaS CRM and walked into TransUnion and Allianz Life through it. Allianz's own infrastructure was never touched; the breach happened entirely inside a system they didn't operate. MOVEit is the bigger-blast-radius version of the same story: one vuln in one file-transfer product, and thousands of downstream companies had a very bad week without shipping a single bad commit themselves.

If you've ever been in an incident channel at 2am trying to figure out if you're compromised or your vendor is, you know exactly the feeling I'm describing. It's a specific kind of helpless: staring at your own clean logs while the actual breach is happening in someone else's environment that you can't SSH into, can't kubectl logs, can't do anything about except wait for their status page to update.

Same app, same team, same on-call rotation. The difference is entirely in how many hops sit between "something's wrong" and "we can actually see what's wrong."

No, self-hosting doesn't make you immune. Don't @ me with that take.

I want to kill this myth before someone in the comments does it for me: running your own boxes does not mean you've escaped third-party risk. You've relocated it.

Your beautifully self-hosted, fully-owned Kubernetes cluster is still standing on:

kernel maintainers → containerd → your base images (probably debian:slim,
be honest) → npm/PyPI transitive deps → NIC firmware → your switch vendor
→ your CA → your DNS provider → GitHub/GitLab → Prometheus/Grafana →
whatever's doing your backups → your ISP or colo contract

Any one of those gets compromised, you're having the exact same bad day as the SaaS-dependent team next door, except your incident retro is longer because now you also have to explain why you thought owning the hardware meant you owned the risk.

What actually changes when you self-host is narrower than the pitch decks make it sound: you shrink the list of parties who can read or move your sensitive data, and you know every name on that list. That's real. It's also a lot less glamorous than "we control our destiny," which is the line I keep seeing on LinkedIn from people who have clearly never had to patch a CVE in their own Kubernetes control plane at 11pm.

Data residency ≠ self-hosting, and conflating them will get you a bad architecture

This one genuinely surprised me when I dug into it. I assumed "data has to stay in-country" automatically meant "so we need our own hardware in-country." It doesn't.

Take RBI (India's central bank, for anyone reading this outside the region). Their rule on payment-system data is: store it in India. That's about the regulator being able to reach the data, not about who owns the rack it sits on. Their broader IT-outsourcing and cloud guidance is explicit that cloud is fine, provided you've actually done a risk assessment and can account for the full data lifecycle, ingestion to deletion.

So if the justification on your design doc for a giant self-hosting migration is "compliance requires it," go actually read the regulation before you file the epic. A lot of the time what's required is a region and a control set, and aws configure region ap-south-1 plus customer-managed KMS keys gets you there without a single rack purchase order.

Words I try to use precisely, because I've watched "self-hosted" cause actual miscommunication in planning meetings

I've been in a sprint planning session where three engineers said "self-hosted" and meant three different infra models, and nobody noticed until the ticket was already half-built wrong. So:

None of these mean going back to SSHing into a box and manually running apt upgrade. You can run full GitOps, Terraform, ArgoCD, Prometheus, the works, on hardware you own just as easily as on EKS. "We own the infra" and "we run infra like it's 2009" are not the same sentence, and it's a little annoying how often people treat them as synonyms.

What this actually looks like in a real system

Forget abstract "layers." Here's roughly what I'd draw on a whiteboard for a payments-adjacent service, if someone asked "okay but what does 'high-control infra' even mean":

Nothing exotic. It's the boring architecture most people would build anyway. The only thing that changes vs. a pure-SaaS version is: no third party sits between the gateway and DB, the KMS is yours, and the only path into IAM for a human is a bastion host with hardware MFA, not a vendor's SSO tenant.

Three things I'd push back on if a junior on my team proposed this without the caveats:

"We own the infra now, so our SOC 2 scope shrinks." Nope, usually the opposite. You've got more direct evidence to hand the auditor, sure, but you've also just inherited every infra-layer control (patching cadence, physical security, hardware disposal) that your cloud provider used to eat for you. Read that back before you put it in a slide.

"It's self-hosted, so we're compliant." Compliance isn't a hosting model, it's a paper trail. You still have to prove access control, retention, deletion, encryption, and incident response regardless of whose rack it is. Owning the hardware doesn't write your runbooks for you.

"We're not exposed to a cloud region outage anymore." True, and also: does your single data center have the failover a hyperscaler's multi-region setup has? If not, you didn't remove the outage risk, you just swapped "us-east-1 had a bad day" for "our one facility had a bad day," and I'm not convinced that's strictly an upgrade.

The actual decision tree I use, per-service, not per-company

I stopped trying to answer this once for the whole org. It's a per-workload question:

Notice "touches regulated data" isn't an instant self-hosting trigger here, on purpose. RBI's own guidance says regulated data can live in the cloud if the controls are real. The gate is whether you need direct control to manage the risk, not whether the data category sounds scary in a compliance meeting.

Cost: please stop citing that one vendor's $1.2M vs $0.4M chart

You've seen it. Some storage vendor's whitepaper with the clean bar chart, cloud on one side, on-prem on the other, on-prem always winning by a suspiciously tidy margin. I'd bench that source; it's usually from a company selling you the on-prem hardware.

The real shape of it: cloud wins hard on spiky, unpredictable load. You're not buying 400 machines for a traffic spike that lasts a week and a half. Self-hosting starts winning when a workload is big, steady, and running hot 24/7 for years, because that's when recurring compute/storage/egress bills quietly outpace what capex would've cost you. Build your own TCO model (engineering time, power, cooling, hardware refresh cycles, DR) instead of trusting someone else's bar chart with an agenda.

The risk nobody puts in the RFC

Here's the one that's bigger than any single team's design doc: if a handful of major banks and fintechs all sit on the same critical cloud/ICT provider, that provider's incident stops being their problem and becomes everyone's problem simultaneously.

This is basically what the EU's DORA regulation is getting at. Not "no cloud allowed." In November 2025, EU regulators formally designated specific ICT providers as "critical" based on how systemically important and hard-to-replace they are. That's a regulator saying, in writing, "concentration risk is now a tracked category," independent of whether any individual vendor's security is good.

Not something a single engineer fixes in a PR, but worth knowing it's a live regulatory concern if you're anywhere near a regulated industry.

What I actually check before I sign off on an architecture

Five questions, per service, not a company-wide mandate:

1. What's actually in it? PII, payment data, health records, IP, or nothing that matters if it leaks?
2. What's the actual blast radius if it goes down? A Slack apology, or a legal filing?
3. What do we specifically need direct control over? Keys, region, network boundary, privileged access, logs?
4. Is the load predictable or spiky? This one alone kills more self-hosting proposals than any security argument.
5. Can we actually run this well? If the team can't patch, monitor, and recover it competently, "owning" it is a liability wearing a security-upgrade costume.

Where I've landed, for what it's worth

Cloud stays the default for anything elastic or low-stakes; I have zero interest in rebuilding S3 for a marketing site. But for the handful of systems where a breach or outage is genuinely catastrophic, I want a short, known list of who can touch that data, and I'd rather most of that list be people on my own team, reachable on my own on-call rotation, not a status page I have to refresh.

That's really the whole take: not "self-host everything," not "cloud no matter what," just actually decide where that line sits, instead of inheriting it from whatever the platform team wired up three years ago and nobody's revisited since.