Argo CD 3.5: More Security and a New UI for ApplicationSets

📷 "Computer Board" by Lenharth Systems is marked with CC0 1.0. To view the terms, visit https://creativecommons.org/publicdomain/zero/1.0/.

On August 4, 2026, Argo CD 3.5 was released—the most mature version yet of the leading GitOps tool for Kubernetes. With a focus on supply chain security, a native UI for ApplicationSets, and Helm 4 support, this release marks a milestone in the development of the CNCF project. Time to take a look at the most important innovations in the 3.x series and what they mean for DevOps teams.

The Path to Version 3.5

The 3.x era of Argo CD began in early 2025 with a fundamental overhaul of the architecture. Since then, the project has maintained a remarkable release cadence: Version 3.1 (August 2025) brought native OCI registry support and CLI plugins, 3.2 (November 2025) optimized webhook handlers and improved ApplicationSet Progressive Sync. Version 3.3 introduced enhanced health checks for third-party operators such as CloudNativePG and KEDA, while 3.4 delivered the long-overdue Microsoft Teams integration via workflows instead of the deprecated Office 365 connectors.

With version 3.5, released after two release candidates on August 4, 2026, Argo CD now sets new standards in three areas: security, user interface, and platform flexibility.

Internal mTLS Encryption: A Win for Security Architecture

Arguably the most important innovation in Argo CD 3.5 concerns internal communication. Previously, traffic between the repo server and other components such as the API server and controllers was unencrypted—a gap increasingly seen as critical in security-conscious environments.

Argo CD 3.5 therefore introduces mutual TLS (mTLS) for all internal components. The repo server now only accepts connections with valid client certificates. For environments without their own PKI infrastructure, the server generates self-signed certificates in memory—a pragmatic solution that avoids the file system while still enabling health checks. This closes a security gap in Argo CD that previously had to be secured externally through network firewalls or service meshes.

Source Integrity: Trust in the Git Source

Another security highlight is Git commit signature verification (Source Integrity). Administrators can now enforce that only signed commits from the Git repository may be synchronized. Configuration is done either declaratively in the application manifest via sourceIntegrity.required: true or via the CLI with argocd app set --source-integrity-required. This prevents a compromised repository from rolling out unverified or manipulated manifests—a crucial building block for supply chain security in line with SLSA Level 2 and above.

With this, Argo CD catches up to Flux, which has supported native GPG signature verification in the GitRepository API for some time. Combined with the new mTLS protection of internal traffic, this release addresses two of the most pressing security requirements in enterprise environments.

ApplicationSets Finally Visible in the UI

ApplicationSets are indispensable in large GitOps deployments with dozens or hundreds of microservices: they automatically generate multiple applications from a template for different environments or clusters. Until now, however, their management remained reserved for YAML and kubectl enthusiasts—a native UI was missing.

Argo CD 3.5 changes that: The new ApplicationSet UI (developed by engineers at Intuit, Red Hat, GoTo, and Octopus Deploy) offers list, filter, and detail views. Particularly practical is the Preview Apps tab, which shows which concrete applications will be generated from an ApplicationSet template before the actual synchronization. This reduces errors and significantly speeds up the work of platform teams.

Platform Progress: Helm 4, Namespace-free ApplicationSets, and More

Beyond the big three, Argo CD 3.5 brings a range of further improvements:

Helm 4 support while maintaining backward compatibility with Helm 3, allowing teams to migrate incrementally.
ApplicationSets in any namespace—a long-requested feature that enables multi-tenant deployment of GitOps workflows per team namespace.
ApplicationSet Concurrency Controls, which limit the number of concurrently processed applications and thus avoid cluster and API overload.
Impersonation (from alpha to beta) allows Argo CD to assume a specific user identity for server-side tasks—a win for audit logs in multi-tenant clusters.
Source Hydrator (also beta) separates dry (unhydrated) manifests from their rendered outputs and enables multi-repository GitOps patterns with separate access controls.
Azure AD and Azure DevOps receive improved integrations: group claims are resolved via the Microsoft Graph API, and service principal authentication replaces the previously required PATs.

Conclusion

Argo CD 3.5 is not a revolutionary but a high-quality evolutionary release. The combination of internal mTLS encryption, Git commit signature verification, and the long-awaited ApplicationSet UI makes it the most mature GitOps tool for Kubernetes to date. Teams still running version 2.14 or older should now seriously consider the upgrade path through the 3.x series—the last three minor versions are 3.5, 3.4, and 3.3; older releases no longer receive security updates. Argo CD thus remains the de facto standard for declarative continuous delivery on Kubernetes—more secure, more visible, and more scalable than ever before.

Sources

🌐 Machine-translated from the German original, editorially reviewed. 🤖 Written with AI assistance.