In my last post, The Birth of My Homelab, I shared the hardware I started with. This time, I want to dive into the “why” behind the stack I chose.
The cluster is simple for now — still a work in progress — but getting here took a lot of background work. I’m sure some of these choices will pay off later. For now, here’s why I picked this stack.
Kairos#
This one’s obvious: I work on Kairos. But here’s the thing — I wouldn’t run it at home if I didn’t believe it was the best fit for me.
Sure, there are other OS options for container workloads, and I could make a few of them work. But none offers something so compelling that I’d want to invest in learning yet another OS from scratch. Kairos does offer something I can’t get elsewhere: I get to choose my base distribution.
Over the years I’ve run Ubuntu, openSUSE, and Arch extensively. Each has its strengths and ideal use cases. With Kairos, I can run the one that fits best for the project at hand (Arch isn’t supported out of the box right now, but Kairos can be extended to use it — and no other container OS even offers that option). That’s the power of Kairos being truly open — not just “the source is public” open, but “built to play well with others” open.
And then there’s the day-2 experience, which I think is outstanding:
- Create custom images and bootable artifacts for installs or upgrades.
- Offload builds to the Kairos Factory GitHub Action.
- Manage upgrades with the kairos-operator right from Kubernetes.
- Use A/B upgrades with quick rollbacks when something goes wrong.
I’ll cover my build-and-upgrade process in a follow-up post — it’s one of my favorite parts.
Ubuntu#
I could have gone with openSUSE here too. My only hard requirement was systemd. That ruled out Alpine for this use case because one key functionality in Kairos — Trusted Boot — relies on systemd-boot’s implementation for using the TPM to measure your Unified System Image.
Most nodes will be at home, so Trusted Boot wasn’t a hard requirement for all of them. But I do want to enable it on at least one node that I’ll place externally, where security matters more.
I’ve spoken at several events about how powerful this feature is, why you should care if security is a high-stakes concern, and how we implemented it in Kairos. I’ll link one of those talks here so you can dive in.
The other reason for Ubuntu is simple: dogfooding. Most of my work testing happens on Ubuntu. Running a similar stack at home means I hit the same pain points as our users and can fix them faster.
k0s#
Kairos started with first-class support for k3s. It’s battle-tested and would have been the safe choice.
One of my early gripes with Kubernetes, though, was how tightly the control plane and workers can feel coupled in practice. That’s an upstream reality, not a k3s problem, but the k0s model of making the split explicit clicks better for me. When William Rizzo, CNCF Ambassador, opened a PR to add k0s support in Kairos, I was sold. We even wrote about the collaboration on the CNCF blog.
A huge thank you to William for inspiring me to work on this — working together has been a lot of fun. We’ll be co-presenting a talk called “The Immutable Lightness of an Edge Platform” at some upcoming events if you want to know more about our work or ask us questions in person.
I could have stopped there — k0s has been great in my simple setup — but then I fell down the Hosted Control Plane rabbit hole. We ran a workshop on HCP at Cloud Native Day Italy in Bologna, and later I found k0smotron, k0s’ take on HCP. That sealed it. For my homelab, I want to spin up dedicated control planes when it makes sense instead of shoving everything into one controller.
A concrete example: my doorbell node. It needs better responsiveness than anything else I’m running right now. Giving it its own hosted control plane keeps the blast radius small and the latency tight. Kudos to Jussi and the team for the design.
The real value of a cluster is in the workloads, not the cluster. But my goal with this project is to learn — Kubernetes, containers, and Linux in general. Knowing the why behind the stack helps me design to the strengths of the tools. Yes, this is overkill for the silly apps I’ll run, and that’s fine. It’s a great way to understand how these distributed systems behave in the real world. It also helps me make better decisions when I build features in Kairos or help others adopt it.
Only experience will tell me which choices were wrong. If I get it wrong, I’ll know why — and I’ll know what a better design could look like.
If you have thoughts on the stack or suggestions, I’d love to hear them. Shoot me an email at the link below.
Reply by Email