I self-host nearly everything. Kubernetes clusters on refurbished mini-PCs. GitLab on my own hardware. Vault for secrets. Monitoring, logging, all of it.
People often ask: why? Managed cloud is easier. AWS, Azure, Google do it at scale and reliably. Why put yourself through this?
The short answer: agency.
The long answer is this entire article.
The spaceship thought experiment
In my post about the space container thought experiment I describe a scenario: you wake up in a closed container in space. Everything you need to survive is present, but nothing goes in or out.
What do you do?
You start understanding your systems. You learn how oxygen is recycled, how water is purified, how energy is generated. You want to know every component, because your life depends on it.
This is how I look at infrastructure.
Not because my life literally depends on it. But because I want to understand what’s happening. I don’t want to depend on a black box that “just works” — until the moment it doesn’t work anymore and I have no idea why.
What is sovereignty?
Digital sovereignty means: having control over your own digital infrastructure, data, and processes.
The opposite is dependency:
- Your data is with a cloud provider who can change the terms
- Your infrastructure runs on a platform you don’t understand
- You’re bound to vendor lock-in that makes migration impossible
- Prices can rise without you having alternatives
Sovereignty isn’t about paranoia or distrust. It’s about having choices. About the freedom to leave when something no longer works. About understanding your own systems.
Why this works for me
For context about how my brain works, see Working with an AuDHD brain.
My AuDHD brain has a deep need for:
1. Understanding how things work
I can’t function well with black boxes. When something breaks, I want to know why. Not “it’s an AWS issue”, but the actual cause. Managed services hide complexity — that’s their value — but for me that hidden complexity feels like a splinter in my brain.
2. Predictability
Cloud pricing is notoriously unpredictable. Egress costs, API calls, reserved instances, spot pricing — it feels like a casino. My own hardware has a fixed monthly electricity bill. That’s it.
3. Control over my environment
This is the autism side: I want to be able to adapt my environment to how I work, not the other way around. If a tool doesn’t do what I want, I can adjust the configuration, read the source code, or choose something else. With managed services, “computer says no” is often the endpoint.
4. Learning by doing
ADHD makes it hard to learn by reading documentation. I learn by building, breaking, and fixing. My homelab is my playground. Every mistake is a lesson I actually remember.
In practice: what do I self-host?
My current stack runs on refurbished mini-PCs (commodity hardware, no expensive servers):
| Component | Solution |
|---|---|
| Kubernetes | K3s with embedded etcd |
| GitOps | ArgoCD (App-of-Apps pattern) |
| CI/CD | GitLab (self-hosted) |
| Secrets | HashiCorp Vault |
| Policy | Kyverno |
| Monitoring | Prometheus + Thanos |
| Logging | Loki |
| Tracing | Tempo |
| Dashboards | Grafana |
| CNI | Cilium (eBPF) |
| Storage | Longhorn + MinIO |
| Certificates | cert-manager |
| Auth | Keycloak |
Everything is GitOps-managed. Configuration in Git, ArgoCD syncs to the clusters. Declarative, reproducible, auditable.
Island mode
An important design principle: island mode capability. My clusters must be able to function without internet connection. This means:
- Local container registry mirrors
- No hard dependencies on external APIs
- All secrets local in Vault
- Documentation locally available
Not because I expect the internet to go down. But because this constraint forces robust design. If your system can work offline, it’s by definition less fragile.
The trade-offs
Self-hosting isn’t free. These are the costs:
Time
You are your own ops team. Cluster upgrades, security patches, incident response — that’s your work. This costs time, especially at the beginning.
My mitigation: automation. Automating K3s upgrades, GitOps for consistency, Kyverno policies that prevent misconfigurations.
Knowledge
You need to know what you’re doing. Kubernetes is complex. Networking is complex. Security is complex. The learning curve is steep.
My perspective: this is an investment, not a cost. The knowledge I gain by self-hosting makes me better at my job. I understand the abstractions because I know the implementations.
Initial investment
Hardware costs money. Not much — refurbished mini-PCs are cheap — but it’s a barrier.
The ongoing costs are lower than cloud though. My entire homelab costs less in electricity per month than one managed Kubernetes cluster.
No SLA
If it breaks, there’s no support ticket. No “this is an AWS problem”. It’s you.
This is also an advantage. I don’t wait for support. I debug myself. And by debugging, I learn.
When managed cloud makes sense
I’m not a dogmatist. Managed cloud has valid use cases:
Startup that needs to ship fast: Focus on your product, not on infra. Use managed services until scale or costs become a problem.
Team without ops expertise: If nobody knows Kubernetes, EKS/GKE/AKS is a reasonable choice. But: build the knowledge, so you can choose later.
Regulation that requires it: Some compliance requirements are easier with certified managed services.
Peak loads: If you need 10x autoscaling for Black Friday, cloud elasticity is valuable.
The point isn’t “cloud is bad”. The point is: make a conscious choice. Understand the trade-offs. Don’t choose managed “because everyone does it”, but because it fits your situation.
The philosophy behind the choice
Buckminster Fuller called Earth “Spaceship Earth” — a closed system where we’re all astronauts. His point: we need to understand our system to be able to maintain it.
I see my infrastructure the same way. It’s my little spaceship. I want to know how the life support works. Not because I distrust cloud providers, but because I believe in:
Understanding over trust
Trust is fine. But understanding is better. If I grasp how something works, I can debug it, optimize it, and adapt it. If I only trust, I depend on the goodwill and competence of others.
Options over convenience
Managed services are easy until you want to leave. Vendor lock-in is comfortable until it becomes a prison. I choose for a bit more work now, in exchange for freedom later.
Learning over consuming
Every time I solve a problem myself, I build knowledge. Every time I use a managed service, I outsource that knowledge. Sometimes that’s fine. But as a pattern it makes you dependent.
How to start
If this resonates and you want to start self-hosting:
1. Start small
One Raspberry Pi or old laptop. Docker Compose. No Kubernetes. Learn the basics of containers, networking, and storage.
2. Build incrementally
Add one service at a time. Each addition is a learning opportunity. Don’t try to do everything at once.
3. Document everything
Future you will be happy with notes. Why did you choose this configuration? What were the alternatives? What went wrong?
4. Accept failure
Things will break. That’s the point. Every failure is a lesson. In a homelab the consequences are low and the lessons valuable.
5. Connect with community
Homelab subreddits, Discord servers, local meetups. Others have had the same problems. Learn from their solutions.
Conclusion
Why do I self-host everything?
Not because managed cloud is bad. Not out of paranoia or distrust. Not to save money (though that’s a side benefit).
I self-host because I want to understand. Because I want to have choices. Because I want to be able to maintain my own spaceship.
This isn’t a prescription. Not everyone needs to self-host everything. But everyone should make the choice consciously. Understand what you give up when you go to managed cloud. Understand what you get.
And if you, like me, have a brain that can’t tolerate black boxes and needs deep control to function — then sovereign infrastructure might be exactly what you’re looking for.
It’s more work. But it’s also more freedom.
And for me, that freedom is worth it.
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