{"slug": "gitops-explained-how-it-works-argocd-vs-flux-and-when-to-use-it", "title": "GitOps Explained: How It Works, ArgoCD vs Flux, and When to Use It", "summary": "GitOps is a method for operating infrastructure and applications using Git as the single source of truth, with automated agents reconciling actual system state to match the desired state defined in Git. The approach, coined by Weaveworks in 2017, relies on four principles: declarative configuration, versioned and immutable state, automatic pulling of changes, and continuous reconciliation. ArgoCD and Flux are the primary tools implementing GitOps for Kubernetes, with ArgoCD being the most widely adopted.", "body_md": "GitOps is a way of operating infrastructure and applications where Git is the single source of truth for what should be running, and an automated agent continuously reconciles the actual state of the system to match it. The term was coined by Weaveworks in 2017, but the underlying idea — declarative desired state, version control, automated reconciliation — predates it. What GitOps added was a specific set of practices and a set of tools that made the pattern practical for Kubernetes.\n\nThis guide covers what GitOps actually means (not just the marketing definition), how the reconciliation loop works, how ArgoCD and Flux compare, and where GitOps genuinely helps versus where it adds unnecessary complexity.\n\nThe OpenGitOps project (a CNCF working group) defines GitOps around four principles:\n\n**1. Declarative.** The desired state of the entire system is expressed declaratively. This means Kubernetes YAML manifests, Helm chart values, Kustomize overlays — not imperative scripts. \"Apply these manifests\" rather than \"run these commands.\" The advantage: the desired state can be stored, diffed, and audited.\n\n**2. Versioned and immutable.** The desired state is stored in a versioning system (Git) that enforces immutability of history. Every change has a timestamp, an author, and a hash. Rollback means reverting a commit. Audit means reading the commit log. You always know what changed, when, and who approved it.\n\n**3. Pulled automatically.** Approved changes are automatically applied to the system. The GitOps agent inside the cluster watches the Git repository and pulls changes — the cluster initiates the connection, not external systems. This is a security advantage: you don't need to give CI/CD systems credentials to access the cluster. The cluster's outbound network needs to reach Git; nothing external needs inbound access to the API server.\n\n**4. Continuously reconciled.** Software agents continuously compare actual state with desired state and automatically correct any divergence. If someone manually changes a Kubernetes resource (kubectl edit), the GitOps agent detects the drift and reverts it. This is the enforcement mechanism.\n\nA GitOps controller runs inside the cluster. It watches one or more Git repositories (or OCI registries) and continuously runs a control loop:\n\nThis pull-based model contrasts with the push-based model used by traditional CI/CD pipelines. In push-based deployments, a pipeline runs after a merge and pushes changes to the cluster via `kubectl apply`\n\nor Helm. In pull-based GitOps, the cluster continuously checks whether it matches Git and corrects itself.\n\n```\n# Push-based CI/CD (traditional)\n# Pipeline runs:\nkubectl apply -f manifests/\n# Cluster state = whatever kubectl apply did\n\n# GitOps (pull-based)\n# GitOps controller runs in cluster, continuously:\n# 1. Reads desired state from git\n# 2. Compares to actual cluster state\n# 3. Applies the diff\n# Cluster state = what's in Git (enforced, not just applied once)\n```\n\nGitOps works best when the application code repository and the deployment configuration repository are separate. This \"app repo + config repo\" pattern is the most common structure:\n\n```\n# Config repo structure (example)\nclusters/\nproduction/\nnamespaces/\napi/\ndeployment.yaml\nservice.yaml\nhpa.yaml\ndatabase/\nstatefulset.yaml\nservice.yaml\nstaging/\nnamespaces/\napi/\ndeployment.yaml  # different image tag, lower resource requests\ndatabase/\nstatefulset.yaml\n```\n\nSome teams keep everything in one repo using directory structure or branch strategy to separate environments. Others use separate repos per environment or per cluster. There's no single right structure — the key is that everything that defines cluster state lives in version control.\n\nArgoCD is the most widely adopted GitOps tool. It runs as a set of controllers in the cluster and exposes a web UI and CLI. The core concept is an **Application** resource that maps a Git repository path to a Kubernetes namespace:\n\n```\napiVersion: argoproj.io/v1alpha1\nkind: Application\nmetadata:\nname: api-production\nnamespace: argocd\nspec:\nproject: default\nsource:\nrepoURL: https://github.com/mycompany/config-repo\ntargetRevision: main\npath: clusters/production/namespaces/api\ndestination:\nserver: https://kubernetes.default.svc\nnamespace: api\nsyncPolicy:\nautomated:\nprune: true      # delete resources removed from git\nselfHeal: true   # revert manual changes\nsyncOptions:\n- CreateNamespace=true\n```\n\nArgoCD's web UI shows the sync status of every Application — green (in sync), yellow (out of sync), red (degraded). Out-of-sync resources show exactly what differs between the cluster and Git. This visual diff is one of ArgoCD's most valued features for operators who want to understand deployment state at a glance.\n\nArgoCD uses an **app of apps** pattern for managing many Applications: a root Application points to a directory of Application manifests, which ArgoCD then deploys. This bootstraps an entire cluster from a single ArgoCD Application.\n\nArgoCD natively supports Helm charts and Kustomize overlays. You can point an Application at a Helm chart in a Git repo or a remote Helm repository, and specify values files or inline value overrides. Kustomize overlays let you maintain a base configuration and layer environment-specific patches on top.\n\nFlux takes a more composable, Kubernetes-native approach. Instead of a single Application CRD, Flux uses several specialized CRDs that each handle a specific concern:\n\n```\n# Flux GitRepository\napiVersion: source.toolkit.fluxcd.io/v1\nkind: GitRepository\nmetadata:\nname: config-repo\nnamespace: flux-system\nspec:\ninterval: 1m\nurl: https://github.com/mycompany/config-repo\nref:\nbranch: main\n\n# Flux Kustomization\napiVersion: kustomize.toolkit.fluxcd.io/v1\nkind: Kustomization\nmetadata:\nname: api-production\nnamespace: flux-system\nspec:\ninterval: 5m\nsourceRef:\nkind: GitRepository\nname: config-repo\npath: ./clusters/production/namespaces/api\nprune: true\ntargetNamespace: api\n```\n\nFlux doesn't have a built-in web UI in the same way ArgoCD does. It's managed primarily via CLI (`flux`\n\n) and manifests. This makes it feel more \"GitOps-native\" to some practitioners — Flux's own configuration lives entirely in Git, managed by Flux itself.\n\nBoth tools are mature, widely used, and maintained by strong communities. The choice usually comes down to UI preferences and composition model:\n\n**Choose ArgoCD if**: your team values a visual dashboard for deployment status, you want a unified view across many clusters, or you're adopting GitOps for the first time and want a guided UI to understand what's happening.\n\n**Choose Flux if**: you prefer a Kubernetes-native composable model, you want to manage Flux's own configuration via GitOps, or you need the image automation features (automatic image tag updates) that Flux provides out of the box.\n\nBoth support multi-cluster deployments, RBAC, SSO integration, Helm, and Kustomize. Both are CNCF graduated projects. Switching between them is possible but non-trivial — once a team is invested in ArgoCD's Application CRDs or Flux's source controller patterns, migrating means rewriting deployment configuration.\n\nGitOps genuinely helps in these situations:\n\n**Multi-environment management.** When you have dev, staging, and production environments and want changes to flow through them consistently. GitOps makes the progression explicit — a PR to update staging, review, then a PR to update production.\n\n**Regulatory compliance and audit requirements.** Every change is a Git commit with an author and timestamp. Audit trails are the commit log. Change approval is the PR review process. This maps naturally to SOC 2, ISO 27001, and similar requirements.\n\n**Preventing configuration drift.** Without GitOps, someone inevitably makes a kubectl change that isn't reflected anywhere, and six months later nobody knows why that resource is configured differently from what the manifests say. Continuous reconciliation closes this gap.\n\n**Large teams.** When multiple teams deploy to shared clusters, GitOps provides a structured review process via PRs rather than direct cluster access. Cluster operators review and merge config changes; they don't need to trust every team to run kubectl correctly.\n\nGitOps isn't always the right choice:\n\n**Small teams or solo projects.** A two-person team doesn't need the overhead of maintaining separate config repos and GitOps controllers. A simple CI pipeline that runs `helm upgrade`\n\nafter merge is easier to understand and maintain.\n\n**Stateful workloads with complex upgrade procedures.** Database migrations, multi-step upgrades, or operations that require ordering guarantees don't fit well into declarative reconciliation. GitOps handles stateless workloads well; it's awkward for operations that need imperative steps.\n\n**Early-stage applications with rapidly changing infrastructure.** If your deployment configuration changes multiple times per day, the PR review process becomes a bottleneck. GitOps adds value when the review gate is valuable; it adds friction when fast iteration matters more.\n\nA common pattern: use Terraform to provision the cluster (EKS, GKE, AKS), then bootstrap GitOps with a single apply command that hands off further configuration to the GitOps controller.\n\n```\n# Bootstrap Flux onto a new cluster\nflux bootstrap github \\\n--owner=mycompany \\\n--repository=config-repo \\\n--branch=main \\\n--path=clusters/production \\\n--personal=false\n\n# After this, everything in clusters/production/ is managed by Flux\n# Including Flux's own configuration\n```\n\nAfter bootstrap, even adding new namespaces, installing cluster addons (cert-manager, external-dns, ingress-nginx), or configuring RBAC happens through Git commits rather than direct cluster commands.", "url": "https://wpnews.pro/news/gitops-explained-how-it-works-argocd-vs-flux-and-when-to-use-it", "canonical_source": "https://dev.to/pandey-raghvendra/gitops-explained-how-it-works-argocd-vs-flux-and-when-to-use-it-12ke", "published_at": "2026-06-20 11:10:44+00:00", "updated_at": "2026-06-20 11:36:44.403964+00:00", "lang": "en", "topics": ["developer-tools", "machine-learning", "large-language-models"], "entities": ["Weaveworks", "ArgoCD", "Flux", "Kubernetes", "OpenGitOps", "CNCF"], "alternates": {"html": "https://wpnews.pro/news/gitops-explained-how-it-works-argocd-vs-flux-and-when-to-use-it", "markdown": "https://wpnews.pro/news/gitops-explained-how-it-works-argocd-vs-flux-and-when-to-use-it.md", "text": "https://wpnews.pro/news/gitops-explained-how-it-works-argocd-vs-flux-and-when-to-use-it.txt", "jsonld": "https://wpnews.pro/news/gitops-explained-how-it-works-argocd-vs-flux-and-when-to-use-it.jsonld"}}