Argo CD v3.5.0, published on August 4, 2026, moves manifest rendering from Helm 3 to Helm 4. That compatibility change leads a release that also gives platform operators tighter control over generation load, cache scope, and repository trust.
The full release notes and downloads are on the GitHub release page.
Helm 4 changes manifest generation ¶
Argo CD now uses Helm 4 rather than Helm 3 for Helm based manifest generation. This is the change most likely to expose assumptions in existing delivery pipelines. Teams should render representative applications before rollout and compare the generated resources, especially where charts depend on Helm behavior rather than explicit templates and values.
The same release adds wildcard glob patterns for valueFiles. That can reduce repeated value file declarations across environment or tenant layouts. It also broadens the set of files that a pattern can select, so repository tests should verify the exact rendered input for each application.
Logs now render Helm ValuesObject content as YAML instead of binary data. This is a smaller change, but it makes failed generation easier to inspect from existing log pipelines. Treat those logs as potentially sensitive because rendered values can contain deployment configuration.
Generation load gets explicit controls ¶
ApplicationSet management can now run with concurrency, and manifest hydration queue concurrency is configurable. The repository server also gains a parallelism limit. Together, these changes let operators separate throughput from resource pressure instead of allowing every source operation to compete without a defined ceiling.
The controls matter most when a single repository event affects many applications. Higher concurrency can reduce reconciliation delay, but it can also move the bottleneck to Git hosting, storage, CPU, or an external credentials provider. A conservative limit with queue and latency monitoring is safer than selecting a value from application count alone.
Webhook triggered application refreshes also gain configurable jitter. This spreads work after a shared webhook event and reduces synchronized refresh pressure. Jitter deliberately adds a small delay for some applications, so the tradeoff is lower peak load in exchange for less uniform refresh latency.
The supplied changelog does not name the configuration keys or recommend values for these controls. Operators should take the exact settings from the versioned documentation or manifests, then validate them under a realistic event burst.
Cache and repository boundaries tighten ¶
Objects from namespaces that are not allowed are now dropped before they enter the server cache. This reduces unnecessary cache contents and keeps namespace policy closer to the point of ingestion. Operators should watch cache size, application visibility, and namespace policy results during rollout, since a policy mismatch can now prevent an object from reaching later cache consumers.
Repository access gains mTLS support in repo-server. The release also adds CLI support for Source Integrity configuration and an opt in, alpha source integrity check for dry sources. The alpha label matters: it is suitable for controlled evaluation, not an assumption of a settled production contract.
Release artifacts retain a separate verification path. Container images are signed with cosign, while provenance for images and CLI binaries meets SLSA Level 3 specifications according to the release notes. The project provides verification documentation for checking those assets before promotion.
Upgrade notes ¶
Argo CD 3.5.0 is a stable release, not a prerelease. For an upgrade from another minor version, read the project upgrade documentation and test Helm output before changing production controllers.
The quick start commands in the release use kubectl apply with --server-side and --force-conflicts for fresh installations. They are not a substitute for the documented minor version upgrade path. A staged rollout should cover Helm rendering, ApplicationSet generation, cache visibility, and repository authentication before broad deployment.