Dora NodaArgo CD has roughly 23,100 GitHub stars. Flux has about 8,180. One March 2026 analysis put their GitOps market shares at 60% against 11%. Those numbers look like a blowout, and they get quoted like one — but they do not say what most people think they say. Both projects are CNCF Graduated, both shipped steadily through 2026 (Argo CD v3.4.3 in late May, Flux v2.8.8 the same month, with Flux already on to v2.9.x by late summer), and both run production fleets you would recognize. The split is not maturity. It is architecture: Argo CD is a centralized application platform with a hub-and-spoke console, and Flux is a set of decentralized per-cluster controllers with no server of its own. Pick the wrong shape for your fleet and you will feel it every day; pick the right one and the star count will never cross your mind again.
This post settles it for one specific reader: a team reconciling a Cluster-API-managed fleet's Cluster and MachineDeployment manifests on machines it owns. The scoreboard, the architecture table, and the decision rule are all below — the rule first, the reasoning after.
The decision rule, up front
If operators need one console showing every cluster, every app, and every drift — GitOps-as-a-service for many app teams — Argo CD's heavier control plane earns its footprint. If the platform already centralizes fleet state through its own control-plane API and each cluster can reconcile itself, Flux's smaller, per-cluster footprint is the better fit. And if you run both against the same namespaces, they will fight over resources instead of managing them — pick one per cluster and commit.
| Concern | Argo CD (v3.4.x) | Flux (v2.8/2.9.x) |
|---|---|---|
| Control plane | API server, repo-server, application controller, ApplicationSet controller, Redis | Source, kustomize, helm, notification controllers; image automation opt-in |
| Operator view | Built-in web dashboard with a live resource graph | No first-party UI; CLI-driven, Kubernetes-API-only surface |
| Multi-cluster fan-out | ApplicationSet generators (clusters, git, matrix) from one hub | One Kustomization per cluster path, or an operator, per cluster |
| Secrets in git | Plugin/extension model (no native SOPS) | Native SOPS/MOPS decryption built in |
| Image updates | External tooling or extensions | Native image-reflector + image-automation controllers |
| RBAC / attack surface | Central API server + Redis to harden and expose | Native Kubernetes RBAC, no exposed server, smaller surface |
| Sync granularity | Global sync interval | Per-resource sync intervals |
| Adoption signal | ~23,100 stars, ~60% share in 2026 analyses | ~8,180 stars, ~11% share, healthy post-Weaveworks releases |
Two footnotes before anyone screenshots the table. First, versions move fast on both sides — Argo CD is on the 3.x line and Flux on 2.9.x as of autumn 2026, so treat any version-pinned claim as a snapshot, not scripture. Second, the star gap measures mindshare, and a large part of that mindshare is the dashboard: a UI spreads virally inside engineering orgs in a way controllers never will. That does not make the dashboard free.
Where Argo CD earns its weight
Argo CD's cost is concrete: an API server, a repo-server, an application controller, an ApplicationSet controller, and Redis, all running somewhere, all needing upgrades, backups, and hardening. The 2026 comparison work is unusually honest about this — every one of those frequent 3.x releases is an upgrade you perform on a self-hosted setup. What buys that footprint back is the operator experience nothing else in the GitOps space matches.
The dashboard is the headline, but the machinery underneath it is the real argument. The in-memory resource graph gives operators a live view of every managed object and its health, and ApplicationSets turn "deploy this to every cluster matching a label" into a declarative generator instead of a scripting project. The Cluster generator in particular is the hub-and-spoke primitive: register workload clusters with the hub, write one ApplicationSet, and fan out tenant namespaces, policy agents, or fleet-wide config to all of them. Teams running the app-of-apps pattern get environment promotion and staged rollouts with sync waves and hooks — and Argo CD 3.3 closed a genuine deletion-safety gap with PreDelete hooks that block an Application's teardown until cleanup jobs (data export, traffic draining, dependent-system notification) succeed.
There is one gotcha worth knowing before you design around those hooks: they fire on explicit Application deletion, not on every removal path. Practitioners report that ApplicationSet auto-pruning does not trigger PreDelete hooks the way a direct delete does — so a tenant-teardown flow that relies on cleanup hooks must delete explicitly or it will silently skip the cleanup it was built for. That is exactly the kind of edge that bites on a platform reconciling tenant lifecycle through GitOps, and it belongs in the runbook, not in a post-incident review.
The second thing Argo CD buys is organizational: it is GitOps-as-a-service. Multi-tenancy, SSO, a console that non-cluster-admins can read — a platform team serving many app teams gets a finished product rather than a kit of controllers to wrap in its own UI. The star-count lead is downstream of this. Argo CD wins evaluations where the evaluator is a human looking at a screen.
Where Flux wins instead
Flux's pitch is everything Argo CD's control plane is not. There is no API server, no Redis, no UI server to expose and harden. Each cluster runs a small set of controllers — source, kustomize, helm, and notification by default — that reconcile that cluster's desired state from git, OCI, or Helm sources. The Kubernetes API is the only surface, which means multi-tenancy falls out of native Kubernetes RBAC instead of a second identity system, and the attack surface is roughly "the controllers you installed." For edge fleets and per-cluster autonomy, the architecture needs no justification: a cluster that reconciles itself keeps converging when the hub is unreachable, which is the entire point of decentralized reconciliation.
Three native capabilities regularly decide evaluations on the technical merits. First, SOPS-encrypted secrets work out of the box — decrypt-at-apply with no plugin plumbing, versus Argo CD's extension model for the same job. Second, image automation is a first-class citizen: the opt-in image-reflector and image-automation controllers watch registries and write updated tags back to git, a loop Argo CD users assemble from external tooling. Third, Helm and OCI support is deep and boring in the good way, including supply-chain verification hooks (Cosign/Notation) that matter once every provider and policy bundle wants provenance, not just workload images.
Then there is the question every evaluator asks and too many comparisons dodge: is Flux safe to bet on after Weaveworks shut down in February 2024? The 2026 evidence says yes, with receipts. Flux was already CNCF Graduated, so its survival never depended on one company; ControlPlane hired core maintainers including Stefan Prodan; governance is multi-vendor; and the release cadence never stalled — v2.8.0 that February, v2.8.8 in May, v2.9.x through the summer at roughly monthly rhythm. Enterprise users like Deutsche Telekom's 5G platform never left. "Nobody maintains it" is 2024 FUD; check the release page instead.
Flux's honest cost is operational, not architectural. You install, version, upgrade, and debug its controllers in every cluster, and you own its CRD migrations — picking Flux to escape Argo CD operations trades one set of controllers for another. And there is no vendor waiting to run Flux for you, while hosted Argo CD is a purchasable thing. Lighter per cluster does not mean zero to operate.
The Cluster-API fleet question
Now the actual decision this post promised: reconciling Cluster and MachineDeployment manifests on a CAPI-managed fleet. Here the two architectures map onto two genuinely different fleet shapes, and the right answer depends on which one you run.
Shape one is the hub: a management cluster that owns fleet lifecycle, with workload clusters as delivery targets. This is Argo CD's home turf. The management cluster's Argo CD registers every workload cluster, ApplicationSets fan tenant config and platform add-ons out by label, and operators watch the whole fleet's drift from one resource graph. The price — a beefy central control plane and a hub outage that blinds (though does not stop) fleet-wide delivery — is worth it when the operator team is small and the alternative is SSH-ing into N clusters to answer "what version is tenant X on."
Shape two is the self-reconciling fleet: each cluster, management or workload, runs Flux and converges itself from its own path in git. There is no hub to lose, no central API server to expose, and per-cluster RBAC stays native all the way down. This fits the platform that already centralizes fleet state through its own control-plane API — bex's shape, in other words. When your API already knows what every machine and app should look like, GitOps does not need to provide the fleet-wide view; it needs to be a reliable per-cluster convergence loop with the smallest possible footprint. That is Flux's job description.
Sensitivity check, because the honest answer varies with size: at two or three clusters, Argo CD's hub costs more than its dashboard returns, and Flux (or even one ApplicationSet-free Argo instance per cluster) is simpler. Past a dozen clusters with multiple app teams, the hub's single pane starts paying rent and Flux's per-cluster debugging multiplies. Most self-hosted PaaS fleets live between those poles — a handful of Hetzner machines, one team — which is why the per-cluster answer wins by default and the hub has to justify itself per deployment rather than being assumed.
One hard rule regardless of shape: never run both reconcilers against the same namespaces. Two controllers managing the same objects do not add redundancy; they fight — each reverting the other's writes — until someone pages. One reconciler per cluster, chosen deliberately, with the fleet-level view (if you need one) built above it, not beside it.
The verdict
The star count was never the argument; it was the symptom. Argo CD's 23,100 stars measure what happens when the best UI in GitOps meets GitOps-as-a-service for platform teams — and if you need that console, pay for the control plane gladly, because nothing in Flux's world replaces it. Flux's 8,180 stars measure what happens when the architecture is right and the marketing is a CLI — and if your platform already owns the fleet-wide view, take the smaller footprint, the native secrets and image automation, and the cluster that keeps converging when the hub is gone.
For a self-hosted, Cluster-API-based PaaS that centralizes fleet state in its own API: Flux per cluster by default, Argo CD's hub where a human-operated console earns its keep. Revisit when the fleet crosses a dozen clusters or the second app team arrives — whichever comes first.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
