Argo CD vs Flux in 2026: GitOps After Argo CD 3.5 and Flux 2.9

Every few months someone asks me which GitOps tool they should pick, and every time I give the same unsatisfying answer: it depends less on the tools than on how many clusters you run and who has to look at them. That answer has held up through 2026, but the details under it moved. Argo CD shipped five minor releases since 3.0 and changed its defaults for tracking, RBAC and Helm. Flux survived the end of the company that created it and is now shipping on a steady cadence with a maintainer list that looks very different from 2023. This post covers GitOps in 2026 as it stands: what the OpenGitOps principles actually require, what changed in Argo CD vs Flux, what the adoption numbers say, how each handles multi-cluster and secrets, and when GitOps is the wrong tool.

What is GitOps in 2026? The four OpenGitOps principles

GitOps has a written definition, which helps when vendors stretch the word. The CNCF's OpenGitOps v1.0.0 principles list four requirements: desired state is declarative, it is versioned and immutable (stored with full history, not edited in place), it is pulled automatically by software agents, and it is continuously reconciled against the live system.

The last two are where most "GitOps" pipelines quietly fail the test. A CI job that runs kubectl apply after a merge is declarative and versioned, but it pushes rather than pulls, and nothing notices when someone edits a Deployment by hand at 2am. That is useful automation, but it isn't GitOps. Both Argo CD and Flux meet all four principles out of the box: a controller inside the cluster (or a hub) pulls from Git, OCI or Helm repositories, compares rendered manifests with what is running, and corrects or reports the difference.

Git is also no longer the only source: Flux has long treated OCI artifacts as first-class, and Argo CD added OCI support as a beta in 3.1 in August 2025.

Argo CD 3.x: what changed from 3.0 to 3.5

Argo CD 3.0 landed on 6 May 2025 and was mostly a release of changed defaults rather than new features. The 2.14 to 3.0 upgrade guide is worth reading even if you upgraded long ago, because these defaults now shape every install:

• Resource tracking moved from labels to annotations by default.
• update and delete permissions on an Application no longer cascade to its child resources; you grant update/* or delete/* explicitly.
• Reading logs needs an explicit logs, get permission.
• Repositories configured in argocd-cm are gone; repository config lives in Secrets.
• A default set of resource.exclusions (Endpoints, EndpointSlices, Leases and similar high-churn kinds) ships enabled.

Since then the project has kept to its quarterly cadence, with GA releases roughly in February, May, August and November, and patches only for the three most recent minors. 3.1 brought OCI sources and more work on the Source Hydrator, 3.2 arrived on 4 November 2025, and 3.3 (February 2026) came with a warning that anyone running Argo CD to manage Argo CD must enable ServerSideApply=true on that Application for the upgrade to succeed. Argo CD 3.5.0 shipped on 4 August 2026 and the current patch is v3.5.5 from 12 October. The 3.4 to 3.5 upgrade notes contain the change most teams will feel: Argo CD now bundles Helm 4.2.x, spec.source.helm.version: v3 is ignored, and every chart renders with Helm 4. The same release replaces GnuPG commit verification with a broader Source Integrity feature and extends sync impersonation to all API server operations. 3.6 is in release candidates with GA scheduled for 3 November 2026.

Read in a row, the direction is fewer implicit permissions, more server-side apply, and rendering manifests ahead of time (the Source Hydrator commits rendered output back to Git).

Flux 2.x after Weaveworks: who maintains it now?

Weaveworks, the company that created Flux and popularised the term GitOps, shut down in February 2024 after failing to raise funding; The New Stack covered the closure when CEO Alexis Richardson announced it. The question was whether Flux, a CNCF graduated project since November 2022, would survive.

It did. In March 2024 the project announced new corporate support, with ControlPlane hiring maintainers Stefan Prodan and Soulé Ba and several firms offering commercial support. ControlPlane funds the work partly through an enterprise distribution built around the Flux Operator, which is open source under AGPL-3.0 (Flux itself is Apache-2.0). The CORE-MAINTAINERS file today lists nine people: three at ControlPlane, three independent, and one each at NexHealth, SUSE and Associmates. Healthier than one startup, though ControlPlane is clearly the centre of gravity.

The release record is the better evidence. Flux has shipped a minor release roughly every four to eight months: 2.6 in May 2025, 2.7 in September 2025, 2.8 in February 2026 with Helm v4 support and server-side apply for HelmReleases, and 2.9 on 30 June 2026 with a CLI plugin system, SSA field-ignore rules for drift control, SOPS decryption with age's post-quantum cipher, workload identity auth for OpenBao and Vault, and OIDC-secured webhook receivers that need no shared secret. The latest patch is v2.9.6 from 1 October 2026. Flux supports only the three newest Kubernetes minors (1.34 to 1.36 for 2.9), which is stricter than Argo CD and worth knowing if your clusters lag.

The one casualty was Weave GitOps, the dashboard. Flux still has no first-party UI in the core project; the Flux Operator now ships a web UI with a workload dashboard, per the 2.9 announcement.

Argo CD vs Flux: what the adoption numbers say

The best primary data comes from CNCF. Its 2025 Argo CD end-user survey, published 24 July 2025, found Argo CD running in nearly 60% of respondents' Kubernetes clusters used for application delivery, 97% of respondents using it in production (up from 93% in 2023), 42% managing more than 500 applications per instance (up from 15%), and 25% connecting a single instance to more than 20 clusters. It surveys Argo CD users, so it measures depth, not market share.

The broader CNCF Annual Cloud Native Survey, released 20 January 2026, found 58% of "cloud native innovators" use GitOps principles extensively against 23% of "adopters". I could not find a 2025 or 2026 CNCF figure for Flux's share specifically. Octopus Deploy's 2025 State of GitOps report was reported to put Argo CD at about half of GitOps users and Flux at 11%, but I could not read the primary report, so treat that as secondhand. GitHub stars are a crude proxy, but the gap is consistent with the surveys: argoproj/argo-cd has about 24,400 and fluxcd/flux2 about 8,500 as of today.

Argo CD vs Flux side by side in 2026

The architectural difference has not changed in years, and it still drives the decision. Argo CD is an application: an API server, a web UI, a repo server that renders manifests, and an application controller, usually running in one place and managing many clusters. Flux is a set of independent controllers (source, kustomize, helm, notification, image automation) that you typically run in every cluster, each pulling its own configuration.

	Argo CD	Flux
Current release	3.5.5, 3.6 GA planned 3 Nov 2026	2.9.6
Release rhythm	Quarterly, 3 minors supported (docs)	2 to 3 minors a year (releases)
Kubernetes tested	1.33 to 1.36 for 3.5 (install docs)	1.34 to 1.36 for 2.9 (release notes)
Helm	Templated to manifests, Helm 4.2.x bundled since 3.5	Native helm install/upgrade via helm-controller, Helm v4 since 2.8
Default topology	Hub managing many clusters	Controllers per cluster
UI	Built in, the main reason many teams pick it	Flux Operator web UI (AGPL), or third party
Multi-tenancy	AppProjects plus Argo CD RBAC and SSO	Kubernetes RBAC and service account impersonation
Secrets stance	Populate on the destination cluster; generation-time injection discouraged (docs)	Native SOPS decryption in kustomize-controller (docs)
Governance	CNCF graduated (Dec 2022)	CNCF graduated (Nov 2022), 9 core maintainers: 3 at ControlPlane, 3 independent, 3 at other firms

The Helm row trips people up. Argo CD renders a chart with helm template and applies the output as plain manifests, mapping Helm hooks onto its own sync hooks, so helm list shows nothing. Flux runs real Helm releases, so helm history works and rollbacks are Helm rollbacks.

Here is the same idea in Flux terms: a Git source and a Kustomization that prunes, decrypts SOPS secrets, and waits for health. The Argo CD equivalent is an Application with automated sync, which the step-by-step Argo CD setup guide covers.

# Flux 2.9: pull a repo every minute and reconcile ./apps/prod every 10 minutes
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: platform
  namespace: flux-system
spec:
  interval: 1m
  url: https://github.com/example-org/platform
  ref:
    branch: main
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: apps-prod
  namespace: flux-system
spec:
  interval: 10m          # full drift correction, even with no new commits
  path: ./apps/prod
  prune: true            # delete what was removed from Git
  wait: true             # mark Ready only when resources are healthy
  timeout: 5m
  sourceRef:
    kind: GitRepository
    name: platform
  decryption:
    provider: sops       # the only supported provider
    secretRef:
      name: sops-age     # Secret with a key ending in .agekey

Multi-cluster GitOps: hub-and-spoke or an agent in every cluster?

This is the question that usually decides it. Argo CD's natural shape is a hub: one control plane holds credentials for every target cluster and pushes rendered state to them over the Kubernetes API, with ApplicationSet's cluster generator stamping out one Application per registered cluster. You get one UI for everything, and a hub that holds admin-level credentials to your whole fleet and must reach every API server.

The Argo project's answer is argocd-agent, which puts a lightweight agent in each workload cluster and keeps the UI centralised. It is still in argoproj-labs and at v0.10.0 (August 2026), so I would pilot it rather than bet a fleet on it today.

Flux's default is already the agent model: each cluster runs its own controllers and pulls its own path from Git, and no central system holds cluster credentials. You give up the single pane of glass. For edge or air-gapped fleets this is the simpler design; 2.9 even added custom Sigstore trusted roots for verifying OCI artifacts offline.

The survey's 25% connecting one instance to 20+ clusters shows the hub model works. It concentrates risk, so run that hub like the most sensitive system you have.

How should you handle secrets in GitOps?

Past the obvious (no plaintext in Git), the two projects take different positions.

Argo CD's secret management docs strongly recommend populating secrets on the destination cluster with something like External Secrets Operator, Sealed Secrets or the Secrets Store CSI Driver, so Argo CD never sees the values. They explicitly caution against generation-time injection such as argocd-vault-plugin: rendered manifests are cached in Redis in plaintext, secret changes get coupled to unrelated syncs, and the approach conflicts with the rendered-manifests pattern the project is moving towards. If you still run the vault plugin, that is your migration signal. Our External Secrets Operator with Vault guide walks through the replacement.

Flux is comfortable with encrypted secrets in Git because kustomize-controller decrypts SOPS-encrypted manifests at apply time, with keys from age, OpenPGP, Vault or a cloud KMS bound to the controller's identity. That is a real convenience for small teams. The trade-off is key management: whoever holds the age key can decrypt your history forever, so rotate and scope it like any other root credential. External Secrets Operator works equally well with Flux, and on larger estates I prefer it for both tools because it keeps secret lifecycle out of the deploy pipeline.

When does GitOps hurt?

GitOps solves drift and auditability. It costs you indirection, and in some places that cost is higher than the benefit.

Fast-changing operational values. Replica counts under an autoscaler, feature-flag state, and certificate rotations do not belong in Git. If you track them, the controller fights the HPA or the operator. Argo CD's ignoreDifferences and Flux 2.9's SSA field-ignore rules exist for this, but each one is a small hole in the "Git is the truth" story that someone has to remember.

Rollback is a commit, not a button. Argo CD's auto-sync docs are explicit that rollback is not possible while automated sync is enabled. In an incident, the fastest path is often git revert and waiting for a reconcile, which is fine when the pipeline is quick and painful when CI takes 20 minutes. Progressive delivery helps here; see canary deployments with Argo Rollouts.

Ordering and one-off tasks. Database migrations, data backfills and "run this once" jobs fit awkwardly into a model built around desired state. Sync waves and hooks work, but they turn deployment logic into annotations scattered across manifests.

Small, static estates. One cluster, three services, one team: a CI job running helm upgrade may be enough. GitOps pays off as clusters, teams or auditors multiply.

Agents opening the pull requests. This is the 2026 twist. When coding agents author infrastructure changes, a GitOps repo becomes an attractive control point: every change is a reviewable diff, and the reconciler, not the agent, holds cluster credentials. That only works if branch protection and review are real, which, as CI/CD in 2026 found, often isn't the case. GitOps makes the merge button the deploy button. Guard it accordingly.

FAQ

Is Flux still maintained after Weaveworks shut down?

Yes. Flux 2.9.0 shipped on 30 June 2026 and 2.9.6 on 1 October 2026. Nine core maintainers are listed, three of them at ControlPlane, which hired key maintainers after Weaveworks closed in February 2024.

Is Argo CD better than Flux?

Neither is better in general. Argo CD is the more widely adopted choice and wins when you want a central UI and one place to manage many clusters. Flux wins when you want a per-cluster pull model, native Helm releases, or built-in SOPS decryption with no extra components.

Can I use Argo CD and Flux together?

You can, and some teams use Flux to bootstrap cluster add-ons and Argo CD for application teams. Keep them on strictly separate resources, though: two reconcilers owning the same object will fight, and Argo CD's FailOnSharedResource=true sync option helps catch overlaps.

What are the four GitOps principles?

OpenGitOps v1.0.0 defines them as declarative desired state, versioned and immutable storage, automatic pulling by software agents, and continuous reconciliation. A push-based CI deploy without drift detection meets the first two but not the last two.

If I were choosing this quarter, I would pick Argo CD for a platform team serving many application teams, because the UI and AppProjects do real work there, and Flux for edge fleets or a small team that lives in the terminal. Either way I would do three things before adding features: move off any generation-time secret plugin, read the 3.5 Helm 4 notes (or Flux 2.8's) and test charts against Helm 4 before upgrading, and make sure the Git repository has the branch protection a production deploy button deserves. The tools are mature; the discipline around them is where outages start.

Related: Infrastructure as Code in 2026, Kubernetes as the Agent Control Plane in 2026 and DevOps Still Matters in 2026.