Argo CD v3.4: What’s New for GitOps Workflows

Argo CD v3.4 arrived with a stack of features that address real pain points in day-to-day GitOps operations. From Helm value file management to cluster-level reconciliation control, this release focuses on making multi-environment, multi-cluster deployments smoother and more predictable. The series has already progressed through several patch releases, with v3.4.4 shipping in mid-June, so the code is well-tested in production. Here’s a walkthrough of the changes that matter most.

Helm Value File Glob Patterns

One of the most practical additions in v3.4 is wildcard glob support for Helm valueFiles. Before this release, you had to enumerate every overlay file explicitly in your Application or ApplicationSet manifests. In environments with many team-specific or feature-flag overlays, that meant long, brittle lists that had to be updated every time someone added a new values file.

Now you can use glob patterns directly:

spec:
  source:
    chart: my-app
    repoURL: https://charts.example.com
    targetRevision: 2.5.0
    helm:
      valueFiles:
        - values.yaml
        - base/redis.yaml
        - "envs/production/*.yaml"
        - "teams/**/*.yaml"

This picks up all YAML files matching the pattern at reconciliation time. If a new team overlay lands in the repo, it gets picked up automatically without touching the Argo CD configuration. It’s a small change that eliminates a surprising amount of toil in environments with many value overlays.

Pausing Reconciliation Per Cluster

There are situations where you need to stop Argo CD from touching applications on a specific cluster temporarily — maybe the cluster is being drained for maintenance, undergoing an upgrade, or experiencing issues that make reconciliation disruptive. Previously, you had to either scale down the controller or manually disable sync on every individual application targeting that cluster.

v3.4 introduces the argocd.argoproj.io/application-cluster-ignore annotation for cluster Secrets:

apiVersion: v1
kind: Secret
metadata:
  name: staging-cluster
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
  annotations:
    argocd.argoproj.io/application-cluster-ignore: "true"
type: Opaque
data:
  # ... cluster credentials

When this annotation is set, Argo CD skips reconciliation, cache warming, and cluster info updates for every application targeting that cluster. The cluster still appears in argocd cluster list and API responses — it’s not removed, just paused. Remove the annotation when you’re ready to resume.

ApplicationSet Cache Synchronization

If you manage more than a hundred applications through ApplicationSets, you may have noticed the informer cache occasionally falling behind the Kubernetes API server. This desync can trigger spurious application re-creations, flooding the cluster with unnecessary rollout activity. v3.4 adds application cache synchronization in the ApplicationSet controller to keep the informer cache in line with the live cluster state. The practical effect: fewer phantom diffs and more stable reconciliation at scale.

Session Token Management

For automation scripts and CI pipelines that interact with Argo CD’s API, the new argocd account session-token command simplifies token management:

argocd account session-token
# Outputs a JWT token for the current session

argocd account session-token -o json
# Returns structured output with issuer, username, and expiry

This is useful when you need a short-lived token for scripted operations — automated rollbacks triggered by alerts, bulk application syncs from scheduled jobs, or integration with external orchestration tools.

OpenTelemetry Tracing for Authentication

v3.4 extends OpenTelemetry instrumentation to cover OIDC authentication flows and token cache operations. If you’ve already enabled OTEL tracing in your Argo CD deployment, this addition gives you visibility into the latency and error rates of authentication-related code paths — useful for diagnosing login delays in environments with complex SSO setups.

Bug Fixes Worth Noting

The bug fixes in v3.4 address several issues that have frustrated operators:

JWT revocation on logout. Previously, logging out of the Argo CD UI didn’t invalidate the JWT token in Redis. That meant an OIDC or Dex token could remain valid until it expired naturally, even after an explicit logout. Tokens are now properly invalidated in Redis on logout, closing a security gap.

Monorepo ls-remote throttling. Applications configured for automatic sync on monorepos triggered excessive git ls-remote requests — one per application, on every reconciliation loop. The fix applies forced ref resolution only to manual syncs, letting automatic syncs use cached refs. If you’re running auto-sync with monorepo source repos, expect a noticeable drop in Git server load.

Rollback preserving sync policy. Performing a rollback from the UI previously wiped out the entire syncPolicy.automated block, effectively disabling auto-sync. The UI now toggles automated.enabled to false for the rollback while preserving the rest of the sync policy configuration. After the rollback completes, re-enabling auto-sync is a single click instead of reconfiguring the entire policy.

ApplicationSet namespace isolation. In multi-Argo CD deployments, updating a cluster Secret could trigger reconciliation on ApplicationSets in namespaces that weren’t allowed. This has been fixed — the controller now correctly filters by allowedNamespaces when processing cluster secret changes.

Upgrade Considerations

If you’re upgrading from v3.3 to v3.4, the most important change to be aware of is the cluster version format. Following a change in how Helm interprets Kubernetes cluster versions, Argo CD now aligns with that behavior. ApplicationSets using Cluster Generators with the argocd.argoproj.io/auto-label-cluster-info annotation need to switch to argocd.argoproj.io/kubernetes-version using the vMajor.Minor.Patch format instead of the old Major.Minor format. Review the upgrade guide for the full migration steps.

Also note that Argo CD v3.1 has reached end-of-life with the v3.1.16 release. If you’re still on v3.1, plan your upgrade path to v3.4.

Getting Started

To install or upgrade to v3.4:

kubectl create namespace argocd
kubectl apply -n argocd --server-side --force-conflicts \
  -f https://raw.githubusercontent.com/argoproj/argo-cd/v3.4.4/manifests/install.yaml

The v3.4 series is at four patch releases and counting, with the latest being v3.4.4. The feature set is mature, and the bug fix track record is solid — a good time to upgrade if you’ve been waiting for the initial patch wave to settle.

For the full changelog and upgrade documentation, visit the v3.4.4 release page on GitHub and the official Argo CD documentation.