Still on Argo CD 3.2? It's Officially End of Life. Here's What's New in 3.5.

Every Argo CD upgrade cycle, I get the same message from at least one reader.

"We're still on 3.2, should we be worried?"

Short answer: yes. Not because 3.2 stopped working overnight — it didn't. But because Argo CD just shipped 3.5, and that release quietly pulled the plug on 3.2's support window.

👉 So today we're doing two things. First, a real walkthrough of what's actually new in Argo CD 3.5. Second, the EOL talk nobody wants to have but everybody needs to.

---

😤 The Situation (Real Talk)

Argo CD moves fast. Faster than most GitOps shops can realistically track.

And the project only supports the three most recent minor versions with security patches and critical fixes. Not five. Not "whatever you happen to be running." Three.

So the math is brutal and predictable:

• 3.5 ships
• 3.5, 3.4, and 3.3 are now the supported line
• 3.2 drops off the back — no more patches, no more CVE fixes, nothing

👉 If your platform team hasn't looked at the Argo CD version pinned in your Helm values in a while, this is your nudge.

---

🚀 What's Actually New in Argo CD 3.5

Here's the thing about 3.5 — it's not a flashy release. There's no single headline feature you'll see plastered on a conference slide. It's a "platform maturity" release. Security, ApplicationSets, and Helm compatibility all got real attention.

👉 Here's the rundown, grouped by what actually matters day to day.

🔐 mTLS for the Repo-Server

Internal traffic between the repo-server and the rest of Argo CD (API server, application controller, appset controller) used to travel unencrypted inside the cluster. Most teams put mTLS at the ingress and called it a day, leaving internal pod-to-pod traffic as the soft underbelly.

3.5 closes that gap. You can now configure client certificates per component, and the repo-server will even auto-generate self-signed certs in memory for internal health checks if you don't provide your own.

👉 Why it matters: if you're running Argo CD in a regulated environment or a shared multi-tenant cluster, this is the difference between "we have TLS" and "we have TLS everywhere it counts."

🔏 Source Integrity Validation (New) + Source Hydrator (Beta)

This is the supply-chain-security story of the release. Source Integrity lets you require that Git commits are signed, and Argo CD will refuse to sync if the signature doesn't check out.

source:
  repoURL: https://github.com/your-org/your-repo.git
  sourceIntegrity:
    required: true
    signingKey:
      keyId: "your-key-id"

It's also configurable straight from the CLI now:

argocd app set my-app \
  --source-integrity-required \
  --source-integrity-signing-key-id <key-id>

The Source Hydrator — the feature that lets you keep your "dry" (templated) source separate from your "hydrated" (rendered) manifests — graduated from alpha to beta. You can now point the dry and hydrated repos at completely separate Git repositories, which is a pattern a lot of larger orgs have been waiting on.

👉 Common mistake: teams enable Source Integrity requirements on day one across every app, then get paged when a legitimate but unsigned emergency commit gets blocked. Roll this out per-project, starting with your most sensitive apps.

🖥️ ApplicationSets Grow Up

ApplicationSets got several stability and usability wins:

• Native UI support — you can now list, filter, and inspect ApplicationSets right in the Argo CD UI, including a new "Preview Apps" tab that shows what an ApplicationSet template will generate before it deploys anything.
• Any-namespace deployment — ApplicationSets are no longer stuck living in the Argo CD namespace. This is now a fully stable feature, not an alpha flag.
• Concurrency control — you can cap how many applications an ApplicationSet processes in parallel, which matters a lot once you're generating hundreds of Applications from a single template.

👉 If you've ever had an ApplicationSet accidentally hammer your Git provider's API because it fanned out 300 reconciliations at once, the concurrency control alone is worth the upgrade.

⚙️ Helm 4 Support

Argo CD now speaks Helm 4, while staying backward compatible with Helm 3 charts. If you've been holding off migrating charts because your GitOps tooling wasn't ready, that excuse is gone.

👤 Impersonation Moves to Beta

Impersonation lets Argo CD perform an operation — sync, delete, log streaming — under a specific user's identity instead of the service account's. In 3.5, this now correctly applies to server-side operations too, not just the sync engine.

👉 Why it matters: in multi-tenant clusters, your audit logs finally reflect who actually triggered an action, not just "argocd-application-controller did it."

🧩 Smaller Wins Worth Knowing About

Feature	What it fixes
Azure AD group claims via Microsoft Graph API	Users in dozens of Azure AD groups no longer hit OIDC token size limits
Azure DevOps Service Principal auth	Drop the PAT, use proper service identity for Azure DevOps repos
Gateway API in the network view	Apps using Gateway API ingress now render correctly in the topology view
--app-namespace everywhere	The flag is now consistent across every argocd app subcommand
Search by target revision	Filter the Applications list by branch, tag, or commit SHA

---

📊 How It Fits Together

flowchart TD Git[Git Repo - Dry Source] -->|signed commit| Integrity[Source Integrity Check] Integrity --> Hydrator[Source Hydrator] Hydrator -->|hydrated manifests| HydratedRepo[Git Repo - Hydrated] HydratedRepo --> RepoServer[Repo Server] RepoServer -->|mTLS| Controller[Application Controller] Controller -->|impersonation| Cluster[Target Cluster] AppSet[ApplicationSet Controller] -->|concurrency limited| Controller

---

⚰️ Argo CD 3.2 End of Life — What It Means for You

Here's the part that actually needs action from you today.

Argo CD's support policy covers the three most recent minor releases. With 3.5 out the door, that supported set is now 3.5, 3.4, and 3.3. Argo CD 3.2 has officially reached End of Life.

👉 In plain terms, EOL means:

• No more security patches — including for newly discovered CVEs
• No more bug fixes, even critical ones
• No official support from the community for issues filed against 3.2

And to be clear — this isn't a CloudChef opinion or a scare tactic. It's the same versioning cadence Argo CD has followed release after release. 3.2 itself EOL'd the last 2.x line the same way. This is just how the project operates, and it's honestly one of the more predictable release policies in the CNCF ecosystem once you know the rule.

The rule to remember: whenever a new minor version ships, the version three releases back goes end of life. Bookmark that sentence — it'll save you from ever being surprised again.

---

🍳 CloudChef Recipe: Getting Off Argo CD 3.2

If you're on 3.2, here's the practical path out. Don't try to leap straight to 3.5 in one sync.

1. Confirm what you're actually running

argocd version --short

Run this against every cluster, not just the one you remember. I've seen orgs discover a forgotten dev cluster still on 2.x during this exact check.

2. Read every upgrade guide in the chain

Each minor version has its own upgrade notes with breaking changes. Don't skip versions in your reading even if you skip them in your deploy:

• 3.2 → 3.3
• 3.3 → 3.4
• 3.4 → 3.5

Pay close attention to the 3.2 → 3.3 change to Source Hydrator's cleaning behavior — it stopped auto-deleting stale files in the hydrated path. If you were relying on that cleanup, you'll need to handle it explicitly now.

3. Stage the upgrade before you touch production

Spin up a non-production Argo CD instance on 3.5, point it at a copy of your Application manifests, and let it reconcile. Watch for:

• RBAC policy drift (fine-grained permissions have evolved since 3.0)
• ApplicationSet behavior changes if you're using generators heavily
• Any custom resource exclusions you rely on

4. Upgrade, then immediately re-baseline your security posture

Once you're on 3.5, this is the moment to actually turn on mTLS for the repo-server and evaluate Source Integrity for your highest-value applications. Don't upgrade and leave the new security features off by default — that's the whole point of doing this work.

---

⚠️ Common Mistakes

• Assuming "still works fine" means "still supported" — those are different things
• Skipping the intermediate upgrade guides because "it's just a minor version"
• Turning on Source Integrity globally without a rollout plan
• Forgetting that ApplicationSet concurrency defaults may throttle previously-unlimited fan-out

---

🔥 CloudChef Pro Tip

Don't wait for the EOL announcement to check your version.

👉 Put a version check in your platform team's quarterly review, right next to your Kubernetes and cloud provider version checks. Argo CD's cadence is predictable — use that predictability instead of getting caught by it.

🔗 Continue Your CloudChef Journey

🔥 Related CloudChef Recipes

Loading related posts...

---

📚 References

• Official Argo CD Release Notes (GitHub)
• Argo CD Upgrade Guide Overview
• Argo CD mTLS Configuration Docs

---

🚀 Final Thoughts

Argo CD 3.5 isn't a release that changes how you think about GitOps. It's a release that makes the GitOps you're already doing more secure and less fragile at scale.

👉 But the feature list isn't really the story here. The story is the calendar. If you're on 3.2, the clock already ran out.

Upgrade the boring way — one minor version at a time, staged, tested. It's a lot less exciting than a 2 a.m. incident caused by an unpatched CVE on an EOL'd version. And production, as always, prefers boring.