Planning or taking over a GitOps platform? WZ-IT builds GitOps with Argo CD or Flux: repository structure, promotion, drift detection, secrets and recovery. See Platform Engineering
As of October 2026: Argo CD and Flux are both CNCF projects with Graduated status (Argo since 6 Dec 2022 according to the CNCF, Flux since 30 Nov 2022 according to the CNCF) and both are licensed under Apache-2.0 (Argo CD, Flux). The current releases are Argo CD v3.5.6 (20 Oct 2026) and Flux v2.10.0 (26 Oct 2026). So maturity and license do not decide the choice. The architecture does, and what it means for operation, tenant separation, secrets and recovery.
Table of contents
- Decision rule in brief
- Architecture: server with a UI or controller toolkit
- GitOps tool comparison by criteria
- Helm: two different models
- Secrets: where decryption happens
- Backing up and recovering GitOps itself
- Resource needs: what the documentation says
- Which tool when
- Our practice at WZ-IT
- Further guides
- Status and methodology
Decision rule in brief
- Several teams who should see status, diffs and syncs in one interface, and a central view of many clusters: Argo CD.
- A platform team that wants only Kubernetes RBAC and Git or OCI as the interface, with encrypted secrets in the repository and image updates in the same toolkit: Flux.
- A single cluster, one team, Helm or Kustomize: either is enough. Existing team knowledge decides, and a switch needs a concrete reason.
The reasons are in the sections below; the table "Which tool when" sorts them by situation.
Architecture: server with a UI or controller toolkit
Argo CD has three core components (architecture): an API server for the web UI, CLI and CI systems (with authentication, RBAC and Git webhooks), a repository server that renders manifests from Git, and an application controller that compares live and desired state. Configuration runs through the custom resources Application and AppProject. The Argo CD Core variant runs headless without the Argo API, Argo RBAC, OIDC login and notifications, and relies on Kubernetes RBAC.
Flux consists of the GitOps Toolkit (components). By default flux bootstrap installs the source-controller (GitRepository, OCIRepository, HelmRepository, Bucket), the kustomize-controller (Kustomization), the helm-controller (HelmRelease) and the notification-controller; the image controllers are optional (bootstrap). There is no central server.
GitOps tool comparison by criteria
| Criterion | Argo CD | Flux |
|---|---|---|
| Components | API server, repository server, application controller, Redis (cache); ApplicationSet and notifications controllers | source, kustomize, helm and notification controllers; optionally image reflector and image automation |
| Interface | built-in web UI, CLI, API | no UI of its own, ecosystem tools (FAQ) |
| Access and RBAC | own RBAC, SSO (OIDC, OAuth2, LDAP, SAML 2.0); AppProjects restrict repos, destinations and resource kinds, project roles bound to OIDC groups (Projects) | Kubernetes RBAC: controllers impersonate a service account per Kustomization or HelmRelease (multi-tenancy) |
| Multi-cluster | one instance manages many clusters, credentials as cluster secrets (setup); ApplicationSets | controllers usually run per cluster; remote apply through spec.kubeConfig (Kustomization) |
| Sync behavior | auto-sync, prune and self-heal are opt-in; Git polled every three minutes, webhooks shorten that (auto-sync, webhooks) | reconciliation at spec.interval (required field), spec.prune is a required field of the Kustomization |
| Helm | helm template, lifecycle handled by Argo CD |
HelmRelease runs Helm actions; drift detection and correction are optional (spec.driftDetection) |
| Kustomize and other formats | Kustomize, Jsonnet, YAML, config management plugins | Kustomize; sources Git, OCI, Helm repositories, buckets |
| Image automation | separate project Argo CD Image Updater, under active development according to its docs, testing in non-critical environments suggested | controllers in the toolkit, write new tags back to Git (guide) |
| Notifications | Argo CD Notifications with triggers and templates (docs) | notification-controller in the default installation (guide) |
| Secrets | secrets on the destination cluster recommended, injecting secrets during rendering discouraged | SOPS decryption in the kustomize-controller |
| Upgrading the tool | notes per minor step, backup before major releases (upgrading) | from any v2.x to any other v2.x, custom resources may need editing (releases) |
| Release and support | minor every three months, patches for the three most recent minors (release process) | at least three minors per year, the last three supported, backports by the community on a best-effort basis (releases) |
| Kubernetes versions | Argo CD 3.5 tested with 1.33 to 1.36 (installation) | Kubernetes 1.35 and newer (installation) |
Both matrices belong in the check of the target version before a cluster upgrade; support dates, version skew and procedure are in Kubernetes Upgrade: Roadmap, End of Support and Emergency Guide.
Helm: two different models
Argo CD uses Helm only to render with helm template; Argo CD controls the lifecycle of the application (Helm in Argo CD). Helm hooks are mapped to Argo CD hooks; the documentation states that this is annotation compatibility and not a guarantee of identical semantics. The Flux HelmRelease, by contrast, runs Helm actions (install, upgrade, test, uninstall, rollback) and can detect and correct drift from the desired state once spec.driftDetection is enabled.
Anyone who uses Helm tests and Helm rollback as a release mechanism gets that with Flux. Anyone who wants one sync lifecycle across Helm, Kustomize and plain YAML gets it with Argo CD. Argo CD bundles Helm and Kustomize and raises them at the start of each minor release (release process). The move from Helm 3 to Helm 4 is described in Migrate from Helm 3 to Helm 4.
Secrets: where decryption happens
Argo CD recommends populating secrets on the destination cluster (Sealed Secrets, External Secrets Operator, Secrets Store CSI Driver). The documentation advises against plugins that inject secrets during rendering, because Argo CD stores generated manifests in plaintext in its Redis cache. Decryption in the render step, for example SOPS through a config management plugin, matches this discouraged pattern.
Flux decrypts SOPS-encrypted secrets directly in the kustomize-controller through spec.decryption, with OpenPGP, age or cloud KMS (SOPS guide). That keeps encrypted values in the repository. With the External Secrets Operator or the Secrets Store CSI Driver, the repository holds only references and the values live in the secret store; Sealed Secrets stores encrypted values in the repository. Operators in the destination cluster work with both GitOps tools.
Backing up and recovering GitOps itself
Argo CD is largely stateless: its data lives as Kubernetes objects in etcd, and Redis is a disposable cache (high availability). argocd admin export and argocd admin import back it up and restore it (disaster recovery). With Flux the desired state lives in Git or an OCI registry; flux bootstrap pushes the Flux manifests to the repository and lets Flux update itself from there (bootstrap). It follows that a new cluster is tied back to the desired state by bootstrapping again against the same repository.
Repository credentials and decryption keys usually live as secrets in the cluster, not in the repository. They belong in a separate backup, in addition to the application data backup described in Kubernetes backup: the four layers.
Resource needs: what the documentation says
The installation and scaling pages of both documentations state no minimum values for CPU and memory. The defaults are visible in the release manifests, which we evaluated on 28 Oct 2026:
| Default | Argo CD v3.5.6 | Flux v2.10.0 |
|---|---|---|
| Workloads of the standard installation | 7 (6 Deployments, 1 StatefulSet); Core variant: 4 | 4 controllers with flux bootstrap; the complete install.yaml contains 7 Deployments including image controllers and source-watcher |
| Requests and limits | not set in install.yaml, ha/install.yaml and core-install.yaml |
per controller request 50 to 100 m CPU and 64 MiB, limit 1 CPU and 1 GiB |
| Sum of requests | none | 350 m CPU and 256 MiB for the four standard controllers |
For scaling, Argo CD names sharding the application controller across replicas and, for 1000 applications, 50 status and 25 operation processors; the HA manifests need at least three nodes because of anti-affinity (high availability). For hundreds of applications Flux shows ten parallel reconciliations with limits of 2 CPU and 2 GiB per controller and supports sharding (vertical scaling). These are defaults and tuning examples, not measured consumption; actual need depends on the number of applications and repository size and is measured in your own cluster. Anyone running Argo CD in production sets requests and limits themselves.
Which tool when
| Situation | Recommendation | Evidence |
|---|---|---|
| Several development teams need status, diff and sync in one interface | Argo CD | built-in web UI, project roles bound to OIDC groups |
| Central view of many clusters from one instance | Argo CD | cluster secrets, ApplicationSets |
| Kubernetes RBAC only, no additional login surface | Flux or Argo CD Core | service account impersonation, headless Core variant |
| Encrypted secrets in the repository without an additional operator | Flux | SOPS in the kustomize-controller |
| Secrets through External Secrets Operator or Vault, decoupled from sync | either | explicitly recommended by Argo CD |
| Helm releases with Helm tests and Helm rollback | Flux | HelmRelease runs Helm actions |
| One sync lifecycle for Helm, Kustomize and YAML | Argo CD | Helm only as a renderer |
| Write new image tags to the repository automatically | Flux | image controllers in the toolkit; a separate project for Argo CD |
| One cluster, one team, Helm or Kustomize | the tool the team knows | either covers the case |
Our practice at WZ-IT
The platform engineering service covers GitOps consulting and implementation with Argo CD or Flux: repository structure, promotion, drift detection, secrets concept and recovery. The choice follows the decision rule above and the existing knowledge in the team. Existing CI pipelines usually stay in place for build and test, and GitOps takes over deployment. Every platform building block gets an owner, an upgrade path and a recovery.
We also run Argo CD as a hosted application; scope and offer are on the page Argo CD hosting and operations. The statements in this guide rest on the linked documentation and manifests, not on our own benchmarks.
Further guides
- Migrate from Helm 3 to Helm 4: package manager deadlines and breaking changes
- Kubernetes backup: the four layers: what is backed up in addition to GitOps
- Kubernetes Upgrade: Roadmap, End of Support and Emergency Guide: add-on matrix and version skew before a cluster upgrade
- k3s vs. RKE2 vs. Talos: the distribution under the GitOps tool
- Taking over a Kubernetes cluster: audit checklist: check the GitOps state of a foreign cluster
Status and methodology
- Survey: 28 Oct 2026, from the documentation and repositories of both projects and the CNCF project pages.
- Versions: Argo CD v3.5.6 and Flux v2.10.0 according to the GitHub releases on the survey date; the "stable" documentation describes Argo CD 3.5.
- Licenses: check of the LICENSE files and the GitHub license field of argo-cd, flux2 and the Flux controllers (each Apache-2.0); the Flux Operator is AGPL-3.0 according to its README.
- Manifest evaluation: counting workloads and reading requests and limits from argo-cd v3.5.6
install.yaml,ha/install.yaml,core-install.yamland flux2 v2.10.0install.yaml. All containers including init containers were checked (Argo CD: 0 of 10, HA 0 of 15, Core 0 of 6 with requests or limits; Flux: 7 of 7). Sum of the Flux requests of the four standard controllers: source 50 m plus kustomize, helm and notification 100 m CPU each = 350 m; 4 times 64 MiB = 256 MiB. - Inferences: statements about recovery through bootstrap and about secret decryption in the render step are conclusions from the documentation, not literal commitments by the projects.
- Not covered: consumption measurements, commercial distributions and progressive delivery tools (Argo Rollouts, Flagger).
The tables may be reused with attribution and a link to this guide.
Argo CD or Flux for your platform? We clarify the choice, the repository structure and the secrets concept together: Platform Engineering and GitOps.
Related service: GitOps with Argo CD and Flux
