The CNCF (Cloud Native Computing Foundation) recently accepted Argo into its incubation stage — and while the formal announcement was back in March, the implications are really sinking in now as the ecosystem coalesces around GitOps as a standard deployment paradigm. Combined with Flux v2 reaching production readiness and the formation of the GitOps Working Group under the CNCF’s App Delivery TAG, we’re watching GitOps transition from a trendy concept to an industry standard.
What GitOps Actually Means (and Doesn’t)#
GitOps, a term coined by Weaveworks back in 2017, boils down to a deceptively simple principle: Git is the single source of truth for your infrastructure and application state. Your desired state lives in a Git repository, and an automated process continuously reconciles the actual state of your system with what’s declared in Git.
This sounds obvious, and many teams think they’re already doing GitOps because they store their Kubernetes manifests in Git and have a CI pipeline that runs kubectl apply. But there’s a crucial distinction between CI-driven deployment (push-based) and true GitOps (pull-based).
In CI-driven deployment, your CI pipeline pushes changes to your cluster. The pipeline needs cluster credentials, the deployment happens imperatively, and if someone manually changes something in the cluster, there’s no mechanism to detect or correct the drift.
In a GitOps model, an agent inside the cluster (ArgoCD, Flux) continuously watches the Git repository and pulls changes. If the cluster state drifts from what’s in Git — whether through manual changes, failed deployments, or infrastructure issues — the agent automatically reconciles back to the desired state. This is the fundamental shift: from “deploy and hope” to “declare and converge.”
ArgoCD: Why It’s Winning Hearts#
I’ve been running ArgoCD in production for about eight months now, and it’s earned every bit of its growing popularity. The project has over 7,000 GitHub stars and is used in production by organizations ranging from startups to enterprises like Intuit (where the Argo project originated).
What makes ArgoCD compelling:
The UI is genuinely useful. Unlike many Kubernetes tools where the dashboard is an afterthought, ArgoCD’s web interface provides real-time visualization of your application’s resource tree, sync status, and health. When a deployment goes wrong, you can see exactly which resource failed and why, without switching to a terminal.
Multi-cluster management works well. We manage four clusters through a single ArgoCD instance, and the experience is clean. Each application declares its target cluster, and ArgoCD handles the rest. This is invaluable for organizations running separate staging, production, and regional clusters.
The Application CRD model is elegant. You define an ArgoCD Application that points to a Git repository path and a target cluster/namespace. That’s it. ArgoCD handles sync, health checking, pruning of removed resources, and rollback. The ApplicationSet controller extends this further, allowing you to template applications across multiple clusters or environments from a single definition.
Helm and Kustomize integration is first-class. ArgoCD natively understands Helm charts and Kustomize overlays, which means you don’t have to pre-render your templates in CI. It renders at sync time, so the Git repository contains the actual source templates rather than rendered output.
Flux v2: The Composable Alternative#
While ArgoCD takes a monolithic approach (one tool that does everything), Flux v2 takes a deliberately composable approach built on a set of specialized controllers:
- Source Controller watches Git repos, Helm repos, and S3 buckets
- Kustomize Controller handles Kustomize-based reconciliation
- Helm Controller manages Helm releases
- Notification Controller handles alerts and webhooks
- Image Automation Controllers can automatically update image tags in Git
This composability means you can use only the pieces you need. If you’re pure Kustomize, you don’t need the Helm controller. If you want automated image updates (a controversial feature that ArgoCD deliberately doesn’t include by default), Flux has purpose-built controllers for it.
Flux v2 is also built entirely on Kubernetes APIs using custom resources, which means standard Kubernetes tooling (kubectl, RBAC, audit logs) works naturally with it. There’s no separate API server or UI to manage — it’s Kubernetes-native through and through.
The GitOps Working Group and Standardization#
Perhaps the most consequential development is the GitOps Working Group effort to create a vendor-neutral definition and set of principles for GitOps. The working group includes contributors from Weaveworks (Flux), Intuit/Codefresh (Argo), Microsoft, AWS, and others.
Having a shared definition matters because “GitOps” has become a marketing term that gets slapped on anything involving Git and deployment. A formal set of principles helps the community distinguish genuine GitOps implementations from CI/CD pipelines with a Git trigger.
The draft principles emphasize four key aspects: declarative desired state, versioned and immutable state in Git, automated agents that pull and apply changes, and continuous reconciliation with drift detection. If your deployment process doesn’t include all four, it’s not GitOps — it’s just CI/CD with Git, which is fine, but it’s a different thing.
My Take#
After running ArgoCD in production and evaluating Flux v2, my recommendation for teams getting started with GitOps is straightforward: if you want a batteries-included solution with a great UI, choose ArgoCD. If you prefer a composable, Kubernetes-native toolkit and don’t need a web interface, choose Flux. Both are excellent, both are CNCF-backed, and both will serve you well.
The more important decision is whether to adopt GitOps at all, and I’d argue that for any team running more than a handful of services on Kubernetes, the answer is yes. The benefits are substantial: auditable deployment history through Git commits, automatic drift detection and correction, easier disaster recovery (just point the agent at the Git repo), and a deployment process that doesn’t require sharing cluster credentials with your CI system.
We’re past the “early adopter” phase for GitOps. The tooling is mature, the community is vibrant, and the CNCF’s investment signals long-term sustainability. If you’re still doing imperative kubectl apply from CI pipelines, now is a good time to make the switch.