I get asked some version of "should I run Kubernetes at home" often enough that it's easier to write this down than answer it fresh each time. Short version: probably not, but the exceptions are more common than the Kubernetes-skeptic crowd likes to admit.
The short answer, up front
If your homelab is under roughly ten containers and one person maintains it, Kubernetes — even the lightweight k3s — adds more operational surface than it removes. Docker Compose plus a couple of systemd units does the same job with a fraction of the moving parts. I ran plain Compose for four years before touching k3s, and nothing about that period made me feel like I was missing out.
This is specifically about homelabs — a handful of physical or virtual nodes maintained by one person for personal use. Production clusters with a team behind them are a different calculation entirely.
What k3s actually costs you
k3s strips out a lot of upstream Kubernetes weight, and it's genuinely the easiest on-ramp if you're going to do this. But you still inherit the core conceptual overhead: namespaces, services, ingress controllers, persistent volume claims, and a control plane that can itself fail in ways a single Compose file never will. I lost a Saturday afternoon to a corrupted etcd datastore on a three-node k3s cluster that existed purely to run a Pi-hole and two Node-RED instances. That's not a Kubernetes problem so much as a proportionality problem.
What broke, roughly
# k3s server logs, abbreviated
level=fatal msg="starting kubernetes: preparing server: start cluster and https: raft_replication.go..."
# two hours later: etcd snapshot restore, half of it from memoryWhen it's genuinely worth it
The calculation changes once you cross a few thresholds:
- You're running enough services that rolling restarts matter. Past 15–20 containers, Kubernetes's declarative reconciliation genuinely saves time over hand-managed Compose files.
- You want to practice for work. If your job involves Kubernetes, running it at home for deliberate practice is a completely legitimate reason that has nothing to do with whether it's the "right tool" for a homelab.
- You have actual multi-node hardware sitting idle. Bin-packing workloads across three or four small nodes is where Kubernetes starts to earn its complexity budget back.
What I run instead on the small nodes
My current setup is Docker Compose per host, each host's compose files tracked in the homelab-iac repo I mention on the projects page, with Ansible handling the parts that would otherwise need a control plane — rolling out config changes, restarting stacks, and keeping images current via a scheduled docker compose pull && up -d.
The entire "orchestration layer," roughly
# systemd timer, runs nightly
ExecStart=/usr/bin/docker compose -f /srv/stacks/media/compose.yml pull
ExecStartPost=/usr/bin/docker compose -f /srv/stacks/media/compose.yml up -dThis doesn't give you self-healing across node failure. If a host dies, its services stay down until I intervene. For a homelab, I've decided that's an acceptable tradeoff for the reduction in daily complexity — your risk tolerance may differ if the homelab runs anything that matters to other people.
How I'd migrate if I changed my mind
If the node count grows past the threshold above, the path I'd actually take is k3s with a single control-plane node and Longhorn for storage, migrating one stack at a time rather than a big-bang cutover. Compose files translate to Kubernetes manifests reasonably cleanly with kompose as a starting point, though I'd hand-rewrite anything that touches storage.
For now, the honest reason I haven't is that the current setup has never actually failed me in a way Kubernetes would have prevented — and I'd rather write about the day it does than convert on principle.