Standalone/Headless mode without ArgoCD dependency

[nissessenap]

First of all, congratulations on version 1.0.

I manage multiple ArgoCD instances across different clusters, and some of them don't have internet access.
So the image updater doesn't have access. to write back changes to git.
But I have external resources that I can push in like Git and new container images.

So I would like a centralized image updater that:

1. Watches container registries for new image versions
2. Updates YAML/values files in Git repositories
3. Let each cluster's ArgoCD instance handle the sync independently

Currently, Image Updater requires ArgoCD Application resources to function, even when using Git write-back mode. This makes centralized management across multiple ArgoCD instances impractical.

I know this is mentioned as one of your limitations, but I'm wondering if you would be willing to remove that limitation?

Proposed Solution

A "headless" mode where image tracking configuration is defined independently (via CRD or config), without requiring ArgoCD Applications. The updater would:

• Read image update rules from a standalone config/CRD
• Watch specified registries for updates
• Commit changes directly to Git
• Not require access to ArgoCD APIs or Application resources

Challenges I Understand

• Current design reads app.Status.Summary.Images to know what's deployed
• Headless mode would need to read from Git to keep track of the current status, and assume it's correct
• Would require a new configuration schema to replace Application-derived settings

What would this solve?

This would also solve the problem of cronjobs or other applications that also scales to 0 like Keda would start to get image update without having to wait for ArgoCD to report which version that is currently running.

What are your thoughts around this?

[chengfang]

Thanks for considering argocd-image-updater in your work. What you're describing is an interesting challenge, but does not align well with current argocd-image-updater design. Our future plan will continue to focus on improving the current CRD-based architecture and configuration to better support workflow centered around argocd.

[nissessenap]

That is what I expected. Thanks for your quick answer.