A Major Release Takes Shape on the Road to General Availability
The Argo CD community used ArgoCon Japan 2026 on July 20 to lay out the road to Argo CD 3.5, and the message to platform teams is direct. Maintainers describe 3.5 as the biggest release since Argo CD 3.0, with hundreds of improvements and a clear focus on making ApplicationSets first-class citizens. The release candidate landed in June, and general availability is targeted for August 4, 2026. For organizations that run GitOps across dozens or hundreds of clusters, this is the release that reshapes daily operations. We read the roadmap as a signal that Argo CD is maturing from a deployment engine into a governed platform surface that engineering leaders can standardize on.
The timing matters for anyone planning a third-quarter upgrade cycle. Argo CD sits at the center of many internal developer platforms, and a version bump touches every team that ships through it. The 3.5 line pulls together security hardening, a redesigned ApplicationSet experience, Helm 4 support, and several features that graduate from alpha to beta. Each change carries adoption cost and testing effort, so treating 3.5 as a routine patch would be a mistake. We recommend that platform leads read the release candidate notes now, stand up a staging control plane, and validate their ApplicationSet generators well before the August general availability date arrives.
ApplicationSets Finally Get a First-Class User Interface
ApplicationSets have powered multi-cluster and multi-tenant fleets for years, and they lived almost entirely in YAML. Argo CD 3.5 introduces a native ApplicationSet UI with list, filter, and detail views, giving operators a real window into the generators that produce their applications. The standout addition is a Preview Apps tab, which shows the applications an ApplicationSet template will create before anything reaches a cluster. Every generated Application now carries an owner badge stamped with its parent name on the resource tree, and clicking that badge jumps straight to the parent. For teams managing large generator matrices, this visibility reduces the guesswork that has long surrounded ApplicationSet behavior.
We see the Preview Apps capability as the most practically useful part of the release. GitOps promises that the desired state lives in Git, and it still leaves operators reasoning about what a templated generator will expand into across environments. A dry-run view of the resulting applications closes that gap and makes review conversations concrete. The feature ships as alpha in 3.5, so the look and behavior will keep changing as the maintainers gather feedback. Platform teams should treat it as a preview worth exercising in lower environments, gather notes from their operators, and feed that input back to the project while the interface is still taking shape.
Helm 4 Support Arrives Without Forcing a Migration
Helm remains the packaging format of record for a large share of Kubernetes workloads, and Helm 4 introduces changes that teams have watched carefully. Argo CD 3.5 adds Helm 4 support alongside continued Helm 3 compatibility, so operators can adopt the newer tooling on their own schedule. This dual-track approach lets a platform team run existing Helm 3 charts through the same control plane while they evaluate Helm 4 features on selected applications. For large estates with thousands of releases, the ability to move chart by chart removes a major source of upgrade anxiety and keeps the blast radius of any change small and observable across the fleet.
The engineering value here comes from optionality. A control plane that pins you to a single Helm major version forces a coordinated migration across every team at once, which rarely fits real release calendars. Argo CD 3.5 lets each application declare its own Helm behavior, so a payments team and a data team can adopt Helm 4 at different times without contention. We view this as the correct default for a shared platform component. It respects the reality that migrations happen in waves, and it gives platform owners a supported path to retire Helm 3 gradually as confidence in Helm 4 grows across the organization.
Internal mTLS Closes a Quiet Gap in the Trust Model
Argo CD 3.5 now enforces mutual TLS for communication between the repo-server and other Argo CD components. For deployments without custom certificates, the system generates self-signed certificates in memory, so the protection applies out of the box. This matters because many teams apply mTLS at the ingress layer and assume the whole system is covered. InfoQ captured the problem plainly, noting that the previous design leaves internal traffic outside the usual mTLS protection that teams apply at the ingress layer. Encrypting the repo-server path removes a channel that carried manifests and repository content in the clear inside the cluster network, where sensitive configuration flows constantly.
We treat this as a meaningful security upgrade for regulated environments. Auditors increasingly ask about encryption in transit for every hop, including service-to-service traffic inside a namespace. Argo CD handling certificate generation automatically lowers the operational cost of meeting that requirement, since teams avoid wiring up a certificate authority just to satisfy an internal control. Platform owners running Argo CD in finance, healthcare, or government contexts should flag this feature in their upgrade justification. It strengthens the compliance story for the control plane and reduces the number of custom mitigations that security teams have to document and maintain around the deployment path.
Source Integrity Validation Hardens the Supply Chain
Supply-chain attacks have moved from theory to routine, and Argo CD 3.5 responds with source integrity validation. Operators can require that Git sources carry valid signatures before any sync proceeds, configured through the Application spec with sourceIntegrity.required set to true or through the CLI with argocd app set and the source-integrity-required flag. When enabled, a compromised or tampered repository cannot push unsigned manifests into a live cluster, because the control plane refuses to reconcile against sources that fail signature checks. This turns a security best practice into an enforced gate that lives inside the deployment engine itself, at the exact moment a change would otherwise reach production.
The design choice we appreciate is that enforcement sits at the point of deployment. Signing commits helps only when something checks those signatures at the moment of action, and Argo CD 3.5 places that check directly in the sync path. For platform teams building toward SLSA-style guarantees, this feature provides a concrete control that maps to audit requirements. We suggest rolling it out first on high-value applications such as shared infrastructure and security tooling, then widening coverage as signing discipline spreads across engineering. Pairing source integrity with the new internal mTLS gives the control plane a coherent story about trust from the repository all the way to the cluster.
Impersonation and the Source Hydrator Graduate to Beta
Two features that platform teams have tracked for a while advance to beta in 3.5. Impersonation lets Argo CD apply a specific user identity when it performs server-side tasks, which gives operators finer control over what the control plane can touch on behalf of each tenant. The Source Hydrator moves to beta as well, supporting multi-repository GitOps patterns where rendered manifests flow through a hydration step before deployment. Both capabilities target the same audience, namely large organizations that run Argo CD as multi-tenant infrastructure and need stronger boundaries between the teams that share a single control plane and its permissions.
These graduations tell us where Argo CD is heading. Impersonation aligns the control plane with least-privilege expectations, so a tenant cannot use the platform to reach resources outside its scope. The Source Hydrator supports the rendered-manifests pattern that many advanced teams already assemble by hand, and bringing it into the project reduces the custom glue those teams maintain. For engineering leaders evaluating whether Argo CD can serve as the backbone of a company-wide platform, the arrival of these features at beta maturity is a strong data point. It shows the project investing in the multi-tenant governance that enterprise adoption demands.
