
The Argo CD community is thrilled to announce Argo CD v3.3. This release delivers some long-awaited and highly anticipated features and improvements.
Let’s dive into what makes this release special.
PreDelete Hooks
PreDelete Hooks has been a highly anticipated feature request in Argo CD. With v3.3, it’s finally here.
PreDelete hooks allow you to execute Jobs or other resources before Argo CD removes your application’s resources. Think of it as the missing piece in the application lifecycle puzzle — you’ve had PreSync, Sync, PostSync, and now you have PreDelete.
Until now, cleaning up before deletion required workarounds — external scripts, manual intervention, or hoping your finalizers would do the trick.
apiVersion: batch/v1
kind: Job
metadata:
name: cleanup-job
annotations:
argocd.argoproj.io/hook: PreDelete
spec:
template:
spec:
containers:
- name: cleanup
image: alpine
command: ["sh", "-c", "echo 'Running pre-delete cleanup...'"]
restartPolicy: Never
In the example we define a Job with the PreDeleteannotation. When the Application that owns this job is deleted, Argo CD first creates and runs this cleanup Job and waits for it to successfully complete. Only after the Job finishes does Argo CD proceed to delete the rest of the Application’s resources. If the Job fails the deletion is blocked.
Shoutout to @pedro-cs-ribeiro for making this happen!
OIDC Background Token Refresh
One of the most upvoted issues in Argo CD history has finally been resolved. Users integrating Argo CD with OIDC providers like Keycloak have long been frustrated by getting logged out after just 5 minutes — the typical access token lifespan even while actively working in the UI.
With this PR Argo CD now automatically refreshes OIDC tokens in the background before they expire. A new refreshTokenThreshold configuration option lets you specify when the server should proactively refresh tokens based on their remaining lifetime. This means no more unexpected logouts mid-workflow across Keycloak other OIDC providers.
Thanks to @devopsjedi for implementing this long-awaited quality-of-life improvement!
Source Hydrator Levels Up
The Source Hydrator has been one of the most actively developed features in Argo CD v3.x, and v3.3 brings a wave of improvements that make it more powerful and flexible than ever.
- Inline Parameter Support: No more committing parameter files for every configuration change! With inline parameters, you can pass values directly during hydration. (by @sangyeong01)
- Better Monorepo Support: This brings significant improvements for monorepo workflows with source hydrator. (by @pbhatnagar-oss)
- Performance Improvements: Source hydrator now avoids unnecessary repo-server calls, making the hydration process faster and more efficient. (by @pbhatnagar-oss)
ClusterResourceWhitelist Now Supports Resource Names
One of the most upvoted RBAC feature requests has finally landed in v3.3.
Until now, clusterResourceWhitelist in AppProjects could only restrict access by API group and kind. If you allowed access to CustomResourceDefinitions, you allowed access to all CRDs. There was no way to say “this project can only manage these specific CRDs.”
With this feature, you can now limit cluster resource access to specific resource names:
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: my-project
spec:
clusterResourceWhitelist:
- group: apiextensions.k8s.io
kind: CustomResourceDefinition
resourceNames:
- crd1.example.com
- crd2.example.com
Shoutout to @crenshaw-dev for implementing this long-awaited feature!
Ability to use shallow clone for repositories
This feature allows Argo CD to fetch only the required commits instead of the entire repository history, reducing git fetch times from minutes to seconds for large repositories. Users can now add a depth flag when adding a repository to enable the shallow clone.
argocd repo add <repo-url> --depth
Thanks @alexmt for this long awaited feature
KEDA Gets First-Class Support
If you’re using KEDA (Kubernetes Event-driven Autoscaling), this release is for you.
- Pause Actions for ScaledObject and ScaledJob: You can now pause and resume KEDA resources directly from the Argo CD UI. This gives operators fine-grained control over autoscaling behavior — perfect for maintenance windows, debugging, or controlled rollouts.
- ScaledJob Health Checks: Argo CD now understands KEDA ScaledJob health status, so you’ll see accurate health indicators instead of generic “Unknown” states.
Big thanks to @rickbrouwer for KEDA support in Argo CD!
ApplicationSet Progressive Sync is now in Beta
Progressive Sync enables staged ApplicationSet updates by syncing Applications in defined groups and advancing only after health checks pass. This reduces blast radius when deploying or deleting changes across large fleets.
Thanks @ranakan19 for all your work on this feature!
Other Notable Changes
Here are some other improvements that made it into this release:
- Redis credentials via volume mount — More secure credential management — @Mangaal
- Ceph CRD health check — Monitor your Ceph storage cluster health directly in Argo CD — @afarbos
- UI: Implement abstraction layer for appset UI support — First step towards the full AppSet UI — @pjiang-dev
- CLI: Filter by API group — @sabre1041
- Configurable K8s API timeout — @ppapapetrou76
- Enable forks to release to custom quay registries — @reggie-k
- UI: Split refresh button with dropdown for hard refresh — @choejwoo
- UI: Conditionally render app view extensions — @jwinters01
- Actions: Add icons to apps actions — @rickbrouwer
- pprof endpoints for application set — @rumstead
- PullRequest merge action — @crenshaw-dev
- And many more …
Where Can I Get It?
For installation instructions and the full changelog, check out the release notes.
We’d love to hear your feedback! Find us on the #argo-cd channel in CNCF Slack to share your experience, report issues, or just say hi.
A massive thank you to everyone who contributed to this release — whether through code, reviews, documentation, or testing. The Argo community continues to amaze us!
<hr /><p>Argo CD 3.3 Release Candidate was originally published in Argo Project on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>