GitOps lab with ArgoCD App-of-Apps

A local Kubernetes lab following the App-of-Apps pattern, running end-to-end: ArgoCD reconciles the cluster against the Git repo – including ingress, cert-manager, monitoring and a demo app, with CI building the images to GHCR.

Kubernetes ArgoCD Helm Go kind GitHub Actions Docker GHCR ingress-nginx cert-manager Grafana

View on GitHub

What it’s about

I want to understand ArgoCD’s App-of-Apps pattern not just in theory but in practice, on a realistic setup that could plausibly run in production. The lab consists of two repositories: demo-app for the application code (Go API + nginx frontend) and platform-gitops as the GitOps source of truth watched by ArgoCD.

What’s running

The stack runs end-to-end: kind create cluster → install ArgoCD → apply the root app, and ArgoCD pulls the rest from the repo itself. After that, the demo app, the ArgoCD UI and Grafana are reachable in the browser via ingress.

App-of-Apps: a root Application under clusters/local/bootstrap/ pulls in one Application per infra component (ingress-nginx, cert-manager, sealed-secrets, monitoring/Grafana) and per workload
In-repo Helm chart for the demo app – deployments, services, ingress and a NetworkPolicy, with a security context (non-root, verifiable)
CI in demo-app builds the container images (frontend + Go API) to GHCR, tagged with latest and the commit SHA; the GitOps repo references them via values.yaml
The architecture is documented in ARCHITECTURE.md

Next steps

Automated image bump: CI already builds and pushes, but the version bump in the GitOps repo is still manual – the last step towards a fully closed pipeline
Actually use sealed secrets and the monitoring dashboards in practice, not just deploy them

Why this project

GitOps promises: drift is immediately visible, rollbacks are a git revert, and nothing on the cluster gets changed by hand. Whether that discipline holds up day to day is something you only find out by building the whole setup yourself.