Why I self-host everything: on sovereignty, agency and control

For a long time the cloud was just the water I swam in. I provisioned managed Kubernetes, clicked through the console, pasted a Terraform module someone else had written, and shipped. It worked. The bill landed every month, the dashboards stayed green, and I didn’t look underneath. Why would I? I trusted it the way you trust a lift. Press the button, doors open.

Then one afternoon a managed service fell over and I sat there with nothing to debug. No host to SSH into, no log I was allowed to read, nothing underneath it I could open up. The status page said “investigating”. Refreshing a page someone else controlled was the whole of my afternoon.

I self-host nearly everything now. Kubernetes on refurbished mini-PCs, Forgejo on my own hardware, Vault for secrets, plus monitoring, logging, the lot. People ask why, and it’s a fair question, because managed cloud is easier and AWS, Azure and Google run it at scale and reliably. The answer started on that afternoon, and it took me a while to say it out loud.

The short version is agency. The long version is this post.

The afternoon the black box stayed shut

Nothing about that outage was dramatic. A managed component I depended on stopped responding, my app started throwing errors, and I went to do what I always do when something breaks. Find the cause.

I couldn’t. The thing that was failing lived behind an abstraction I had no access to. I could see the symptom and nothing else. So I opened a support ticket and waited, which is a polite way of saying I sat on my hands while my own system was broken.

The downtime itself didn’t bother me much. Downtime happens. What bothered me was that I had no relationship with my own infrastructure. I’d outsourced the running of it, fine, but I’d outsourced the understanding of it too, without noticing. When it broke there was nothing for me to pull on, because I’d never been allowed near it.

That’s the splinter. A black box I’m responsible for feels like a splinter under the skin. I need to understand what I’m running, and a system I can’t open is a system I can only wait on.

A default I’d never looked at

With the ticket still open I had to admit something I didn’t like. I’d been telling myself the cloud was a choice. It wasn’t. It was a default I’d never examined. Every team I’d worked on used it, so I used it. There was a trade-off in there, and I’d never once looked at it.

The trade-off goes like this. Managed services hide complexity, and hiding complexity is exactly what you pay them for. The hard parts stop being your problem. But the complexity doesn’t go anywhere. It moves behind a wall you’re not allowed past. On a good day that wall is convenience. On the afternoon I’m describing, it was the reason I couldn’t do my job.

For context on how my brain works, see Working with an AuDHD brain.

My AuDHD brain made the splinter impossible to ignore. When something breaks I want the cause, and “it’s an AWS issue” is a shrug with a status code. Hidden complexity doesn’t feel restful to me. It feels like an itch I can’t reach. The autism side wants to shape my environment to how I work rather than the other way round, and “computer says no” is where managed services tend to end that conversation. The ADHD side learns by building and breaking, with the docs coming a distant second, and a black box gives you nothing to take apart.

So the question I’d been avoiding was a simple one. Had I ever decided on managed infrastructure, or had I just ended up there? That afternoon the honest answer was the second one. And I couldn’t un-know it.

What I decided sovereignty means

Digital sovereignty means real control over your own infrastructure, data and processes. The opposite is dependency, and dependency has a shape you can recognise. Your data sits with a provider who can change the terms whenever they like. Your infrastructure runs on a platform you don’t understand. Vendor lock-in makes leaving expensive enough that you never do. Prices go up and you have nowhere to walk to.

I want to be careful here, because this turns into paranoia fast, and I don’t mean paranoia. Sovereignty is having choices. The freedom to leave when something stops working for you, and enough understanding of the system that leaving is even possible. A dependency on something you can’t inspect or control is a vulnerability. I file it next to an unpatched service, and I treat it the same way.

So I chose. I stopped letting the default decide for me. The things I depend on would run on hardware I own, with software I can read, so that the next time something breaks I have somewhere to start.

The closed container in space

There’s a scenario I keep coming back to, and I wrote it up separately as the space container thought experiment. You wake up inside a sealed container drifting in space. Everything you need to stay alive is in there with you, and nothing comes in or goes out. What do you do?

You start learning the systems. How the oxygen gets scrubbed and recycled, how the water is filtered, where the power comes from. You want to know every component, because in that container a black box can kill you.

My homelab isn’t a survival pod, and I’m under no illusion that it is. But the instinct carries over. I want to understand the systems I depend on, far enough down that I could fix them if I had to. Island mode, a few sections down, is the same idea with a power switch.

What that choice looks like in practice

My current stack runs on refurbished mini-PCs. Commodity hardware, no expensive servers:

Everything is GitOps-managed. Configuration lives in Git, ArgoCD syncs it to the clusters, and the whole thing is declarative, reproducible and auditable. When I want to know why something is the way it is, the answer is a git log away.

Island mode

One design rule I push harder than the rest is island mode. My clusters have to keep working without an internet connection. In practice that means local container registry mirrors, no hard dependencies on external APIs, every secret held locally in Vault, and documentation that lives on the cluster instead of on someone else’s website.

I don’t expect the internet to vanish. The constraint is there for what it does to the design. A system that survives being cut off is a system you understand all the way down, because you had to find and remove every dependency you couldn’t account for. Offline-capable and well-understood turned out to be the same requirement.

The bill for all this

Rebuilding on hardware I own came with a price tag, and leaving it out would make this an advert. So here’s the invoice.

Time first. You’re your own ops team. Cluster upgrades, security patches, incident response, that’s your evening now. It costs real hours, especially at the start. I pay it down with automation. K3s upgrades run themselves, GitOps keeps everything consistent, and Kyverno policies block the misconfigurations I’d otherwise make when I’m tired.

Then knowledge. You have to know what you’re doing. Kubernetes, networking and security each have a steep curve, and self-hosting hands you all of them at once. This is the part of the bill I’m happy to pay. The knowledge I buy by running my own stack makes me better at the day job, because I understand an abstraction a lot better once I’ve seen what’s under it.

Money up front. Hardware costs something. Refurbished mini-PCs are cheap, but cheap isn’t free, and it’s a barrier if you’re starting cold. The running costs land in my favour, though. My entire homelab draws less electricity in a month than one managed Kubernetes cluster costs to rent.

And no SLA . When it breaks there’s no ticket to file and no “this is an AWS problem” to hide behind. It’s me. That was the point, so I don’t get to complain about it. I don’t wait on a status page anymore. I open a shell and start looking, and the looking is where the understanding comes from.

When I’d still reach for managed cloud

I made a choice for my situation, and I’d be a hypocrite to pretend it’s the only right one. Managed cloud earns its place in plenty of cases.

A startup that needs to ship this quarter should be working on the product and leaning on managed services until scale or cost starts to hurt. A team where nobody knows Kubernetes is making a sensible call with EKS, GKE or AKS, as long as they keep building the knowledge so the choice stays open. Some compliance regimes are easier to satisfy with certified managed services. And if you need ten times the capacity for one Black Friday, cloud elasticity is worth real money.

What all of these have in common is the thing I missed for years. Make the choice on purpose. Look at the trade-off, name what you’re handing over and what you get back, and then pick managed because it fits. Picking it because everyone around you had is how I ended up refreshing that status page.

Where that leaves me

The day-to-day looks a lot like it did. Kubernetes, YAML in the evenings, the occasional outage to chase. The dashboards point at boxes in my own rack now, and that’s most of the visible difference.

The difference I feel is that I can reach it. I no longer treat my infrastructure as a subscription I hope keeps working. It’s a system I’m responsible for and can get into. When something breaks now there’s always somewhere to start, and starting there teaches me something.

Understanding beats trust for me. If I know how something works I can fix it, tune it and change it. If I only trust it, I’m betting on someone else’s competence and goodwill, and on that afternoon the bet lost. Options beat convenience. Managed services are lovely right up until you want to leave, and the cost of leaving is one they charge you the whole time without ever itemising it. And I’d rather learn than consume. A problem I solve myself I can solve again next year. The ones I outsourced I couldn’t solve once.

If you want to feel some of this yourself, start small. One Raspberry Pi or an old laptop, Docker Compose, no Kubernetes yet. Containers, networking and storage are plenty. Add one service at a time and let each one teach you something. Write down why you chose what you chose, because you won’t remember. Expect things to break, because in a homelab the blast radius is tiny and the lesson is the same size as it would be at work. And talk to other people doing the same thing. Someone in a homelab forum has already hit your exact wall and written up how they got past it.

This isn’t a prescription. Not everyone needs to self-host everything, and plenty of people are right to stay on managed cloud with their eyes open. The one thing I’d ask is what that afternoon asked of me. Don’t let the default decide for you. Know what you give up when you hand a system to someone else, and know what you get.

The splinter never fully came out. I’ve stopped wanting it to. When something breaks now, I open a shell.

Related posts:

• The space container thought experiment - Systems thinking and closed systems
• Working with an AuDHD brain - How my brain influences my tech choices
• ArgoCD for beginners - Declarative infrastructure
• Building an Internal Developer Platform - The broader context

• Philosophy
• Privacy