Argo CD v3.5: Helm 4, mTLS, and a Maturing Source Hydrator

Argo CD v3.5.0 landed on August 4, 2026, bringing substantial changes that touch nearly every layer of the GitOps controller stack. From a major Helm version migration to mTLS hardening and a maturing Source Hydrator workflow, this release reflects where production Kubernetes delivery is heading in 2026.

If you’re running Argo CD at any meaningful scale, several of these changes warrant immediate attention. The Helm 4 migration alone affects how charts are templated and rendered, while the new mTLS support closes a long-standing gap in repo-server communication. Let’s walk through the features that matter most for production deployments.

Helm 4 Migration: A Quietly Massive Change

The headline feature is the migration from Helm 3 to Helm 4 (#28076). Helm 4 shipped with a restructured CLI, removed several deprecated APIs that lingered since Helm 2, and introduced changes to how values.yaml files are parsed and merged. For Argo CD users, this means chart rendering inside the repo server now uses Helm 4’s templating engine.

The practical impact depends on your chart complexity. Charts relying on deprecated Helm 3 functions or workaround syntax may need updates. The good news is that Helm 4 maintains backward compatibility with the chart format itself, so most well-maintained charts work without changes. The migration primarily affects edge cases around template function behavior and dependency resolution.

One notable improvement: Helm 4 renders valuesObject as YAML in log output instead of binary, making debugging significantly easier when troubleshooting chart rendering issues through Argo CD logs.

Source Hydrator Reaches New Maturity

The Source Hydrator continues to evolve as Argo CD’s answer to the “rendered manifests” pattern. This release adds four significant improvements:

Configurable hydration queue concurrency (#27926) — You can now control how many manifest hydration operations run in parallel, which is critical for large fleets with hundreds of applications.
Source integrity verification (Alpha) (#19302) — An opt-in feature that verifies the integrity of dry sources before hydration, adding a supply chain security layer to GitOps workflows.
Separate destination repos (#27011) — The syncSource.repoURL field lets you hydrate manifests from one repo and sync them to a different destination repo entirely.
Dynamic README templates (#19067) — README templates for hydrated repos can now be managed dynamically from the argocd-cm ConfigMap, reducing manual maintenance.

The Source Hydrator pattern addresses a real pain point: storing raw Kubernetes manifests in Git rather than templates that get rendered at apply-time. This eliminates a class of “works on my Argo CD” problems where local rendering differs from what the controller applies.

mTLS for the Repo Server

Argo CD’s repo server communicates with Git repositories and renders manifests, making it a critical trust boundary. Until now, communication between the API server and repo server used unencrypted gRPC. Version 3.5 adds native mTLS support in the repo server (#26715), encrypting this internal traffic.

For organizations running Argo CD in regulated environments or multi-tenant clusters, this closes a meaningful gap. Configuring mTLS involves generating certificates for both the server and client sides:

# argocd-cmd-params-cm
repo.server.tls: "true"
# The repo server will use the TLS certificate
# from the argocd-repo-server-tls secret

# Client-side: API server verifies repo server
reposerver.tls.verify: "true"
reposerver.tls.strict: "true"

The TLS certificates are managed through Kubernetes secrets, and the rotation process integrates with existing certificate management tools like cert-manager.

Configurable Webhook Jitter

At scale, webhook-triggered refreshes create thundering herd problems. When a shared infrastructure repo receives a push, dozens or hundreds of applications may need to refresh simultaneously. The new configurable jitter feature (#25433) spreads these refreshes over a time window, preventing CPU and memory spikes on the application controller.

# argocd-cmd-params-cm
# Maximum jitter duration for webhook-triggered refreshes
# Default: 0 (no jitter, immediate refresh)
controller.webhook.jitter.seconds: "10"

This is a simple setting with outsized impact for large installations. Even a 10-second jitter window dramatically smooths out webhook storms.

Gateway API Support in Network View

The Gateway API has become the standard for Kubernetes ingress and traffic management. Argo CD v3.5 adds Gateway API resources to the network view (#26188), making it easier to visualize how Gateway, HTTPRoute, and BackendTLSPolicy resources relate to your applications.

This release also adds health checks for GatewayClass (#26591) and BackendTLSPolicy (#27385), so the UI accurately reflects whether your Gateway API resources are healthy rather than showing them perpetually in an unknown state.

ApplicationSet Improvements

ApplicationSet, Argo CD’s tool for generating applications from patterns, gains several production-oriented features:

Concurrency control (#26642) — Applications managed by an ApplicationSet can now be processed concurrently, significantly improving reconciliation speed for large sets.
Archived repo filtering (#21505) — Git generators can now filter out archived repositories, preventing accidental application creation from stale repos.
Preview apps tab (#27799) — A dedicated UI tab for preview applications generated by ApplicationSets, improving visibility into ephemeral environments.

Authentication and Security Enhancements

Beyond mTLS, this release strengthens authentication across multiple fronts:

Azure Service Principal for Azure DevOps (#25324) — Service Principal authentication replaces the need for personal access tokens when connecting to Azure DevOps repositories.
Azure AD groups claims overflow (#27397) — Large group claim sets that exceed token size limits are now fetched via the Microsoft Graph API.
Impersonation for server operations (#26898) — Logs, deletes, and other operations now use impersonation, providing better audit trails and tighter RBAC enforcement.
Namespace-scoped cache filtering (#28018) — Objects from non-allowed namespaces are dropped before entering the cache, improving both security and performance.

Upgrading Considerations

Before upgrading to v3.5.0, review these points:

Test Helm charts with Helm 4 locally first. Run helm template with Helm 4 to verify rendering matches expectations.
Review sync windows — the new sync overrun option (#25361) allows syncs to complete even when a sync window is closing, which changes behavior if you relied on hard cutoffs.
Check the RBAC changes — the namespace-scoped cache filtering may affect users who previously accessed resources across namespace boundaries.

Argo CD continues to be the most widely adopted GitOps controller for Kubernetes, with over 23,000 GitHub stars and a thriving contributor community. The v3.5 release solidifies its position with practical production features rather than flashy experiments — exactly what you want from infrastructure tooling that teams depend on every day.

Wrapping Up

Argo CD v3.5.0 is a release focused on hardening and scale. The Helm 4 migration future-proofs chart rendering, mTLS closes a real security gap, and the Source Hydrator features push the rendered manifests pattern toward mainstream adoption. If you’re running Argo CD in production, this upgrade deserves prompt attention — particularly the Helm 4 migration, which requires testing but brings long-term stability benefits.