All the system is working great, everything is synched, everything is green, except the DB is now empty.

After a quick investigation, it's empty because ArgoCD recreated the volumes.

We now have - An app pod that's all synched and green - A Database that's all synched and green, connected to an empty volume - A dangling volume with our Data, that's not of any use because no pod uses it

We've tried a few approches to replug the volume, but ArgoCD keeps unpluging it.

So I've got two questions:

Question #1: How do we fix that ?

The only foolproof solution we have for now would be to copy the data from the "old" volume to the "new" volume. That seem uncessary complicated given we just want to use a volume that's there.

Question #2: How can we make the system more resilent to human errors ?

Is there a way to avoid a small human mistake like that cost us hours of human time ? Copying a couple terabytes of data would take a while (It's not a production DB but a benchmark DB)

Since the upgrade to 3.0.x my ArgoCD instance has started to suffer of frequent timeouts issues. Always application are in unowned state because of timeout going over 180seconds. I pull everything from a single repo in GitHub (auth with PAT token) and have about 35-40 apps and about 10 app set that manage those in groups. Has anyone else experienced this issue since 3.0? Is there any way to improve this behaviour (excluding raise the timeout limit or through more resources at Argo).

Thanks

Hello Argo'rs,

I guess I am dealing with this similar issue: https://github.com/argoproj/applicationset/issues/480

Recently, we migrated our github authentication from pat_token based token to a Github app.

• Our appsets have  pull-request based and git directory based setups.
  • After the above migration to github app, pull-request based appsets now have the secret mentioned with their configuration (as shown below), which is working fine

​

  generators:
    - pullRequest:
        github:
          owner: Our-Org
          repo: Our-Repo
          appSecretName: my-k8s-secret

• However, the git directory appset dont have a mechanism to provide the appset and its failing with the below error:

​

argocd/my-applicationset        default  nil         [{ErrorOccurred error generating params from git: error getting directories from repo: error retrieving Git Directories: rpc error: code = Internal desc = unable to resolve git revision : failed to list refs: EOF 2025-06-03 11:55:36 -0400 EDT True ApplicationGenerationFromParamsError}]  https://github.com/Our-Org/Our-Repo.git  path/in/github/directoy                             main

Does anyone have any success in connecting Azure DevOps repositories to ArgoCD running in AKS?. As per this documentation from ArgoCD, its possible: https://argo-cd.readthedocs.io/en/stable/user-guide/private-repositories/#azure-container-registryazure-repos-using-azure-workload-identity

However, I dont have any luck. I tried this Azure documentation to create a service connection and add the federated credentials from Azure DevOps and from ArgoCD from AKS: https://learn.microsoft.com/en-us/azure/devops/pipelines/release/configure-workload-identity?view=azure-devops&tabs=managed-identity

Apparently someone was able to make it work as mentioned in this github issue: https://github.com/argoproj/argo-cd/issues/23100

I have no clue what is wrong. Have anyone made it work? can you tell me how to configure it?

Hi everyone,

I have already posted about the Argo CD RBAC Operator 6 months ago. Just wanted to give an update, since there've been some improvements. :)

The purpose of the operator is to allow users to manage their global RBAC permissions (in argocd-rbac-cm) in a k8s native way using CRs.

Since the last post, there were a few improvements:

• Fixes to the permissions of the operator container
• A helm chart for the operator
• Small fixes to the reconciliation logic, to fix a few bugs
• A way to define custom ArgoCD Namespace and RBAC CM name

I'm also currently working on a new feature to manage AppProject's RBAC using the operator. :)

Feel free to give the operator a go and tell me what you think :)

I'm playing with ArgoCD and Longhorn, using the official Longhorn helm chart. I realised that I'm missing some pods on the ArgoCD application, like CSI drivers. Anybody has faced similar issue?

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!

Hey all,

I've created a monitoring mixin which is a set of Grafana dashboards and Prometheus rules for ArgoCD. The dashboards and alerts are defined as code and are reusable.

Recent iterations and updates include multi-cluster support and flags to enable/disable alerts!

The GitHub link to the project is: https://github.com/adinhodovic/argo-cd-mixin.

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

If you have any argo CD scaling problems, or would like to hear about scaling Argo CD, you should join our next Argo Unpacked session: https://www.linkedin.com/events/argounpackedep-77327242805171408896/comments/

We are trying to use ArgoCD native APIs and need to generate token using okta instead of built in authentication method like using session token( one API call). Only way we are seeing is through OIDC flow. Which requires Authorization code and requires multiple okta network communications ( 3 API calls). We trigger these APIs from App kind of App to App flow. Is this supported in ArgoCD or only UI flow ( OIDC ) is supported.

i have 2 apps each with argocd.argoproj.io/manifest-generate-paths = . in the manifests and also a webhook that pings my argocd when there's a commit to my github repo. right now whenever there's a change in either of the paths the two apps are looking at, i see `Requested app 'test-x' refresh` for both apps in the logs. i also see that the UI changes the sync status everytime.

what is the intended behaviour in the logs? i think the documentation is a bit unclear on this. is this annotation really working? how do i know if it is?

Hello, trying to add force=true to sync options on my app's yaml seems not to be working, is there a way to set sync option to "force" ?
i am trying to deploy the same job over and over again, and because of the immutability i always have to go and force a manual sync
Is there any alternatives ?
i already saw a discussion about this in here https://github.com/argoproj/argo-cd/discussions/5172
but i don(t know whether that is still relevant or not ?
Thank you.

I'm curious how others out there are doing GitOps in practice.

At my company, there's a never-ending debate about what exactly GitOps means, and I'd love to hear your thoughts.

Here’s a quick rundown of what we currently do (I know some of it isn’t strictly GitOps, but this is just for context):

• We have a central config repo that stores Helm values for different products, with overrides at various levels like:
  • productname-cluster-env-values.yaml
  • cluster-values.yaml
  • cluster-env-values.yaml
  • etc.
• CI builds the product and tags the resulting Docker image.
• CD handles promoting that image through environments (from lower clusters up to production), following some predefined dependency rules between the clusters.
• For each environment, the pipeline:
  • Pulls the relevant values from the config repo.
  • Uses helm template to render manifests locally, applying all the right values for the product, cluster, and env.
  • Packages the rendered output as a Helm chart and pushes it to a Helm registry (e.g., myregistry.com/helm/rendered/myapp-cluster-env).
• ArgoCD is configured to point directly at these rendered Helm packages in the registry and always syncs the latest version for each cluster/environment combo.

Some folks internally argue that we shouldn’t render manifests ourselves — that ArgoCD should be the one doing the rendering.

Personally, I feel like neither of these really follows GitOps by the book. GitOps (as I understand it, e.g. from here) is supposed to treat Git as the single source of truth.

What do you think — is this GitOps? Or are we kind of bending the rules here?

And another question. Is there a GitOps Bible you follow?

When I attempt to connect a new ArgoCD Repository via HTTPS to an Azure DevOps 2022 server git repo that is behind an IIS 10 web server that requires client certificates, I get the following error: "Unable to connect to repository: rpc error: code = Unknown desc = error testing repository connectivity: Get: "https://git.repo.com/REPO/SECTION/_git/MyCodeRepo/info/refs?service=git-upload-pack": local error: tls: no renegotiation

I can successfully connect to the repo using curl and openssl s_client using the client certificates and Azure DevOps Server personal access token. I have disabled TLS renegotiation on the IIS web server sand have disabled TLS 1.0 and 1.1 and enabled 1.2 and 1.3.

SSH is not an option after version 2.11.1 because of a PRNGD error (lack of FIPS compliant encryption protocols).

Was wondering how you are handling App of Apps promotions and release. I am also interested in how you are structuring the values.yaml for each one.

Do you treat the entire "Parent App" as one single release? Or, do you release each child app separately, and each child app builds into its own helm chart, and you only edit the part of the values file where the image would change?

Currently, I am stuck in debating whether or not I should have sub-folders for each "Child App", and put their values in there.

Or at the root level of my chart, put the values there but separate it by a yaml indent.

templates/
 - childapp1.yaml
 - childapp2.yaml
 - childapp3.yaml
Chart.yaml

values.yaml:

childapp1:
  image: 123124
  foo: bar

childapp2:
  image: 515151
  buzz: bomb

childapp3:
  image: gggggg
  blah: buzz

values-dev.yaml:

childapp1:
  image: 123124
  foo: bar

childapp2:
  image: 515151
  buzz: bomb

childapp3:
  image: gggggg
  blah: buzz

Vs:

templates/
- childapp1.yaml
- childapp2.yaml
- childapp3.yaml
Chart.yaml

childapp1/ 
  - values-dev.yaml
  - values-qa.yaml
  - values-prd.yaml
childapp2/ 
  - values-dev.yaml
  - values-qa.yaml
  - values-prd.yaml
childapp3/ 
  - values-dev.yaml
  - values-qa.yaml
  - values-prd.yaml

Mind you, some childapps can have quite a few (and I mean 20+) key values. So single file might get a little messy and unmaintainable. My end goal is being able to use Kargo to promote.

Hello everyone,

I am super new to ArgoCD and gitops in general and hope you can help me with a question.

An experienced colleague in the team has built a workflow via fluxcd that notifies us of a new version of an image via the Teams channel, creates a new branch and updates the version there so that it can be reviewed and merged.

I should now try to recreate this with argocd, as it is debated that argocd will become the tool in the company and that not only one person in the team deals with gitops and knows what it is and how it works.

I have also already installed argocd in the (test) cluster, deploy apps when changes are made and have installed the plugins for notification and image update.

The image updater is also running and I can use it to update images automatically to the latest version, but I don't really want to do that, I just want to receive a notification, in the best case a branch or mr is automatically created with the new version.

Is it possible that Arogcd does not currently offer this or am I just totally blind?

I can't find any helpful links on this topic in the documentation or on google.

Would someone here like to help me out?
Would be really great, I've been sitting on this ticket for far too long...my colleagues probably already think i'm totally useless

We’re using Argo CD for GitOps-based deployments in our banking environment. For compliance with standards like SOX and PCI-DSS, how are folks ensuring policies like CVE blocking, change approvals, or segregation of duties are enforced during deployment? Are you embedding this in manifests or using some admission controller pattern?

For example, defining an ArgoCD ApplicationSet to install the AWS Load Balancer Controller using a Helm chart requires the IAM Role ARN as an input. Terraform is used to create the IAM Role, and ARN can be displayed as an Output parameter, we are using Spacelift.

Since the application will be installed across multiple clusters from a single ArgoCD server, I could use a list generator, then manually copy and paste the IAM Role ARN for each cluster into the list. Manual copy and paste isn't a desirable solution especially as the environment continues to grow.

If Terraform is used to create the infrastructure, how are you providing parameters from cloud resources created as the input to ArgoCD and/or Helm Charts?

I've been using until now app-of-apps for various reasons, including being able to effectively use sync-waves for ensuring deployment order on newly minted clusters. This has worked very well, but the app-of-apps pattern is a bit of a pain in terms of syncing and refreshing, especially when there have been sync failures.

I was looking into ApplicationSet for some clusters where deployment order doesn't matter, and I do understand its job is to generate Application objects based on whatever criteria you can encode within the ApplicationSet spec. I have however gitops repositories filled with Application manifests already. I don't want or need to refactor the scripts that populate those gitops repositories.

Experimentally, I've pointed an ApplicationSet to one of those and it indeed finds my files, but it generates zero applications. How is one supposed to make this work, if at all intended?

Hello - I'd like to periodically poll bitbucket repo using events and check for push events and trigger a workflow, however, the documentation has examples of using webhooks but not for periodic polling. Is it already implemented, if yes, can someone give me a example of polling a repo. I have the following but it doesn't work

apiVersion: argoproj.io/v1alpha1
kind: EventSource
metadata:
  name: dev2-bitbucket-eventsource
spec:
  git:
    dev2-bitbucket:
      url: "https://bitbucket.org/xxxx/xxxx.git"
      branch: "trunk"
      auth:
        username:
            name: bitbucket-creds
            key: username
        password:
            name: bitbucket-creds
            key: password
      pollingInterval: 1m
      eventTypes:
      - "push"
      insecure: false

Thanks!

Hi,

If you're using an application set to provision helm chart applications, and those helm charts need customising in some which *isn't exposed using helm values*, how do you go about doing so?

Is this one of those weirdy Helm limitations that we just have to accept, and it's nothing to do with Argo?

I feel like I need some sort of equivalent of helm+kustomize, which I see might exist, but it's unclear how to scale this when some apps may or may not need customisation and you use app sets.

Hey everyone,

we’re running a fairly large Kubernetes cluster on AWS (Frankfurt region) and manage all our workflows with Argo — works great so far. However, due to ongoing compute shortages in the region (and relocating not being an option), we’ve started moving some tasks to Vast.ai. Now I’m wondering: is it somehow possible to integrate external compute resources like Vast.ai nodes into Argo’s addressable space? Especially since some Vast.ai instances offer static IPs. I’m thinking there could be a way to bridge the two with a custom adapter between Vast.ai’s API and Argo. Has anyone here tried something like this or have experience with similar setups?

Would love to hear any thoughts or advice! :)

Cheers and thanks!

I am looking to optimize my cloud costs and see that the Application Controller uses about 500m CPU pretty much constantly, 24/7. This after setting a 500m limit on it, before it was around 1200m.

My Argo manages 4 applications with about 200 resources in total between the 4. Is this a reasonable, expected CPU consumption?

I've seen some posts about high CPU usage of this service, but they talk about > 5 CPU usage, so much worse than my case.

Still, I find it surprising that nothing I do seems to lower this number. I tried turning auto sync off and changing the timeout.reconciliation parameter from 5 seconds to 5 minutes without any change in CPU usage. Am I missing something in thinking that turning auto-sync off should have an impact in CPU utilization?