Argo CD 3.4: Practical GitOps Patterns for Production Kubernetes

GitOps has moved past the hype phase and into production maturity. If you’re running Kubernetes at scale, the question isn’t whether to adopt GitOps — it’s which tooling and patterns make it reliable. Argo CD, the CNCF-graduated declarative delivery tool for Kubernetes, just shipped version 3.4 with several features that directly address pain points teams hit in real deployments.

Let’s walk through the most impactful changes and how they fit into practical GitOps patterns you can apply today.

Helm ValueFiles Get Glob Support

One of the most requested features for Helm-heavy shops is finally here. Argo CD 3.4 supports glob patterns in valueFiles, which means you no longer need to enumerate every environment-specific override file by hand.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-service
  namespace: argocd
spec:
  source:
    repoURL: https://github.com/org/charts
    targetRevision: main
    helm:
      valueFiles:
        - values.yaml
        - envs/production/*.yaml
  destination:
    server: https://kubernetes.default.svc
    namespace: production

Previously, every new override file required updating the Application manifest. In environments with per-team or per-region overrides, this was a constant source of drift. With glob patterns, new files are picked up automatically on the next reconciliation. If you’re running a monorepo with envs/us-east/*.yaml, envs/eu-west/*.yaml, and similar structures, this removes an entire class of manual configuration work.

Pause Reconciliation Without Removing Clusters

Hybrid Kubernetes topologies are increasingly common — you might have an Argo CD instance managing clusters directly while also using the argocd-agent for edge deployments. The problem: sometimes you need a cluster registered in the inventory without the controller actively reconciling against it. The old workaround was to remove the cluster entirely and re-add it later, which is error-prone and loses configuration.

Argo CD 3.4 introduces a simple annotation-based mechanism:

apiVersion: v1
kind: Secret
metadata:
  name: edge-cluster-secret
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
  annotations:
    argocd.argoproj.io/application-cluster-ignore: "true"
type: Opaque
data:
  name: ZWRnZS1jbHVzdGVy
  server: aHR0cHM6Ly9lZGdlLmV4YW1wbGUuY29t
  config: # ...

With this annotation, the cluster remains visible in argocd cluster list and API responses, but the controller skips reconciliation, cache warming, and cluster info updates for it. When you’re ready to bring it back online, remove the annotation. This is particularly useful during cluster maintenance windows or when running blue-green cluster migrations.

ApplicationSet Cache Synchronization

If you use ApplicationSets to generate applications from Git directory structures or cluster lists, you may have hit a frustrating bug: with 100+ applications in a set, the controller’s watch-based cache could fall behind between reconciliation cycles. The symptom? Argo CD attempts to re-create applications it just created, causing reconciliation failures and noisy alerts.

v3.4 adds active cache synchronization in the ApplicationSet controller. Instead of relying solely on the informer cache, the controller now actively syncs with the API server during bulk application operations. Here’s a practical pattern that benefits directly from this fix:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: services
  namespace: argocd
spec:
  generators:
    - git:
        repoURL: https://github.com/org/infra
        revision: main
        directories:
          - path: services/*
  template:
    metadata:
      name: '{{path.basename}}'
    spec:
      source:
        repoURL: https://github.com/org/infra
        targetRevision: main
        path: '{{path}}'
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{path.basename}}'
      project: default
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

This Git directory generator pattern is one of the most scalable ways to manage dozens or hundreds of microservices. With the cache synchronization fix, it now handles rapid bulk changes — like onboarding 50 services at once — without reconciliation storms.

Session Tokens for Automation

SSO users have long faced an awkward gap: logging in via argocd login with OIDC or Dex works fine interactively, but extracting that session for scripts or CI pipelines required fragile workarounds. v3.4 adds argocd account session-token, which outputs a bearer token you can capture and use in automation:

First, log in interactively via SSO:

argocd login argocd.example.com --sso

Then extract the token:

argocd account session-token

The output is a JWT. Pass it in the Authorization header of API requests to automate Argo CD operations from CI pipelines or custom scripts. Add the -o json flag to get structured output with issuer, username, and expiry — useful for token rotation logic.

OpenTelemetry Tracing for Authentication Flows

Observability in Argo CD has progressively improved, and v3.4 extends OpenTelemetry tracing to cover the full OIDC authentication flow. If you have an OTel collector configured, you’ll now see traces for SSO session handling and token cache operations alongside your existing sync and reconciliation spans.

This matters because authentication issues are among the hardest to debug in GitOps setups. When users report intermittent login failures or slow dashboard loads, the traces give you concrete data on where time is spent — whether it’s the IdP, the token cache in Redis, or the Dex middleware.

Notable Bug Fixes Worth Knowing About

Several fixes in this release address issues you may have encountered without realizing they were bugs:

JWT token revocation on logout — Tokens are now invalidated in Redis on logout, so a logged-out token cannot be reused. This closes a security gap affecting OIDC, Dex, and admin tokens.
Excessive ls-remote on monorepos — A commit to a monorepo with many auto-syncing applications could trigger a git ls-remote call per source per application. Forced ref resolution now applies only to manual syncs, not automatic ones.
Rollback no longer wipes sync policy — Triggering a rollback from the UI previously nulled out the entire syncPolicy.automated object. The UI now toggles automated.enabled instead, preserving settings like prune.
ApplicationSet namespace isolation — In multi-ArgoCD deployments sharing a cluster, cluster Secret updates triggered reconciliation across all ApplicationSets in all namespaces, ignoring allowedNamespaces. This is now correctly filtered.

Upgrade Considerations

Argo CD v3.4 ships with an important change following Helm’s shift in Kubernetes version interpretation. ApplicationSets using Cluster Generators with argocd.argoproj.io/auto-label-cluster-info on cluster Secrets need to update to use argocd.argoproj.io/kubernetes-version with the full vMajor.Minor.Patch format instead of the previous Major.Minor format. The upgrade guide has the details.

v3.1 has reached end of life as of May 6, 2026 — if you’re still on that series, upgrade to a supported version (v3.2, v3.3, or v3.4) to continue receiving security updates.

Putting It Together

The v3.4 release continues the pattern of incremental, production-focused improvements rather than headline-grabbing rewrites. Glob patterns for Helm values, cluster pause annotations, and ApplicationSet cache synchronization are all features that emerged from real operational pain. If you’re running Argo CD in production, these changes reduce toil and improve reliability — which is exactly what GitOps tooling should do.

The official Argo CD GitHub repository has the full changelog and installation manifests. The documentation covers all features in detail, including the ApplicationSet patterns discussed above.