What’s New in ArgoCD 3.2? Features, Upgrade Guide, and Installation Tips

Release Overview

ArgoCD 3.2.0 was released as a stable version on 2025‑11‑05. Version 2.14 reached end‑of‑life on 2025‑11‑04, so production clusters running 2.14 must be upgraded immediately.

Supported and Unsupported Versions

Supported: 3.2, 3.1, 3.0

Unsupported: 2.14 and earlier (no security patches or bug fixes)

Key New Features in 3.2

Enhanced ApplicationSet Progressive Sync The UI now displays the progressive‑sync status, stale applicationStatus is cleared when progressive sync is disabled, and a new status.resourcesCount field provides a count of managed resources.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-appset
spec:
  # ... your spec
status:
  resourcesCount: 150  # New field
  resources:
    - # limited list of resources

Webhook Handler Memory Optimization The webhook processor now uses an informer instead of direct API calls, reducing memory consumption in large monorepos or high‑traffic environments. Users of very large monorepos may still see repo‑server lock contention, which is targeted for fix in 3.2.1.

Updated Health Checks

Crossplane V2 resources are now supported.

ExternalSecret scripts include a refreshPolicy field.

PromotionStrategy typo corrected to avoid false‑positive alerts.

OCI Registry Improvements Layer limits are relaxed, allowing OCI registries to be used as first‑class artifacts for storing Kubernetes configuration.

CLI and Notification Fixes

CLI correctly initializes argocdService.

Webhook payload handler now recovers gracefully from panics.

Various documentation updates and bug fixes.

Upgrade Path and Migration Considerations

When upgrading from 2.14, be aware of breaking changes introduced in 3.0 (fine‑grained RBAC, health‑status persistence changes, high‑churn resource exclusion, Dex claim changes) and 3.1 (OCI registry support, CLI plugin architecture, Source Hydrator enhancements).

Recommended upgrade steps:

Read the official upgrade guide: https://argo-cd.readthedocs.io/en/stable/operator-manual/upgrading/overview/

Test in a staging environment before rolling out to production.

Backup ApplicationSet and Application resources.

Audit RBAC policies if upgrading from any 2.x release.

Monitor memory usage and webhook performance after the upgrade.

Installation Guide

ArgoCD 3.2 can be installed via Helm (recommended) or directly with kubectl.

Helm installation (adds the ArgoCD Helm repo and installs version 9.1.0 of the chart):

helm repo add argo https://argoproj.github.io/argo-helm
helm repo update
helm install argocd argo/argo-cd \
  --namespace argocd \
  --version 9.1.0

To apply custom values, add --values values.yaml.

kubectl installation (non‑HA) :

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v3.2.0/manifests/install.yaml

For a high‑availability deployment, use the HA manifest:

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v3.2.0/manifests/ha/install.yaml

After deployment, verify pods, check the image tag (should be quay.io/argoproj/argocd:v3.2.0), and access the UI (e.g., kubectl port-forward svc/argocd-server -n argocd 8080:443).

Testing Checklist

Validate that the ApplicationSet progressive‑sync status appears in the UI.

Monitor memory consumption of the webhook processor under load.

Confirm health checks for Crossplane V2 resources and ExternalSecret refreshPolicy.

Verify that existing RBAC policies function as expected.

Future Outlook

ArgoCD will continue to treat OCI registries as first‑class configuration artifacts and deepen integration with progressive delivery models. Ongoing work focuses on scalability and multi‑tenant support, positioning ArgoCD as a core component of internal developer platforms.

Conclusion

ArgoCD 3.2 is production‑ready, delivering stability, performance, and usability improvements without disruptive changes. Users on 2.14 must upgrade immediately; those on 3.0 or 3.1 face low risk but should still test, especially in large monorepo environments. The next patch release (3.2.1) will address known monorepo lock‑contention issues.