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 wrote, and shipped. It worked. Billing landed every month, the dashboards stayed green, and I never once asked what was actually running underneath. I trusted it the way you trust a lift in a building. You press the button and the 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, no layer I could peel back. The status page said “investigating.” That was the whole of my agency: refreshing a status page someone else controlled.

I self-host nearly everything now. Kubernetes on refurbished mini-PCs. GitLab on my own hardware. Vault for secrets, plus monitoring, logging, the lot. People ask why, because managed cloud is easier and AWS, Azure and Google do it at scale and reliably. The honest answer started with that frozen afternoon, and it took me a while to put words to it.

The short word is agency. The longer answer is this whole 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. 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 and there was nothing I could do about it.

What bothered me was not the downtime. Downtime happens. What bothered me was the feeling I had no relationship with my own infrastructure. I had outsourced not just the running of it but the understanding of it. When it broke, I had no thread to pull, because I had never been allowed near the threads.

That is the splinter. Black boxes feel like splinters under the skin. I need to understand what I’m running, and a system I can’t inspect is a system I can only pray to.

The question I had been avoiding

Sitting with that ticket open, I had to admit something uncomfortable. I had been telling myself the cloud was a choice, when really it was a default I had never examined. Everyone used it, so I used it. The trade-off was real, I had just never looked at it.

Here is the trade-off, stated plainly. Managed services hide complexity, and hiding complexity is exactly their value. You pay them to not think about the hard parts. But the complexity does not disappear. It moves behind a wall you are not allowed to climb. On a good day that wall is convenience. On a bad day it is a prison, and you discover the bars at the worst possible moment.

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 actual cause, not “it’s an AWS issue”. Hidden complexity does not 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 instead of the reverse, and “computer says no” is where managed services tend to end that conversation. The ADHD side learns by building and breaking, not by reading docs, and a black box gives you nothing to take apart.

So the real question was not “is the cloud good or bad”. It was: am I running on managed infrastructure because I chose it, or because I never stopped to choose? That afternoon, the honest answer was the second one. And once you see a default for what it is, you can’t unsee it.

What I decided sovereignty actually means

Digital sovereignty means having real control over your own infrastructure, data, and processes. The opposite is dependency, and dependency has a specific shape:

• 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 climb and you have no alternative to walk to

I want to be careful here, because this is easy to turn into paranoia, and that is not it. Sovereignty is about having choices. It is the freedom to leave when something stops working for you, and the ability to understand the system well enough that leaving is even possible. A dependency on something you can’t inspect or control is a vulnerability, full stop. Not a moral failing, a vulnerability, the same way an unpatched service is.

So I made a choice. Not to rage against the cloud, but to stop drifting into it. To run the things I depend on, on hardware I own, with software I can read, so that when something breaks I have a thread to pull.

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, but nothing comes in and nothing goes out. So 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 the cost of a black box in that container is your life.

My homelab is not a survival pod, and I’m under no illusion that it is. But the instinct transfers cleanly. I want to understand the systems I depend on, down to the layer where I could fix them if I had to. Island mode, a few sections down, is the same idea given 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 principle pushed harder than the rest: island mode capability. My clusters have to keep functioning without an internet connection. In practice that means local container registry mirrors, no hard dependencies on external APIs, all secrets held locally in Vault, and documentation that lives on the cluster instead of on someone else’s website.

I don’t actually expect the internet to vanish. The point of the constraint is what it does to the design. A system that can survive being cut off is a system you understand all the way down, because you had to remove every dependency you couldn’t account for. Offline-capable and well-understood turn out to be the same property wearing two hats.

The bill for all this

I deleted the easy path and rebuilt on hardware I own, and that rebuild came with a price tag. Pretending otherwise would make this an advert, so here is the honest invoice.

Time. You are your own ops team. Cluster upgrades, security patches, incident response, that’s all your evening now. It costs real hours, especially at the start. I pay this down with automation: automating K3s upgrades, GitOps for consistency, and Kyverno policies that block the misconfigurations I’d otherwise make at midnight.

Knowledge. You have to actually know what you’re doing. Kubernetes, networking and security each have a steep curve, and self-hosting hands you all three at once. I think of this as 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 the abstractions when I’ve also seen the implementations underneath them.

Money up front. Hardware costs something. Refurbished mini-PCs are cheap, but cheap is not 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.

No SLA. When it breaks, there’s no ticket to file and no “this is an AWS problem” to hide behind. It’s me. Which is the whole point. I no longer wait on a status page. I open a shell and start pulling threads, and the debugging is where the understanding gets built.

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 correct one. Managed cloud earns its place in plenty of cases.

A startup that needs to ship this quarter should focus on the product, not on infra, and lean on managed services until scale or cost makes them 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 genuinely 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.

The thread running through all of these is the same one 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 pick managed because it fits, not because it’s the current of the river you happened to be floating on.

What changed, quietly

I still run Kubernetes. I still write YAML at night and chase the occasional outage. From the outside not much looks different from the managed days, except that the dashboards point at boxes in my own rack.

What changed is the relationship. I no longer treat my infrastructure as a service I subscribe to and hope about. I treat it as a system I’m responsible for and can actually reach. When something breaks now, there’s always a thread to pull, and pulling it teaches me something instead of leaving me refreshing a status page.

Three things carry that for me. Understanding beats trust, because if I grasp how something works I can fix it, tune it and change it, and if I only trust it I’m betting on someone else’s goodwill and competence. Options beat convenience, because managed services are lovely right up until you want to leave, and the cost of leaving is the cost they’re quietly charging the whole time. And learning beats consuming, because every problem I solve myself becomes knowledge I keep, while every one I outsource is knowledge I rent.

If you want to feel some of this yourself, start small. One Raspberry Pi or an old laptop, Docker Compose, no Kubernetes yet, just containers, networking and storage. Add one service at a time and let each one teach you. Write down why you chose what you chose, because future-you will need it. Expect things to break, since in a homelab the blast radius is tiny and the lessons are real. And talk to other people doing the same thing, because 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 thing I’d ask of anyone is the thing that afternoon asked of me: don’t let the default decide for you. Understand what you give up when you hand a system to someone else, and understand what you get.

For me the splinter never fully comes out, and I’ve stopped wanting it to. It’s the thing that keeps me reaching for the next layer down. Sovereign infrastructure costs more work, and it buys more freedom, and after running on it for a while I can’t imagine going back to praying at a status page.

Related posts:

• The space container thought experiment - Systems thinking and closed systems
• Working with an AuDHD brain - How my brain influences my tech choices
• GitOps for beginners - Declarative infrastructure
• Homelab hardware choices - The physical side of self-hosting
• What is Platform Engineering? - The broader context