# GitOps with ArgoCD and Flux CD Explained > Implement GitOps for Kubernetes using ArgoCD and Flux CD — where Git is the single source of truth. Compare both tools with real manifests and automated image update examples. URL: https://www.matthewswong.com/en/blog/gitops-argocd-flux/ - Author: Matthews Wong (https://www.matthewswong.com/en/about/) - Published: 2024-10-30 - Updated: 2024-10-30 - Category: DevOps GitOps with ArgoCD and Flux CD represents one of the most significant shifts in Kubernetes delivery practices. The core idea is elegant: your Git repository is the single source of truth for the desired state of your cluster. Any change — whether a new deployment, a config map update, or a Helm chart version bump — goes through a pull request, gets reviewed, and is automatically applied to the cluster. No more kubectl apply from a local machine. ## What is GitOps and Why It Matters GitOps is a set of practices where the entire system state is versioned in Git and an automated operator continuously reconciles the cluster to match it. The four principles defined by OpenGitOps are: declarative configuration, versioned and immutable state, pulled automatically (the cluster pulls from Git, not CI pushes to the cluster), and continuously reconciled. This approach eliminates configuration drift, makes rollbacks as simple as reverting a commit, and creates a full audit trail of every infrastructure change. ### ArgoCD: UI-first GitOps for Kubernetes ArgoCD is a pull-based continuous delivery tool that runs inside your Kubernetes cluster and watches Git repositories for changes. It ships with a rich web UI and CLI that show you exactly which resources are in sync and which have drifted from the desired state. ArgoCD supports Helm, Kustomize, jsonnet, and plain YAML — making it adaptable to any repo structure. ## Flux CD: The CNCF-Graduated Alternative Flux CD takes a more GitOps-native approach: instead of a monolithic operator, it's a collection of Kubernetes controllers — the source controller, kustomize controller, helm controller, notification controller, and image automation controller. Each controller watches its own custom resource and reconciles independently. Flux integrates tightly with Kustomize and supports multi-tenancy through namespace isolation. ### Flux GitRepository and Kustomization Resources In Flux, you define a GitRepository resource that points to your config repo and specifies a polling interval. The Kustomization resource then references that GitRepository, specifies the path to apply, and declares health checks. Flux will continuously sync the cluster to match the manifests in that path, pruning resources that are removed from Git. ## Automated Image Updates Both ArgoCD and Flux support automated image tag updates — a critical feature for teams that want fully automated delivery. When a new container image is pushed to a registry, the image automation controller updates the image tag in your Git config repo, which triggers a sync and deploys the new version. This creates a complete, Git-driven delivery loop without any manual steps. ### Flux Image Updater Configuration Flux's image automation controllers use two resources: an ImageRepository that polls a container registry on an interval, and an ImagePolicy that selects which tags to promote based on semver ranges, alphabetical ordering, or regex patterns. A third resource, ImageUpdateAutomation, commits the updated tag back to Git — completing the loop. > Use separate Git repositories for application code and Kubernetes configuration (the 'app-of-apps' pattern in ArgoCD, or separate source repos in Flux). This prevents your CD system from triggering itself when it commits an image tag update back to the config repo. > **Beware of Auto-Sync on Production Clusters** > Enabling automated sync with selfHeal and prune on production is powerful but risky. Any accidental Git commit (wrong file, merge conflict resolution, automated PR merge) will immediately change production. Many teams enable auto-sync only for staging and require a manual sync approval step for production using ArgoCD's sync windows or Flux's Kustomization suspend feature. ## ArgoCD vs Flux: Which Should You Choose? ArgoCD is the better choice if you want a rich UI, RBAC-controlled multi-cluster management, and a single-pane-of-glass view of all your applications. Flux is the better choice if you prefer a lightweight, controller-based approach that fits naturally into existing Kubernetes tooling, or if you need strong multi-tenancy and GitOps automation at scale. Both are CNCF projects with strong communities — the 'best' choice depends on your team's preferences. ## GitOps Terminology Explained To get started with GitOps in production: begin with a single non-critical application, use Kustomize overlays to manage environment differences, set up Slack notifications for sync events and health status changes, and implement branch protection on your config repo so all changes require a PR review. Gradually expand GitOps to cover your entire cluster as your team builds confidence in the workflow. ## Source links - https://argo-cd.readthedocs.io/en/stable/ - https://fluxcd.io/docs/ - https://opengitops.dev/ ## FAQ ### What is the core principle of GitOps, and how do ArgoCD and Flux enforce it? GitOps treats your Git repository as the single source of truth for the desired state of your cluster. Both ArgoCD and Flux use a pull-based model — the cluster pulls changes from Git rather than CI pushing to the cluster — and continuously reconcile the live state to match what is declared in Git, eliminating configuration drift. ### What is the main architectural difference between ArgoCD and Flux CD? ArgoCD is a monolithic operator with a rich web UI and CLI that gives a single-pane-of-glass view of all applications. Flux is a collection of independent Kubernetes controllers (source, kustomize, helm, notification, and image automation controllers), each managing its own custom resource, which makes it lighter-weight and more composable with existing Kubernetes tooling. ### How does automated image tag updating work in Flux, and why is a separate config repo recommended? Flux uses three resources: an ImageRepository that polls a container registry on an interval, an ImagePolicy that selects which tags to promote using semver, alphabetical, or regex rules, and an ImageUpdateAutomation that commits the updated tag back to Git to trigger a sync. A separate Git repository for application code and Kubernetes configuration is recommended to prevent the CD system from triggering itself when it commits an image tag update back to the config repo. ### Why should teams be cautious about enabling auto-sync with selfHeal and prune on production clusters? With selfHeal and prune enabled, any accidental Git commit — a wrong file, a merge conflict resolution, or an automated PR merge — will immediately change production. The post recommends enabling auto-sync only for staging and requiring a manual sync approval for production using ArgoCD sync windows or Flux's Kustomization suspend feature. ### When should you choose ArgoCD over Flux, and vice versa? ArgoCD is the better fit when your team wants a rich UI, RBAC-controlled multi-cluster management, and a unified view of all applications. Flux is preferable when you need a lightweight controller-based approach that integrates naturally with existing Kubernetes tooling, or when strong multi-tenancy through namespace isolation is a priority. Both are CNCF projects with strong communities, so the final choice depends on team preference. --- - HTML version: https://www.matthewswong.com/en/blog/gitops-argocd-flux/ - Bahasa Indonesia: https://www.matthewswong.com/id/blog/gitops-argocd-flux/ - Site index for agents: https://www.matthewswong.com/llms.txt - Sitemap: https://www.matthewswong.com/sitemap.xml - API description (OpenAPI): https://www.matthewswong.com/openapi.json