Argo CD 3.6 moves GitOps rollout observability into the core of the project
Released on November 3, 2026, Argo CD 3.6 adds progressive-sync metrics to ApplicationSets, hardens Dex TLS, and replaces homegrown Lua scripts with native health checks. For operators that means less glue code to maintain and SLSA level 3 provenance on every artifact.
November 3, 2026. The Argo CD project releases 3.6.0 of its GitOps continuous-deployment orchestrator, followed on November 4 by a 3.6.1 fix. November 3, 2026. The substance comes down to three words: observability, hardening, and native health checks. November 3, 2026. Images and binaries are cosign-signed with SLSA level 3 provenance. Why it matters: this release does not sell a flashy feature — it shrinks the hand-rolled glue an operator has to maintain around their GitOps.
ApplicationSets gain progressive-sync metrics
The most visible change concerns ApplicationSets, the mechanism that deploys the same set of applications across many clusters. Progressive sync — rolling out waves step by step rather than all at once — had little observable signal until now: mid-wave, it was hard to know how many applications had already flipped.
3.6.0 closes that gap with progressive-sync metrics exposed by the ApplicationSet controller, an app-refresh counter triggered during progression, and the surfacing of the progression scenario in the resource’s conditions. There is also a force-reconciliation annotation to regain control before advancing to the next wave — effective only on applications managed by an ApplicationSet in progressive mode, not on standalone applications. Rate-limiter flags on the controller round out the picture.
For an SRE, that is the difference between deploying blind and deploying under control: a multi-cluster rollout can now be measured with the same instincts as application telemetry.
Dex: TLS hardening becomes configurable
Dex, the SSO bridge between Argo CD and identity providers, is a sensitive link — it holds the authenticated front door of the control plane. 3.6.0 makes its TLS configuration drivable from argocd-cm: explicit cipher suites and curve preferences, a configurable minimum TLS version, and even the storage type for Dex.
This is not cosmetic. An overly permissive cipher suite or a still-allowed TLS 1.0 is exactly the weakness compliance audits flag, and the one a security team asks you to close. Being able to pin it in declarative config — and therefore version it in Git — rather than in a container file makes hardening auditable and reproducible. The operational trade-off: these changes only take effect after a dex-server pod restart.
Native health checks replace homegrown Lua scripts
The most structural change for a long-time operator is a wave of native health checks for CustomResourceDefinition resources previously covered by Lua scripts in resource.customizations. Argo CD can now natively assess the health of CloudNativePG (databases and backups), cert-manager (certificate requests, ACME orders), Velero (backups, restores, schedules), Tekton (PipelineRun, TaskRun), the Prometheus Operator (Alertmanager, ThanosRuler), Kyverno, AWS ACK resources, Kro, Flink, and Medusa, plus Gateway API (TLSRoute, ListenerSet).
Why this matters: homegrown Lua scripts are operational debt. They break when CRDs change, they diverge from cluster to cluster, and nobody documents them. Replacing them with project-maintained health checks — kept in step with operator versions — removes glue code and aligns the health verdict with the community instead of a local script. Affected operators should remove their old Lua overrides so they do not shadow the improved native checks.
Provenance, signing, and small operational wins
The rest of the release consolidates supply chain and observability. The project’s OpenTelemetry spans become sampleable by configuration. The hydrator — the component that rewrites manifests before commit — gains metrics and alpha support for signing hydrated commits. The argocd admin export CLI learns an --exclude-status flag that produces lighter, easier-to-diff exports.
On the security side, two points deserve attention. Artifacts are cosign-signed with SLSA level 3 provenance — an increasingly common requirement in supply-chain policies. And an option now lets you disable strict impersonation enforcement for multi-tenant setups: convenient for some migrations, but to evaluate carefully before enabling, since it loosens a security control.
What the native health checks signal: GitOps grows up
The wave of native health checks is more than a convenience — it is a maturity signal for the whole ecosystem. When Argo CD natively reports the health of CloudNativePG, cert-manager, or Velero, it means those operators have become common enough to deserve first-class support in the reference GitOps tool. The project is absorbing what teams used to do by hand, and that is the right move: customization is a cost, normalization is a product.
The contrast with the other major engine, Flux, is instructive. Where Flux bets on a composition of lightweight controllers and a minimal surface, Argo CD concentrates more logic in a rich control plane — and embraces being the catalog of operational best practice. Both approaches remain valid, but the direction of 3.6.0 is unmistakable: Argo CD wants to be the place where deployment observability lives as a standard, not a plugin.
There is also 3.6.1, shipped the next day. A GitOps control plane is a critical link in the delivery chain, so prudence says to wait for the first patch before a wide rollout, and to verify the cosign signature of the image you deploy. On that front, Argo CD has done its part — the operator has to do theirs.
For an SRE steering dozens of clusters, this release draws one clean line: everything that touches deployment must be measurable, signed, and reversible. The progressive-sync metrics, the sampleable OpenTelemetry spans, and the native health checks all converge on that goal — making a rollout as instrumented as a production application. That is exactly the discipline GitOps lacked in its early days, when a deployment was treated as a mere git push. Operators who skipped the last major jump should apply the same playbook: read the upgrade overview, back up the three ConfigMaps, and spot-check one resource of each newly covered CRD before trusting the verdict across a fleet.
In practice, the payoff shows up the first time a Velero backup silently stops running and Argo CD flags it Degraded without a single line of custom Lua. Multiply that across a fleet running twenty operators, and the saved maintenance is real, if unglamorous. The feature list reads as quiet incremental work, but for a team that has been patching Lua scripts through three CRD migrations, it is the release that finally deletes a drawer of undocumented glue.
Verdict
If you run Argo CD in production, the upgrade to 3.6.1 is a low-risk, high-yield job: no breaking changes flagged, but a set of gains that shrink your glue code. Deploy with kubectl apply --server-side --force-conflicts against the v3.6.1 manifests — Argo CD’s CRDs are large and fail without --force-conflicts — then drop your now-redundant Lua overrides to benefit from the native health checks. If you deploy multi-cluster with progressive ApplicationSets, enable the new metrics now: it is the only way to steer a wave other than blind. And if you are audited on SSO, pin Dex cipher suites and minimum TLS version in argocd-cm — one pod restart, and the hardening lives in Git instead of a container.