Argo CD vs Flux: An Enterprise Guide to Multi-Cluster GitOps

Argo CD and Flux are both mature, CNCF graduated GitOps controllers. Either can reconcile a Kubernetes estate from Git or an OCI registry. For an enterprise running clusters across environments, regions and compliance boundaries, the harder decision is not which tool has the longer feature list. It is where reconciliation runs, which side opens the network connection, and where cluster credentials are stored.

This guide is written for platform leads, architects, CTOs and security reviewers. It compares Argo CD 3.5 and Flux 2.9 as of October 2026, then sets out a reference architecture, governance controls, an operating model and a phased adoption roadmap that apply to either tool.

Executive summary

• Both tools are production-grade. The functional gap between them narrows with each release. Choose on operating model and topology before features.
• Topology matters more than the tool. Decide per trust zone whether a central control plane pushes to clusters or each cluster pulls its own state.
• Choose Argo CD when many product teams need a shared web UI, SSO-mapped permissions and fleet templating from a central control plane.
• Choose Flux when clusters must pull their own state with no inbound access and no central credential store, or when GitOps should be installed with the cluster as plain Kubernetes objects.
• Never share a control plane across trust zones. Separate production from non-production, and give regulated environments their own.

1. How GitOps reconciliation works

GitOps replaces imperative deploy scripts with a controller that continuously compares two things: the desired state in Git or an OCI registry, and the live state in the cluster. When they differ, the controller applies the difference. When someone changes the cluster by hand, the controller detects the drift and restores the approved state.

For an enterprise this matters for two reasons. The Git history becomes the change record, with an author, reviewer, timestamp and diff for every production change. And unapproved changes do not survive the next reconcile.

Self-heal is a policy decision. Argo CD reverts drift when selfHeal is enabled on an Application; Flux reverts it on its regular reconciliation interval. Both need a documented break-glass path for incidents, covered in the governance section below.

2. Argo CD and Flux in 2026

Argo CD 3.5: an application delivery platform

Argo CD runs an API server, web UI, repository server and application controller. The Application is the unit of delivery, and ApplicationSet generates Applications from cluster inventories, Git directories or pull requests.

Version 3.5, released as a candidate in June 2026, added mutual TLS between internal components, Git commit signature verification through Source Integrity, ApplicationSet management in the UI, Helm 4 support and ApplicationSets in any namespace. It also promoted impersonation and the Source Hydrator to beta. Version 3.4 added a way to register a cluster without the central controller reconciling it, which supports estates that mix a central hub with agents.

Flux 2.9: a toolkit of composable controllers

Flux is a set of controllers for sources, Kustomize, Helm, notifications and image automation, configured entirely through Kubernetes custom resources. There is no required central server.

OCI artifact support reached general availability in Flux 2.6 and image update automation in Flux 2.7. Flux 2.9, released on June 30, 2026, added a CLI plugin system and field-level ignore rules for server-side apply drift detection. The Flux Operator, maintained by ControlPlane, adds a web UI, sharding and multi-tenancy lockdown, and is available through Red Hat OperatorHub.

3. The four multi-cluster patterns

Every multi-cluster design answers three questions: which side opens the network connection, where cluster credentials are stored, and what happens to the fleet when the central cluster fails.

Argo CD hub push and Flux hub and spoke share the same risk profile: one cluster holds credentials for the fleet. The difference is operational. Argo CD provides a single UI and permission model; Flux provides plain Kubernetes objects that provisioning tools can create with the cluster, and a hub that can be sharded across several Flux instances.

The agent pattern is Argo CD's answer to the pull model. The argocd-agent project inverts the connection so that spokes connect out to a principal on the hub, authenticate with client certificates and reconcile locally. Its documentation lists high availability for the principal and full multi-tenancy as work in progress, so treat it as maturing for production use.

4. Enterprise reference architecture

The architecture below applies to either tool. It separates control planes by trust zone, keeps a single source of truth with a signed supply chain, and treats regulated environments as pull-only.

Design principles

1. Separate control planes per trust zone. Production, non-production and regulated environments never share a GitOps control plane.
2. Pull across untrusted networks. Use hub push only inside one trust zone. Across zones, clusters pull.
3. Make Git the change record. No routine kubectl in production. Exceptions follow a documented break-glass procedure.
4. Promote immutable artifacts. Production references image digests and versioned configuration, never a moving branch or a latest tag.
5. Split platform and application ownership. Platform add-ons and product workloads live in separate paths with separate owners.
6. Enforce policy at admission. CI checks are advisory. Kyverno or OPA Gatekeeper in the cluster is the control.
7. Keep secrets out of Git. Reference external stores through External Secrets Operator, or encrypt with SOPS.
8. Manage the GitOps platform as code. Bootstrap it with Terraform, upgrade it through Git, and rehearse rebuilding it.

The supply chain controls behind principle 4 are covered in the DevSecOps pipeline security guide, and the platform boundaries behind principle 5 in the internal developer platform strategy guide.

5. Repository structure and promotion

Use one branch with a folder per environment, not a branch per environment. Environment branches drift apart through cherry-picks and make it hard to see what is running where. A folder layout makes every environment's state reviewable on main, and CODEOWNERS assigns approval rights per path.

platform-config/
├── clusters/                  # what runs where, one folder per cluster
│   ├── nonprod/dev-use1/
│   ├── nonprod/stg-use1/
│   └── prod/prd-use1/  prd-euw1/
├── platform/                  # add-ons owned by the platform team
│   ├── base/                  # ingress, cert-manager, external-secrets, kyverno
│   └── overlays/nonprod/  prod/
└── apps/                      # product teams own their folders via CODEOWNERS
    └── payments/
        ├── base/
        └── overlays/dev/  staging/  prod/   # prod pins image digests

Promotion is a pull request that copies a tested digest from the staging overlay to the production overlay. CI can open that pull request automatically after staging passes; a person with production approval rights merges it. Rollout across production regions then proceeds in waves, and an unhealthy wave stops the release.

Argo CD expresses waves with ApplicationSet progressive syncs. Each RollingSync step waits for the previous step's Applications to report Healthy, and maxUpdate limits how many production clusters change at once. Progressive syncs must be enabled on the ApplicationSet controller.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: payments
  namespace: argocd
spec:
  goTemplate: true
  generators:
    - clusters:
        selector:
          matchLabels:
            fleet: payments
  strategy:
    type: RollingSync
    rollingSync:
      steps:
        - matchExpressions:
            - {key: env, operator: In, values: [staging]}
        - matchExpressions:
            - {key: env, operator: In, values: [prod]}
          maxUpdate: 25%        # one production cluster in four at a time
  template:
    metadata:
      name: 'payments-{{.name}}'
      labels:
        env: '{{index .metadata.labels "env"}}'
    spec:
      project: payments         # AppProject limits repositories and destinations
      source:
        repoURL: https://github.com/acme/platform-config
        targetRevision: main
        path: 'apps/payments/overlays/{{index .metadata.labels "env"}}'
      destination:
        server: '{{.server}}'
        namespace: payments

Flux expresses the same ordering with dependsOn between Kustomizations. Setting wait: true means a Kustomization reports Ready only when its workloads are healthy, so the next wave starts only after the previous one succeeds. In hub mode, kubeConfig points at the target cluster; in per-cluster mode it is omitted.

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: payments-prod-us-east
  namespace: flux-system
spec:
  interval: 10m
  retryInterval: 2m
  serviceAccountName: payments-deployer   # tenant RBAC
  sourceRef:
    kind: GitRepository
    name: platform-config
  path: ./apps/payments/overlays/prod
  prune: true
  wait: true
  dependsOn:
    - name: payments-staging
  kubeConfig:                             # hub mode only
    secretRef:
      name: prod-us-east-kubeconfig
  postBuild:
    substitute:
      cluster_name: prod-us-east
      region: us-east-1

For canary traffic shifting inside a single cluster, the usual companions are Argo Rollouts and Flagger. The enterprise deployment bottlenecks guide covers the approval and release practices around this flow.

6. Governance, security and compliance

GitOps gives auditors stronger evidence than pipeline-pushed deployments. Every production change is a reviewed pull request with an approver, a timestamp and a diff, and the controller records what it applied. The table maps common control objectives to the mechanism in each tool. Map the rows to your own framework, for example SOC 2 change management (CC8.1), ISO/IEC 27001:2022 control 8.32 or PCI DSS requirement 6.5.

Credential concentration is the largest security difference between patterns. A hub that stores a kubeconfig for every cluster is one breach away from the whole fleet. Per-cluster Flux and the Argo CD agent keep credentials local; prefer them for regulated or internet-exposed fleets. Our DevSecOps consulting team can map these controls to your audit scope.

7. Operating model

Most GitOps programs that stall do so on ownership rather than technology. Agree who is responsible (R), accountable (A), consulted (C) and informed (I) for each activity before the pilot starts.

The platform team's role here mirrors the product-team model described in platform engineering golden paths: templates and paved paths are the product, and product teams are the customers.

8. Adoption roadmap

A phased rollout proves the model with willing teams before it becomes mandatory. Durations are indicative for an estate of a few dozen clusters, and each phase ends only when its exit criteria are met.

9. Scale and resilience of the control plane

The GitOps control plane becomes tier-0 infrastructure. Design and operate it accordingly.

• Argo CD scaling. Use the HA installation, shard the application controller across clusters and scale repository servers for manifest rendering. Argo CD 3.5 also adds concurrency to how the ApplicationSet controller manages Applications.
• Flux scaling. Per-cluster Flux scales with the fleet by design. A Flux hub can be sharded across several instances, and the Flux Operator configures sharding and vertical scaling.
• Failure behavior. When the control plane is down, running workloads keep running; only new changes and drift correction stop. State this explicitly in your recovery objectives.
• Disaster recovery. The desired state is already in Git. Back up what is not: cluster credentials, SSO configuration and secret references. Rehearse a full control plane rebuild from Terraform and Git at least twice a year. The cloud disaster recovery guide covers setting RTO and RPO for tier-0 services.
• Upgrades. Read the upgrade notes for every minor version. For example, Argo CD 3.3 required the ServerSideApply=true sync option on the Application that manages Argo CD itself. Roll upgrades through non-production first.

10. Measuring success

Report outcomes leadership already tracks, plus a few GitOps-specific indicators taken from the controllers' Prometheus metrics and your Git platform. The DevOps and SRE operating model guide explains consistent DORA definitions.

11. Anti-patterns and how to avoid them

12. Argo CD vs Flux comparison

13. Decision helper

Answer five questions about your estate. Example answers are pre-selected; change them to match your environment.

Frequently asked questions

Can an enterprise run Argo CD and Flux together?

Yes. A common split is Flux for platform add-ons installed during cluster provisioning and Argo CD for application teams. Give each tool exclusive ownership of its namespaces and resources so the controllers do not overwrite each other.

Is Flux still maintained after Weaveworks closed?

Yes. Weaveworks shut down in early 2024, and Flux continued as a CNCF graduated project with maintainers from several companies. It has shipped regular releases since, through Flux 2.9 in June 2026.

How many clusters can one Argo CD instance manage?

There is no fixed limit. It depends on resource count, sync frequency and controller sharding. In enterprises the constraint is usually trust zones and blast radius rather than raw scale, which is why production and non-production get separate control planes.

Does GitOps satisfy change-management audit requirements?

It provides strong evidence: every change is a reviewed pull request with an approver, a timestamp and a diff, and the controller records what was applied. Auditors still expect documented policy, branch protection, separation of duties and a break-glass procedure.

Adopt GitOps with CloudForge

CloudForge helps platform and security teams choose the right pattern for each trust zone and stand it up with the controls auditors expect. Engagements are documented and designed for a clean handover to your team.

• Infrastructure Audit: a review of your clusters, pipelines and delivery controls with a prioritized roadmap. See pricing.
• Platform engineering: reference architecture, repository design, bootstrap and pilot through platform engineering consulting.
• Delivery and reliability: DevOps consulting, CI/CD deployment engineering and SRE consulting for scale-out and operations.

Planning a GitOps rollout across your clusters? Contact CloudForge to review your estate and agree the pattern for each trust zone.

Sources and further reading

• InfoQ: Argo CD 3.5 tightens supply chain security with internal mTLS and Source Integrity
• Argo CD v3.5.2 release notes
• Argo CD v3.5.0-rc1 changelog
• argocd-agent: features overview
• argocd-agent: hybrid architecture
• Red Hat: Argo CD Agent architecture overview
• Flux: Announcing Flux 2.9 GA
• Flux v2.9.0 release notes
• Flux: Announcing Flux 2.7 GA
• ControlPlane: Flux architecture and multi-cluster strategies