What's Actually New in Argo CD 3.5, Explained Without the Jargon

Argo CD shipped a new version today, version 3.5.0. The official changelog is long and written for people who already know the project inside out. This post is the plain-English version: what actually changed, why it matters, and the one thing worth testing before you upgrade. (If you followed the repo-server vulnerability I covered earlier, this release is not about that, it is a genuinely separate set of improvements, and worth knowing about on its own terms.)

This post starts from zero. You do not need to have used Argo CD before to follow it, just an interest in what changed and why.

Quick refresher: what is Argo CD?

Argo CD is a tool that watches a Git repository and automatically keeps your Kubernetes cluster matching whatever is in it. You change a file in Git, Argo CD notices, and it applies that change to your cluster for you. This pattern is called GitOps, and Argo CD is one of the most widely used tools for doing it.

What actually changed in Argo CD 3.5

Skipping the internal plumbing changes nobody outside the Argo CD project team needs to care about, here is what is worth knowing.

1. A tamper-evident seal for your deployments

Argo CD can now, optionally, check that the templates it is about to build a deployment from were actually written by someone trusted, before it does anything with them. This is called source integrity verification, and it is new and still early (marked "alpha," meaning expect rough edges and changes before it is considered fully stable).

Here is how it actually works, in plain terms. Argo CD has a feature called the hydrator, which takes your raw template files in Git (what it calls the "DRY source," short for don't repeat yourself, the templates before they get turned into final deployment files) and renders them into the finished Kubernetes configuration Argo CD applies. Source integrity verification plugs into that step. You set a rule on a project saying "commits to this source must be signed with a trusted digital signature," and before the hydrator will render anything from a given Git commit, it checks whether that commit carries a valid, trusted signature. No valid signature, no rendering. Argo CD refuses to build a deployment from it at all, rather than building it and hoping it was fine.

One honest limitation worth knowing: this checks the raw templates coming in, not the finished output going out. The hydrator does not currently sign the rendered files it produces, so it verifies where your source came from, not that nothing happened to it during the render step itself. That is a reasonable thing to expect will mature as the feature moves past alpha.

Think of it like a tamper-evident seal on a package. It does not stop someone from trying to swap the contents. It lets you notice if they did, before you act on it.

2. Real authentication between Argo CD's own internal parts

Argo CD is made of several components talking to each other, an API server, an application controller, a component called the repo-server that turns your Git files into deployable configuration, and more. This release adds mTLS (mutual TLS) between them.

This is more than just encrypting the traffic between them. Each component now has to present a trusted certificate before another component will talk to it, and prove its own identity back. That "mutual" part is genuine authentication: not just "nobody can eavesdrop on this conversation," but "you have to prove who you are before this conversation happens at all."

3. Argo CD borrows more limited identities instead of using its own powerful one

Argo CD has a feature called impersonation. Normally, when Argo CD makes a change to your cluster, it uses its own single identity, one that tends to be quite powerful because it needs to be able to deploy anything, anywhere. Impersonation lets it instead act using a smaller, borrowed identity scoped to just the one team or app it is working on at that moment.

This release extends that limited-identity approach to cover more operations, like viewing logs or deleting resources, not just deployments. This is a genuine, meaningful improvement for anyone running Argo CD across multiple teams: the damage from any mistake or compromise is proportional to how much power was available at the time, not how much was actually needed.

4. A quiet fix that reduces what could leak between teams

If your cluster is shared across multiple teams, Argo CD used to cache information about resources first, then decide whether a given team should be allowed to see them. Now, it drops anything from a namespace a team should not access before it ever enters the cache, rather than after.

It sounds small. In a shared cluster, it is a real reduction in the chance of one team's information accidentally becoming visible to another.

5. Multi-team automation is now considered production-ready

Argo CD has a feature that lets different teams each manage their own automated app-generation rules in their own part of the cluster, rather than everything being centrally managed by one team. That feature, "ApplicationSet in any namespace," has moved from experimental to stable in this release. If you run Argo CD as a shared platform for several teams, this is now something you can build on with more confidence.

6. The one item worth testing before you upgrade

Argo CD has migrated its underlying Helm support from Helm 3 to Helm 4. If anything in your setup depends on Helm-specific behavior, plugins, or quirks, this is the change most likely to break something quietly. Test it in a non-production environment before rolling this version out everywhere.

The theme underneath all of it

Look at the list again and a pattern shows up: tighter identity checks between components, scoped permissions instead of one powerful identity, verification before trust instead of after. None of these are flashy features. They are the unglamorous, structural kind of improvement that platform teams actually benefit from long after the release notes are forgotten.

The whole post in three lines

• Argo CD 3.5 shipped today with optional source integrity verification (checking that your deployment templates were signed by someone trusted before using them), real mutual authentication between its own internal components, and wider use of scoped "impersonated" identities instead of one powerful default one.
• Multi-team ApplicationSet support is now stable, and a shared-cluster caching fix reduces what could leak between teams.
• The one thing to test before upgrading: Argo CD's Helm support moved from version 3 to 4, which is the change most likely to quietly break something if you depend on Helm-specific behavior.

Most of what actually matters in a release like this is not the headline feature. It is the small, structural tightening that adds up over time.

Sources and further reading

• Argo CD v3.5.0 release notes. The official, primary changelog for this release.
• Argo CD documentation: Source Hydrator. How the hydrator and DRY sources work, and where source integrity verification plugs in.
• InfoQ: Argo CD 3.5 Tightens Supply Chain Security with Internal mTLS and Source Integrity. Independent coverage of these two features specifically.
• Octopus: Fix Unsecured Argo CD Communications. Confirms the new mTLS support requires client certificates for authentication, not just encryption.
• Argo CD documentation: TLS configuration. The official configuration reference for repo-server TLS and certificates.
• Argo CD releases page. Full version history and release cadence.