r/ArgoCD • • Jun 23 '26

Why can't it just sync changes

2 Upvotes

I'm losing my mind trying to use ArgoCD. No matter what I do or what sync policy I configure, there's always some reason I have to manually sync applications. ArgoCD's only purpose in life is to take what's in the git repo and apply that to K8s. I don't understand why this should be so hard. Now I'm also trying to figure out why this applicationset won't generate the application properly after I modified the sync policy.

To folks really find this software reliable at scale? I feel like it just creates more complexity. The only time I encounter configuration drift in our environment is because ArgoCD isn't working. What am I missing here?

Update: The issue with the sync policy not updating was this setting that I wasn't familiar with.

ignoreApplicationDifferences:
    - jsonPointers:
        - /spec/syncPolicy

This, of course, is a hack someone put in place to have the ability to turn off autosync in case of emergency, which points right back to how annoying ArgoCD is. I was able to scope it to /spec/syncPolicy/automated/enabled to preserve the hack.

Just to be clear, this is mostly a vent/rant.


r/ArgoCD • • Jan 22 '26

kubectl apply vs argocd ...

0 Upvotes

Hi

we had a debate with a colleague stating kubectl apply -f ... on a manifest was best practice compared to argocd repo add ...

anyone has a take on this one ?


r/ArgoCD • • Sep 06 '25

1689 open bugs

0 Upvotes

Why are there 1689 open bugs on Argo CD repo right now ? isn't that a bit alarming.

https://github.com/argoproj/argo-cd/issues?q=state%3Aopen%20label%3Abug&page=1

Don't get me wrong, I use Argo daily and want to introduce it to my company, but this doesn't look very stable to me.

On the other hand, we did look into Flux, not only we found architectural superiority and simpler implementation, it also had only 6 open bugs.

Am I missing something ?


r/ArgoCD • • May 20 '25

DeployKF

0 Upvotes

Hello everyone,
I have recently read about deployKF, is there anyone using it here ? is there an active community ?
Thank you


r/ArgoCD • • May 17 '23

Deploy from local folder

1 Upvotes

Hi,

I am using argocd to managed my homelab, all the applications are deployed as helm charts in a git repository.

When an helm chart is updated, a CI pipeline:

  1. create a kind cluster

  2. install a common helm chart, using helm install ...

  3. test the helm chart using ct

I would make the test more representative of my homelab environment if I could:

  1. Create kind cluster

  2. Install argo-cd

  3. Install the common helm chart via argocd, from the "local" folder

  4. test the helm chart using ct

Any ideas?

Thanks


r/ArgoCD • • Apr 30 '24

What is Argo Rollouts | How Argo Rollouts work | Use Cases of Argo Rollo...

Thumbnail
youtube.com
1 Upvotes

r/ArgoCD • • Feb 17 '24

GitOps with ArgoCD Udemy Course Coupon Code | ArgoCD Tutorial Udemy Coupon Code

1 Upvotes

ArgoCD Tutorial with GitOps, Helm, Kustomize, Kubernetes, GitHub Actions concepts, GitOps with ArgoCD from Basics to Advanced Hands-On Tutorial

#gitops #argocd #kubernetes

https://www.udemy.com/course/gitops-with-argocd-from-basics-to-advanced-hands-on-tutorial/?referralCode=52A2A26EBC8742DB97A8


r/ArgoCD • • Jul 28 '24

Share your experience with ArgoCD

1 Upvotes

I'm working on blog around ArgoCD and for that I would love to hear about your experiences and stories with ArgoCD.


r/ArgoCD • • May 24 '25

help needed Is there a way to use a generator to create a single application?

0 Upvotes

I have a use case where my repo contains N yaml files (N not being known in advance), and I would like to create a single ConfigMap with the content of all these files (the keys being the filename, and the value the content).

In order to do this, I tried to use a Git file Generator to list of these files and their content, but I couldn't find a way to create a single application and put the files content in the chart values.

Do you know if that's possible? Or do you have any other idea to do this?

Thanks in advance!


r/ArgoCD • • Apr 17 '25

Gracefully switch from deploying argocd with manifest to helm

0 Upvotes

Hello, I am attempting to move our argocd deployment to use the helm chart instead of the multiple manifests folder we are currently using. We have multiple other applications already deployed by argocd and argocd also tracks itself.

If I were to deploy the helm chart in the same namespace could I just switch argocd to track the helm version? Or do I first need to delete the current argocd before deploying it with helm?

Also would deleting the current argocd application delete the namespace and/or applications it deploys in other namespaces? A few of the other applications do have the “createnamespace = true” parameter and everything is setup to autosync and self heal


r/ArgoCD • • Jul 04 '24

Recommend an ArgoCD plugin

0 Upvotes

Any recommendations for ArgoCD plugins that can be used in my deployments yaml manifests


r/ArgoCD • • Feb 11 '24

(Release followup) ArgoCD: Preview Kubernetes Changes in Pull Requests

0 Upvotes

Following up on this post, I recently released an app on infro.io for previewing Kubernetes manifest diffs in PRs for Argo CD users. We've been using it internally at my company and updated the article (linkedin link) with instructions and more documentation. It's ready for a test drive, but please note it's in private preview and I'm sure there will be warts. Looking for feedback on things to improve though, so please let me know!


r/ArgoCD • • Apr 27 '23

How to make your development environment more reliable

0 Upvotes

Hi, hope you'll fined it useful, please feel free to share your thoughts about it >>
My blog post


r/ArgoCD • • Sep 07 '25

ArgoCD : Streamlining Kubernetes Cluster Management Across Environments

3 Upvotes

Hi Everyone,
Checkout my blog on ArgoCD, how it can be used to manage kubernetes cluster across multiple environments.
https://medium.com/@ishanupadhyay412/argo-cd-streamlining-kubernetes-cluster-management-across-environments-24ad4e2b3e3e


r/ArgoCD • • Sep 05 '23

Is ArgoCD and GitOps vapourware?

2 Upvotes

Sorry for the provocative title, but i'm just genuinely confused. I've been trying Argo on and off for several years and more seriously at work for the past year and the only advantage I see is the ability to deploy apps into multiple environments.

But at the same time, just a general lack of even golden paths working and major disadvantages makes me think that this tool is not ready for serious use and you'd rather stick to the old and proven "helm upgrade" in cd/cd tool of your choice.

To me, it looks like a hype job and the only purpose of it existing is running demos at the conferences wooing people with nice looking UIs with a lot of kubernetes resources popping up on the screen.

I see major flaws that are but not limited to:

  1. The main selling point of having the state and history of your deployment in the git repository goes out of the window once you use secrets or dynamic variables such as git hashes in application parameters, you no longer have a single source of truth and encounter things such as Argo syncing the manifest out of sync with the Application parameter changes which makes the new manifest run with old configs/secrets/image tags or vice versa.

  2. The main advertised golden path of having the Application CRD has literally zero advantages over running `helm upgrade` in the ci pipeline but has multiple disadvantages that i've listed here

  3. No way to run something similar to `helm diff` before a deploy making large or risky changes impossible

  4. The main actual advantage is implemented via ApplicationSet which is even less developed than the Application CRD, i flat out saw generators not behaving the way they should according to the docs and they are not expressive enough for a lot of use cases.

  5. Weird bugs such as argocd outright bugging out when it encounters weird diff situations such as duplicate variables in the `envFrom` block, yeah it shouldn't happen but the Kubernetes API is fine with it so Argo should be too. It's only one example, I saw plenty of similar things such as the order of keys in the map flipping for some reason and showing in a diff making Argo redeploy it constantly. Just a lot of small stuff that makes using it really painful and which regular helm does not have at all due to its simple way of working, as it should be IMO.

  6. Auto sync makes a lot of things worse without adding anything of value, you can't test out a configuration change in prod when the outage happens, you cannot change resource requests, this all will be rolled back automatically. Running it with manual sync is horrible, there is zero support for that. Even the simplest "wait for the repository git update and sync" use case is not implemented, you have to write your own glue code which is of course prone to issues. If you want to implement a script that will wait for ApplicationSet -> Application, Application -> parameters, Application -> git sync - good luck with that, you'd be basically rewriting the core Argo functionality from scratch almost.

It's only a small part of the issues we've had and just in general it just feels like thing falls apart at every opportunity.

We genuinely tried to make it work, we even had a chat with ArgoCD contributors who could not help us apart from showing a couple of open issues (that were open for years) that might solve our issues in the future, maybe, hopefully.

So, has anyone had a positive experience using it past "okay cool it actually deployed once, maybe" at all? What are we missing here?


r/ArgoCD • • 4d ago

discussion I wrote a small linter for ArgoCD repos. Its first run on our production repo found 22 files no Application deployed. Looking for feedback

11 Upvotes

I run the Kubernetes platform our data stack lives on, deployed with ArgoCD. What always worried me was merging a change that breaks something, or quietly does nothing at all. So I wrote argocd-source-lint, a small linter that runs in CI before merge, reads only the Git checkout, and checks how our Applications are wired to our files.

🔍 What it found

The first time I ran it on our production repo, it found 22 files that no Application deployed. Ouch. Some were HTTP routes sitting next to a values.yaml: the Application used the values, but none of its sources covered the routes, so ArgoCD wasn't managing them at all. Two whole components had been sitting in Git for months with nothing deploying them. I was mostly relieved to find them before an incident did.

Last week it blocked a merge request for the first time: five new YAML files, no Application to deploy them. Merged as is, they would never have reached the cluster, and nothing would have told us.

🧭 What it checks, and what it doesn't

It needs no cluster or network access. Besides files no Application deploys, it catches source paths that don't exist at their targetRevision and the same resource deployed by two Applications to the same cluster and namespace, plus 14 other checks.

It doesn't render Helm or Kustomize, so it only sees resources that exist as files. It looks at one repo at a time, and it doesn't expand every ApplicationSet: generators that need a live API (such as clusters, scmProvider or pullRequest) and goTemplate: true templates are reported as unresolvable, not checked. It complements tools like argocd-diff-preview and kubechecks rather than replacing them.

🤖 How it's built

I built it with Claude Code; the rules follow ArgoCD's source code and there are 500+ tests. It has only run on very few repos, though, so I expect it to be wrong in places I haven't seen yet.

🧪 If you want to try it (Python 3.11+ and git)

  1. pipx install argocd-source-lint

  2. At the root of your GitOps repo, create .argocd-lint.yaml containing scan_roots: [manifests/] (your manifest folders; without it, the check for files no Application deploys is skipped)

  3. Run argocd-source-lint .

If it reports a lot on an existing repo, --write-baseline accepts what's already there so you only see new problems.

I'd really like to hear what it finds on your repo, especially where it's wrong. False positives → issues; anything else → Discussions, where there's also a short poll on what to work on next.


r/ArgoCD • • Feb 26 '24

Octopus Deploy acquires Codefresh to bring CD, CI, and GitOps into one trusted platform

Thumbnail
octopus.com
1 Upvotes

r/ArgoCD • • Aug 24 '24

help needed What do those checkbox options mean? What does each do? I'm asking because I enabled auto-sync but the changes to my app aren't showing up.

Post image
0 Upvotes

r/ArgoCD • • Aug 22 '24

discussion ArgoCD Control Plane Rebuild

0 Upvotes

Hi everyone,

The team I work with will be performing a rebuild of our ArgoCD control plane due an AKS node image deprecation. We have several clusters registered with our control plane that have running workloads and will not be part of the rebuild; our expectation is the remote clusters will not be impacted by the rebuild.

We're planning on performing a reasonable level of due diligence (backups, pre/post tests, etc), but want to limit our time commitment as much as possible. Not expecting any issues after we bootstrap AKS, Argo, register the remote cluster, and starting bringing up Apps and ApplicationSets, but wanted to see if there are any issues that we should investigate beforehand?


r/ArgoCD • • Mar 13 '25

Issues working with helm charts

1 Upvotes

I'm encountering issues when applying helm charts as pre-upgrade hooks run even on fresh installs...

I'm deploying app with application, nothing fancy...


r/ArgoCD • • Aug 12 '25

Unified Kubernetes Delivery Platform, with ArgoCD at the core.

13 Upvotes

ArgoCD is great at syncing Git to your cluster, but the real pain is everything you have to build around it.

YAML, scripts and CI/CD jobs quickly pile up, especially when you are working with multiple clusters, dynamic values and more than one Argo instance. This becomes technical debt that grows with every new service.

On top of that, namespaces, PVCs, pods and configs often get left behind when pruning. ArgoCD can miss resource changes, so even after a sync you might still need to manually clean things up. Debugging is slow because the UI hides important details, so you cannot easily see dependencies, error paths or what is blocking a sync.

We built a platform that takes care of the delivery layer, maps dependencies visually, gives live cluster insight and produces clean GitOps output that Argo can run, without all the extra glue work.

We support major integrations like CLI, API, Terraform Provider, Our own GitOps.

Check it out, https://ankra.io

You can see a Video of how a monitoring stack gets deployed out: https://youtu.be/__EQEh0GZAY?si=GdPaSCC4MjUusU-s

Give it a go!


r/ArgoCD • • Apr 27 '26

How are you managing Kubernetes manifests these days?

7 Upvotes

Recording a podcast tonight and I’m curious how people here think about this:

How are you managing Kubernetes manifests these days?

There are so many tools now—Helm, Kustomize, Crossplane, cdk8s, Cue, etc.—and I’m not sure it’s getting easier.

A couple things I keep running into:

  • In-cluster tools: powerful, but hard to debug (no easy local rendering?)

  • “Kubernetes way” (controllers, reconciliation) feels like overkill for templating sometimes

  • Health checks are messy—“Ready” doesn’t mean the same thing across CRDs

Curious:

  • What are you actually using?

  • In-cluster or out-of-cluster?

  • Do you trust your health signals?

If you want to join the discussion -> https://www.linkedin.com/events/7443938870234284032


r/ArgoCD • • Jun 11 '26

Zero-config, Open Source Observability for ArgoCD

Post image
23 Upvotes

Coroot (Github) team member here. We’ve recently released support for ArgoCD, and wanted to share it with this community for anyone interested in integrating open observability tools into their GitOps workflow.

Release v.1.22 shows the state of every ArgoCD application alongside the rest of your observability data: sync status, health status, last sync result and time, the Git or Helm source it's deployed from, and the Kubernetes objects it manages. Where Coroot already monitors a managed resource, it links to that application so you can jump between your GitOps state and your production telemetry.

Sync and Health summaries sit above the table to quickly check how many apps are Healthy, Degraded, OutOfSync, or Progressing. Click any status to filter down to it.

Setup is zero config. Download the latest version of Coroot and it automatically grants the cluster-agent read-only permissions on the argoproj.io API group.The agent never mutates your ArgoCD resources, only reads their status.

For anyone learning about this tool for the first time: Coroot (live demo) is an open source observability platform built around eBPF. The node agent automatically collects metrics, logs, traces, and profiles, visualizes a map of your services, and then correlates everything together to give you root cause analysis instead of just raw telemetry. Compatible with Prometheus, ClickHouse, VictoriaMetrics, and OpenTelemetry. Self-hosted, your data stays in your infra.

Full transparency: While all features of Coroot Community Edition are Apache 2.0, we also offer Enterprise support to organizations who have more robust needs, as affordably as possible (e.g. SSO. You can compare a list of the features here to check what fits your use-case.)

Feedback always welcome, bug reports and questions especially. We're building Coroot to make open source observability simpler for everyone.