GitOps with Argo CD and Flux

The cluster pulls the desired state

In GitOps, Git holds the desired state and a controller inside the cluster continuously reconciles the cluster to match it, instead of a CI job pushing with helm upgrade. Both main GitOps tools support Helm. Argo CD treats a chart as a source of manifests: it renders it with helm template and applies the result itself, mapping Helm hooks to its own sync phases. Because Argo CD does the applying, the release does not appear in helm list. Flux uses its helm-controller: a HelmRelease custom resource names a chart source and values, and Flux performs real Helm installs and upgrades, with options for automatic remediation such as rollback on failure; the releases do appear in helm list. Either way you get drift detection, an audit trail in Git and no cluster credentials in CI.

A Flux HelmRelease

Flux pulls the chart from an OCI repository and applies these values; changing the file in Git triggers an upgrade.

apiVersion: source.toolkit.fluxcd.io/v1
kind: OCIRepository
metadata:
  name: shop-api
  namespace: shop
spec:
  interval: 10m
  url: oci://ghcr.io/acme/charts/shop-api
  ref:
    semver: "1.4.x"
---
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: shop-api
  namespace: shop
spec:
  interval: 10m
  chartRef:
    kind: OCIRepository
    name: shop-api
  upgrade:
    remediation:
      retries: 2
  values:
    replicaCount: 3
    image:
      tag: "2.8.0"

A thermostat, not a heater switch

Pushing with helm upgrade is flipping a heater on by hand. GitOps is a thermostat: you set the temperature in Git, and the controller keeps adjusting the room until it matches, even if someone opens a window.

Quick check: Why does a chart deployed by Argo CD usually not appear in `helm list`?

• Argo CD deletes Helm releases
• helm list only shows OCI charts
• Argo CD uses Helm 2
• Argo CD renders the chart and applies the manifests itself instead of creating a Helm release