GitOps for Homelabs: How ArgoCD App-of-Apps Scales Your Cluster
Managing a homelab Kubernetes cluster by hand eventually breaks you. Not in a dramatic way — in a slow, grinding way. You tweak a deployment to fix something urgent, forget to commit the change, an...
Source: DEV Community
Managing a homelab Kubernetes cluster by hand eventually breaks you. Not in a dramatic way — in a slow, grinding way. You tweak a deployment to fix something urgent, forget to commit the change, and three months later you can't reproduce your own setup. A node dies and you're reverse-engineering what was running on it from kubectl get output and fuzzy memory. I hit that wall. The fix was GitOps, specifically ArgoCD's app-of-apps pattern. This post is about how I structured it, what I got wrong the first time, and what actually works in a homelab context where you're the only engineer and iteration speed matters. Why App-of-Apps and Not Just Helm ArgoCD has several ways to manage applications. The simplest is pointing ArgoCD at a single app manifest — done. That works fine for three apps. It doesn't scale when you have fifteen namespaces and forty-plus workloads, each with their own sync policies, health checks, and override values. The app-of-apps pattern solves this with a hierarchy:
