One month in. The migration from Gentoo + Docker to Fedora Server 43 + MicroShift is complete and everything is running in production: mail stack, Nextcloud, Vaultwarden, Paperless, Collabora Online, monitoring, and this website — all on a single VPS, orchestrated by Kubernetes, managed by GitOps. So far, so good.
But let me be honest about the complexity. The full documentation runs to eight major sections covering base system, storage, firewall, WireGuard, MicroShift, GitOps, TLS, and eight services with their operational scripts. Behind that documentation are 368 commits across two repositories in four weeks — 232 in the GitOps manifests repo alone, 136 in the runbook. That’s not a “deploy and forget” setup. Every one of those commits represents something that had to be figured out, fixed, or explicitly decided.
If you’re considering a similar setup, that number is the most honest thing I can tell you.
Why Not Gentoo Anymore?
I ran Gentoo for many years. Custom-compiled everything, intimate knowledge of every package, full control. But that model is becoming harder to justify.
The fundamental shift is this: I no longer see a future in running workloads natively on a Linux host. Maybe RHEL image mode as a narrow exception, but the era of “configure this daemon directly on the OS” is ending for me. The container orchestrator that won — after ten years of ecosystem consolidation — is Kubernetes. Everything gravitates toward it: tooling, documentation, community knowledge, operational patterns.
And Kubernetes has a hard dependency: a clean, well-integrated SELinux implementation. Not SELinux as an afterthought, but SELinux as a first-class security layer with proper policy tooling and upstream support baked in. Gentoo simply doesn’t deliver that the way Red Hat does. MicroShift runs on RHEL/Fedora because that’s where the SELinux integration is mature. Running it on Gentoo would mean fighting the platform instead of using it.
The other thing Kubernetes brought along is GitOps — the practice of describing your entire
infrastructure state in Git and having a controller reconcile the cluster to match. With Flux CD,
a merge to main is a deployment. The history is auditable. Rolling back is reverting a commit.
This is the operational model that makes sense at scale, and it works just as well for a single VPS
homelab as it does for a fleet of clusters.
Would I Recommend MicroShift for Beginners?
Definitely not. If you want to run a Kubernetes homelab without prior Kubernetes experience, start with k3s or something similar. MicroShift is opinionated in ways that will confuse you if you don’t already know what Security Context Constraints are and why they’re different from Pod Security Admission. The documentation assumes OpenShift familiarity.
Is MicroShift fully mature? Also no, not quite. In an ideal world, I’d want a ready-made appliance image — something like RHEL for Edge with MicroShift pre-integrated, where the OS and the orchestrator are packaged and tested together. That product exists: RHEL MicroShift on Edge. But it’s for enterprise customers, not homelabs.
I use MicroShift because we work with it professionally, and because Red Hat’s overall approach genuinely impresses me: the layering of CRI-O, SELinux, SCCs, OVN-Kubernetes, the HAProxy ingress router — it’s a coherent system where the pieces were designed to fit together. OpenShift would be the real thing to run here, but my VPS doesn’t have the resources for a full OpenShift cluster. OpenShift is, frankly, the hammer. MicroShift is what fits on a single node.
Why Btrfs Instead of ZFS?
I ask myself that sometimes. ZFS is more enterprise-grade than Btrfs in almost every measurable way. The snapshot space accounting is better (I wrote about exactly that difference). The tooling is more mature.
But here’s the thing: I want automatic OS updates and automatic container updates. I want to merge
a Renovate PR on my phone and have the new version running in the cluster 60 seconds later. What I
don’t want is to check, every few months, whether the current ZFS-on-Linux version has been
validated against the new kernel that dnf5-automatic just installed. ZFS is an out-of-tree kernel
module. That means it lags kernel releases, sometimes significantly, and if you want fully automatic
unattended upgrades, that gap becomes a liability.
With Btrfs, the filesystem is in-tree. dnf5-automatic applies the update, reboots if needed,
and the filesystem works. Grub-btrfs has already registered the pre-update snapshot in the GRUB
menu. If something breaks, I’m at the old system in thirty seconds. If nothing breaks, I got a
GitHub notification, merged it, and moved on.
That trade-off — slightly less capable filesystem in exchange for zero-friction automatic updates and instant rollback — is the right one for how I actually use this system.
The Bottom Line
The setup works and I’m happy with it. But it’s genuinely complex, and the commit count is the proof. If you’re not already comfortable with Kubernetes, SELinux, Btrfs, systemd, and GitOps as separate topics, this stack will be steep.
The full runbook — every step, every decision, every script — is documented at /homelab/.