I run a homelab cluster from a single self-hosted Git repository. One directory contains all of my deployments, including plain Kubernetes YAML manifests and Helm values files. Argo CD is installed, but I have not set it up extensively yet. I was considering the App of Apps pattern to manage everything, though the configuration already feels more complicated than the workloads themselves.
I also came across Keel, a lightweight controller that watches container registries and updates deployments when newer images are available. It is not really GitOps, but my main goal is to deploy new images automatically, so it seems like it could be a simpler fit.
For a setup this small, is there a simpler way to configure Argo CD than App of Apps? Would it make sense to use Argo CD for syncing manifests and Keel for image updates, or would that create unnecessary complexity? I am also interested in experiences and potential problems with running Keel in a homelab.
5 Answers
The App of Apps pattern is not inherently too much, even for a small cluster. It provides a useful overview, clear ownership of components, straightforward rollbacks, and a convenient way to see when something is unhealthy. However, for one folder and only a few workloads, a single Argo CD Application is simpler and easier to understand. I would also avoid blindly deploying every new image version; automatic updates can introduce breaking changes and turn a hobby cluster into constant troubleshooting.
If automatic image updates are the only goal, you may not need a separate controller at all. Keep image tags or digests in the repository and update them periodically, either manually or with a tool designed for Git-based image automation. For a small homelab, explicit updates tied to commits are often less surprising than deploying every registry change immediately.
Using both controllers would probably add more moving parts than you need. For a single folder, a straightforward Argo CD application pointing at that path may be enough; you do not need App of Apps unless you want to manage a collection of separate applications. Flux is another relatively lightweight option, especially if you mainly need Git-based reconciliation and can live without Argo CD's UI.
Argo CD works fine for a homelab, and you can keep the repository organized with one directory per application or component. Each directory can contain its values file, manifests, and a kustomization if needed. A top-level Argo application can point at the relevant directories, while image versions are changed in Git and synced normally. That keeps the desired state visible and reproducible.
A common hybrid layout is a kustomization per application that references a Helm chart and its values file, with extra manifests or patches beside it when the chart does not expose something you need.
I would be cautious about choosing Keel. It has had maintenance and image-version detection problems, including cases where updates stopped working or a manually changed version was later reverted. Some users have moved away from it because of that behavior. A maintained GitOps tool such as Argo CD or Flux is safer if reliability and traceable changes matter.
A simple Kustomization can also cover this setup. It gives you a clean entry point for both raw manifests and Helm-based resources without introducing an application hierarchy.