Argo CD vs FluxCD: Debunking Helm Versioning Myths in GitOps

Loga.dev · May 21, 2025 · 6 min read

Helm support is one of the most debated differences between Argo CD and FluxCD — and also one of the most misunderstood. You’ll often hear:

“FluxCD handles Helm better because it uses real helm install and supports versioning and rollback.”

But in real GitOps workflows, this isn’t just misleading — it’s potentially dangerous.

This post breaks down the myths around Helm versioning and rollback in FluxCD, explains why Argo CD’s approach is actually more aligned with GitOps, and shows how Argo CD users can declaratively manage Helm at scale — without losing clarity, traceability, or control.

📖 This is a follow-up to our deeper GitOps comparison of Argo CD vs FluxCD, where we explored architecture, RBAC, UX, and multi-cluster design.

🔸 Myth 1: “FluxCD supports Helm rollback, Argo CD doesn’t.”

This is true on the surface — but flawed in principle.

✅ Reality: GitOps rollback should happen in Git, not in the cluster.

FluxCD stores Helm release state inside the cluster using secrets. When you run helm rollback, you’re changing the cluster state manually — Git knows nothing about it. You’ve now broken GitOps.

By contrast, Argo CD uses Helm as a renderer — not a state engine. It pulls charts and values from Git, renders manifests internally, then applies them using kubectl. Crucially, it compares the rendered output with the live cluster state — so if anything drifts from Git, ArgoCD flags and reconciles it.

Rollback in ArgoCD means a Git revert, which is far more auditable and aligns with GitOps principles.

Git should be the source of truth — not Helm’s secret-based release history.

🔸 Myth 2: “Helm versioning makes deployments safer.”

FluxCD’s versioning gives you access to the full Helm history in-cluster, and on paper that sounds like a safety net.

✅ Reality: Helm versioning creates silent drift and undermines Git as your single source of truth.

Let’s say your Git repo has chart version 1.2.3, but someone rolls the cluster back to 1.2.2 using helm rollback. Now your cluster and Git are out of sync — and FluxCD won’t correct it, because the Helm release version is “technically healthy.”

In contrast, Argo CD re-renders from Git on every sync and compares the resulting manifests with the cluster. If the live state diverges from Git — even with the same chart version — Argo CD will detect and correct it.

Versioning isn’t safer if it breaks declarative control.

🔸 Myth 3: “FluxCD is the only GitOps tool that can patch Helm charts declaratively.”

A common claim is that FluxCD allows you to declaratively patch Helm chart output — like CRDs or deployment resources — without forking the chart or overriding values.yaml.

✅ Reality: Patching Helm-rendered output is not a FluxCD feature — it’s just plain Kustomize. Argo CD supports it natively too.

In both tools, you can define a kustomization.yaml that includes Helm charts and overlays:

kind: Kustomization

resources:
  - "./resources/controller-manager-externalsecret.yaml"
  - "./resources/github-webhook-server-externalsecret.yaml"
  - "./resources/runner-small.yaml"
  - "./resources/runner-medium.yaml"

overlays:
  - "./overlays/patch-controller-manager.yaml"

helmCharts:
  - name: actions-runner-controller
    repo: https://actions-runner-controller.github.io/actions-runner-controller
    version: 0.23.7
    releaseName: gharc
    namespace: gharc-system
    valuesFile: values.yaml
    includeCRDs: true

This is Kustomize-native patching, not a controller feature. No need to fork Helm charts or inject post-render hacks — Argo CD handles it cleanly.

Declarative patching isn’t special to FluxCD — it’s upstream Kustomize, and both tools support it equally.

🔸 Myth 4: “Argo CD doesn’t support Helm hooks or Helm tests.”

This one is mostly true — Argo CD doesn’t run helm test or lifecycle hooks like pre-install or post-upgrade.

✅ Reality: Argo CD replaces Helm’s procedural hooks with declarative sync phases — and that’s exactly what GitOps wants.

Argo CD supports hook execution using annotations:

metadata:
  annotations:
    argocd.argoproj.io/hook: PreSync
    argocd.argoproj.io/sync-wave: "0"

This enables full control over execution order, rollback behavior, and pre/post-deploy validation — without depending on Helm’s internal state machine.

And helm test? In GitOps workflows, tests belong in CI pipelines — not in post-deploy steps that depend on live state.

Declarative sync control scales. Helm hooks don’t.

✅ Summary: Helm in Argo CD vs FluxCD

🧠 Conclusion: Helm is a Template Engine — Not a State Machine

The truth is simple: Helm was designed as a package manager, not a source of truth. FluxCD builds on that by treating Helm state as canonical. Argo CD breaks away — treating Helm as a template renderer, and Git as the single source of truth.

That tradeoff matters.

If you care about reproducibility, rollback, and platform-wide Git consistency, Argo CD’s stateless Helm approach is exactly what GitOps needs.

Helm history lives in secrets. Git history lives in your repo. Only one of them scales.

📖 Missed the bigger comparison?
👉 Read Part 1: ArgoCD vs FluxCD — A Real-World GitOps Comparison

—

Need help scaling your GitOps architecture? Get in touch.