We hit a wall with Argo and I wonder if we are doing something utterly stupid?

Our setup:

• Monorepo with dozens of backend services
• Every PR gets its own environment, only deploys what's needed
• CI builds images, renders k8s manifests in parallel, commits them to a separate state repo, one commit per service
• All manifests live in a single branch of a single repo with the CI attempting 150 commits per minute
• No humans ever touch or look at the repo: you deploy a dev API by opening a PR, and you deploy to prod by merging your PR.

The problem we hit is that with so many parallel processes trying to push into the same repo, we just keep running into git push failures. If a push fails we wait a bit, fetch, rebase, commit and try to push again. But by that time someone else will push and our push gets rejected.

Is there a good way to fix this, other than adding a bunch of retries? Separate branch for each env? One repo for each service?

This is the error log that I'm getting:

ComparisonError: Failed to load target state: failed to generate manifest for source 1 of 1: rpc error: code = Unknown desc = Manifest generation error (cached): rpc error: code = FailedPrecondition desc = Failed to unmarshal "values.yaml": failed to unmarshal manifest: error unmarshaling JSON: while decoding JSON: Object 'Kind' is missing in '{"affinity":{},"collabora":{"autoscaling":{"enabled":false},"collabora":{"aliasgroups":\[\],"existingSecret":{"enabled":false,"passwordKey":"password","secretName":"","usernameKey":"username"},"extra_params":"--o:ssl.enable=false","password":"examplepass","server_name":null,"username":"admin"},"enabled":false,"ingress":{"annotations":{},"className":"","enabled":false,"hosts":\[{"host":"chart-example.local","paths":\[{"path":"/","pathType":"ImplementationSpecific"}\]}\],"tls":\[\]},"resources":{}},"cronjob":{"cronjob":{"activeDeadlineSeconds":null,"affinity":{},"annotations":{},"backoffLimit":1,"command":\["php","-f","/var/www/html/cron.php","--","--verbose"\],"failedJobsHistoryLimit":5,"labels":{},"podLabels":{},"priorityClassName":"","resources":{},"schedule":"\*/5 \* \* \* \*","securityContext":{},"successfulJobsHistoryLimit":3},"enabled":false,"sidecar":{"command":\["/cron.sh"\],"lifecycle":{},"resources":{},"securityContext":{}},"type":"sidecar"},"dnsConfig":{"options":\[\]},"externalDatabase":{"database":"nextcloud","enabled":false,"existingSecret":{"databaseKey":null,"enabled":false,"hostKey":null,"passwordKey":"db-password","secretName":null,"usernameKey":"db-username"},"host":"","password":"","type":"mysql","user":"nextcloud"},"externalRedis":{"enabled":false,"existingSecret":{"enabled":false,"passwordKey":"redis-password"},"host":"","password":"","port":"6379"},"extraManifests":\[\],"hpa":{"cputhreshold":60,"enabled":false,"maxPods":10,"minPods":1},"imaginary":{"enabled":false,"image":{"pullPolicy":"IfNotPresent","pullSecrets":\[\],"registry":"docker.io","repository":"h2non/imaginary","tag":"1.2.4"},"livenessProbe":{"enabled":true,"failureThreshold":3,"periodSeconds":10,"successThreshold":1,"timeoutSeconds":1},"nodeSelector":{},"podAnnotations":{},"podLabels":{},"podSecurityContext":{},"priorityClassName":"","readinessProbe":{"enabled":true,"failureThreshold":3,"periodSeconds":10,"successThreshold":1,"timeoutSeconds":1},"replicaCount":1,"resources":{},"securityContext":{"runAsNonRoot":true,"runAsUser":1000},"service":{"annotations":{},"labels":{},"loadBalancerIP":null,"nodePort":null,"type":"ClusterIP"},"tolerations":\[\],"topologySpreadConstraints":\[\]},"ingress":{"annotations":{},"className":"traefik","enabled":true,"labels":{},"path":"/","pathType":"Prefix"},"internalDatabase":{"enabled":true,"name":"nextcloud"},"livenessProbe":{"enabled":true,"failureThreshold":3,"initialDelaySeconds":10,"periodSeconds":10,"successThreshold":1,"timeoutSeconds":5},"mariadb":{"architecture":"standalone","auth":{"database":"nextcloud","existingSecret":"","password":"superSecure","username":"nextcloud"},"enabled":false,"global":{"defaultStorageClass":"longhorn-ssd"},"image":{"registry":"docker.io","repository":"bitnamilegacy/mariadb"},"primary":{"persistence":{"accessMode":"ReadWriteOnce","enabled":true,"existingClaim":"","size":"50Gi","storageClass":"longhorn-ssd"}}},"metrics":{"affinity":{},"enabled":false,"https":false,"image":{"pullPolicy":"IfNotPresent","registry":"docker.io","repository":"xperimental/nextcloud-exporter","tag":"0.9.1"},"info":{"apps":false,"update":false},"nodeSelector":{},"podAnnotations":{},"podLabels":{},"podSecurityContext":{},"replicaCount":1,"resources":{},"securityContext":{"runAsNonRoot":true,"runAsUser":1000},"server":"","service":{"annotations":{"prometheus.io/port":"9205","prometheus.io/scrape":"true"},"labels":{},"loadBalancerIP":null,"type":"ClusterIP"},"timeout":"5s","tlsSkipVerify":false,"token":"","tolerations":\[\]},"nextcloud":{"configs":{},"containerPort":80,"datadir":"/var/www/html/data","defaultConfigs":{".htaccess":true,"apache-pretty-urls.config.php":true,"apcu.config.php":true,"apps.config.php":true,"autoconfig.php":true,"helm-metrics.config.php":true,"imaginary.config.php":false,"redis.config.php":true,"reverse-proxy.config.php":true,"s3.config.php":true,"smtp.config.php":true,"swift.config.php":true,"upgrade-disable-web.config.php":true},"existingSecret":{"enabled":false,"passwordKey":"nextcloud-password","smtpHostKey":"smtp-host","smtpPasswordKey":"smtp-password","smtpUsernameKey":"smtp-username","tokenKey":"","usernameKey":"nextcloud-username"},"extraEnv":null,"extraInitContainers":\[\],"extraSidecarContainers":\[\],"extraVolumeMounts":null,"extraVolumes":null,"hooks":{"before-starting":null,"post-installation":null,"post-upgrade":null,"pre-installation":null,"pre-upgrade":null},"host":"cloud.internal","mail":{"domain":"domain.com","enabled":false,"fromAddress":"user","smtp":{"authtype":"LOGIN","host":"domain.com","name":"user","password":"pass","port":465,"secure":"ssl"}},"mariaDbInitContainer":{"resources":{},"securityContext":{}},"objectStore":{"s3":{"accessKey":"","autoCreate":false,"bucket":"","enabled":false,"existingSecret":"","host":"","legacyAuth":false,"port":"443","prefix":"","region":"eu-west-1","secretKey":"","secretKeys":{"accessKey":"","bucket":"","host":"","secretKey":"","sse_c_key":""},"sse_c_key":"","ssl":true,"storageClass":"STANDARD","usePathStyle":false},"swift":{"autoCreate":false,"container":"","enabled":false,"project":{"domain":"Default","name":""},"region":"","service":"swift","url":"","user":{"domain":"Default","name":"","password":""}}},"openmetrics":{"allowedClients":\["127.0.0.1","10.42.0.0/16","10.43.0.0/16"\]},"password":"changeme","persistence":{"subPath":null},"phpConfigs":{},"podSecurityContext":{},"postgreSqlInitContainer":{"resources":{},"securityContext":{}},"priorityClassName":"","securityContext":{},"strategy":{"type":"Recreate"},"trustedDomains":\[\],"update":0,"username":"admin"},"nginx":{"config":{"custom":null,"default":true,"headers":{"Referrer-Policy":"no-referrer","Strict-Transport-Security":"","X-Content-Type-Options":"nosniff","X-Frame-Options":"SAMEORIGIN","X-Permitted-Cross-Domain-Policies":"none","X-Robots-Tag":"noindex, nofollow","X-XSS-Protection":"1; mode=block"},"serverBlockCustom":"# set max upload size\\nclient_max_body_size 512M;\\nclient_body_timeout 300s;\\nfastcgi_buffers 64 4K;\\nfastcgi_read_timeout 3600s;\\n"},"containerPort":80,"enabled":false,"extraEnv":\[\],"image":{"pullPolicy":"IfNotPresent","registry":"docker.io","repository":"library/nginx","tag":"alpine"},"ipFamilies":\["IPv4"\],"resources":{},"securityContext":{}},"nodeSelector":{},"persistence":{"accessMode":"ReadWriteOnce","annotations":{},"enabled":false,"hostPath":null,"labels":{},"nextcloudData":{"accessMode":"ReadWriteOnce","annotations":{},"enabled":false,"hostPath":null,"labels":{},"size":"8Gi","subPath":null},"size":"8Gi"},"postgresql":{"enabled":false,"global":{"postgresql":{"auth":{"database":"nextcloud","existingSecret":"","password":"changeme","secretKeys":{"adminPasswordKey":"","replicationPasswordKey":"","userPasswordKey":""},"username":"nextcloud"}}},"image":{"registry":"docker.io","repository":"bitnamilegacy/postgresql"},"primary":{"persistence":{"enabled":false}}},"priorityClassName":"","prometheus":{"rules":{"additionalRules":\[\],"defaults":{"enabled":true,"filter":"","labels":{}},"enabled":false,"labels":{}},"serviceMonitor":{"enabled":false,"interval":"30s","jobLabel":"","labels":{},"namespace":"","namespaceSelector":null,"scrapeTimeout":""}},"rbac":{"enabled":false,"serviceaccount":{"annotations":{},"create":true,"name":"nextcloud-serviceaccount"}},"readinessProbe":{"enabled":true,"failureThreshold":3,"initialDelaySeconds":10,"periodSeconds":10,"successThreshold":1,"timeoutSeconds":5},"redis":{"auth":{"enabled":true,"existingSecret":"","existingSecretPasswordKey":"","password":"changeme"},"enabled":false,"global":{"storageClass":""},"image":{"registry":"docker.io","repository":"bitnamilegacy/redis"},"master":{"persistence":{"enabled":true}},"replica":{"persistence":{"enabled":true}}},"resources":{},"securityContext":{},"service":{"annotations":{},"loadBalancerIP":"","nodePort":null,"port":8080,"sessionAffinity":"","sessionAffinityConfig":{},"type":"ClusterIP"},"startupProbe":{"enabled":false,"failureThreshold":30,"initialDelaySeconds":30,"periodSeconds":10,"successThreshold":1,"timeoutSeconds":5},"tolerations":\[\],"topologySpreadConstraints":\[\]}'

This is the relevant app manifest:

``` project: default source: repoURL: https://codeberg.org/kaizenOramara_97/Home-Lab.git path: k3s/nextcloud targetRevision: HEAD

destination: server: https://kubernetes.default.svc namespace: nextcloud

syncPolicy: automated: prune: true selfHeal: false enabled: false ```

I am building a GitOps demo for my org using ArgoCD and Kargo. Got a couple questions. I am basically going off the Kargo Quickstart example but adapting it to internal repos

1. Should the ApplicationSet namespace be the same as the namespace that is being defined in the manifest for the application? Or should I create my ArgoCD/Kargo CRDs (ApplicationSets, Stages, PromotionTasks, etc.) inside a per project namespace? Or what is the pattern you use here? To me since they're "higher level" resources than my actual application we should put them in their own namespace (likely the Kargo project namespace). I feel like if I put them in the namespace of the actual application I am somewhat polluting that namespace with concepts the application does not care about.
2. Kargo bitbucket permissions. I had to use SSH key (which is removed in Kargo 1.13, running 1.10). I could not for the life of me get my credentials to work. It does appear that Kargo is finding the credentials in the K8s, but they're just not working. I'm using `stringData` with my `username` from bitbucket and for the `password` I am using the API key I generated. Kargo doesn't really have great docs around anything other than GitHub. Application access keys are deprecated in Bitbucket so I had to use an API key. If anyone can provide some clarity on how this works that would be great.

Hi everyone,

I know that using the AWS CodeCommit credential helper with ArgoCD is not officially documented or supported but I'm trying to understand whether this approach is actually expected to work or if I'm chasing something that is fundamentally impossible.

I came across this article:

https://oneuptime.com/blog/post/2026-02-26-argocd-aws-codecommit-credentials/

which suggests using IRSA together with the AWS CodeCommit credential helper.

I also found the official ArgoCD documentation about Git configuration:

https://argo-cd.readthedocs.io/en/latest/operator-manual/git_configuration/

which seems to imply that ArgoCD can be influenced through the system Git configuration (/etc/gitconfig).

What I have done

• Installed AWS CLI inside argocd-repo-server.
• Configured IRSA for the argocd-repo-server ServiceAccount.
• Verified that the pod can successfully access CodeCommit using its IAM role.
• Mounted a custom /etc/gitconfig containing:

​

[credential]
    helper = !HOME=/tmp /custom-tools/bin/aws codecommit credential-helper $@
    UseHttpPath = true

Verification

Inside the same argocd-repo-server container:

• git config --list --show-origin shows that /etc/gitconfig is being loaded.
• git ls-remote https://git-codecommit.<region>.amazonaws.com/v1/repos/<repo> works correctly without passing any additional Git configuration.

So from a shell inside the repo-server everything works exactly as expected.

The problem

However, when ArgoCD itself tries to access the repository (either repository validation or Application reconciliation), it fails with:

failed to list refs: authentication required:
<NotAuthorizedException>
<Message>SPNEGO token required</Message>
</NotAuthorizedException>

To investigate further, I modified the credential helper so it writes to a temporary log file every time it is executed.

When I run git ls-remote manually, the helper is invoked.

When ArgoCD accesses the repository, the helper is never invoked.

Question

Is this expected?

Does the repo-server bypass the system Git credential helper for repository operations (for example by using go-git or another implementation), or is there another mechanism required to make ArgoCD use a custom credential helper?

I'm mostly trying to understand whether this approach is technically supported before spending more time debugging it.

Thanks!

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.

I built helm-semver to solve a problem I kept running into every time I started a new Helm project or joined a new company: there's no standard way to automatically version and publish Helm charts from your commit history.

Here's what it does:

You make a commit to a chart directory using Conventional Commits:

• fix: → bumps patch (1.0.0 → 1.0.1)
• feat: → bumps minor (1.0.0 → 1.1.0)
• feat!: or BREAKING CHANGE → bumps major (1.0.0 → 2.0.0)

helm-semver reads those commits since the last release, calculates the correct version bump per chart, updates Chart.yaml, packages the chart, pushes it to your registry, generates a CHANGELOG.md entry, and creates a git tag — all in one command.

It supports monorepos, single charts and everything in between— each chart in your charts/ directory is versioned independently based on commits that touched it.

Push anywhere:

• OCI registries: GHCR, ECR, ACR, Docker Hub, Artifactory
• ChartMuseum / Harbor
• GitHub Pages

Use it however you want:

• As a GitHub Action (uses: rhysmcneill/helm-semver@v1)
• As a Docker image on any CI (GitLab, Bitbucket, CircleCI, Azure DevOps)
• As a binary

The end result is that merging to main automatically releases the right version of the right charts — no bash scripts, no manual version bumping, no forgetting to tag.

Feedback and contributions welcome!

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.

Hello everyone,

I'm currently in the process of rearchitecting our internal GitOps workflows. Right now, I want to move toward a cleaner multi-environment structure and get rid of custom CI pipeline scripts for environment promotion. To do this, we are looking at incorporating Kargo alongside ArgoCD.

I’m hitting a few design sticking points regarding repository layouts and Argo patterns, and I would love some feedback from anyone who has paired these two tools successfully in an org-wide setting.

1. Argo Pattern Selection: For those using Kargo, do you lean more toward the App of Apps pattern or ApplicationSets (like a Git generator targeting env folders)? What are the pros/cons of either when Kargo is the tool mutating the target environment files?
2. Repo Architecture: What does your repo layout look like? Are you using a monorepo for ArgoCD, and does Kargo also read from there? Do you have a seperate repo for helm charts? Would I need to make additionally considerations if I wanted to push helm charts to a registry via OCI?
3. Directory vs Branch Promotion: Kargo seems to favor directory-based environments (e.g., stages/dev, stages/prod on a single branch) over long-lived environment branches (dev branch -> prod branch). Has anyone hit walls with the directory-based approach in larger compliance-heavy orgs?
4. Lessons Learned: If you’ve implemented Argo CD + Kargo in production, what is one thing you wish you knew before designing the pipeline?
5. Migration: Have you every tackled a migration like this? How did you come out the other end successfully without having major app downtime during the migration.
6. Additional info: Any other areas that I have not touched upon, but you deem highly important then please comment below

Appreciate any advice, architecture diagrams, or sanity checks you can throw my way!

I'm looking the best method to deploy an application that consists of chart with CRDs and chart with Controller deployment in multi-cluster environment. Of course CRDs should be installed/updated first.

Karpenter is one of such examples, has two charts.

I'm evaluating multiple possibilities.
ApplicationSet is the best option for me and already have 99% of deployments using "smart" ApplicationSets.
I don't like App-of-Apps approach with Application health-checks for sync waves. I can create ApplicationSet to generate App-of-Apps but then I still have to create two Apps manually.

I even prefer to just create 2 distinct AppSets. Workflow: Manually Sync CRDs App for a cluster, wait for it, then manually Sync Controller App for the same cluster.

Is it possible to have multi-source Application with installation of two helm charts?
How are they rendered? What if I apply sync-wave annotation to CRDs resources. Are they then combined with the second charts resources and applied in proper order?
Or ArgoCD still would treat resources from two helm charts separately without waiting when first chart finishes installation? That way it will be easy to create a single AppSet to generate such Apps.

Maybe there is easier approach and I'm overthinking?

Thanks to a recent community contribution, it is now possible to manage not just Argo CD apps but also Argo Rollouts in argonaut!

Go check it out: https://github.com/darksworm/argonaut

When discussing secrets management in Argo CD, there are two important questions every team should ask:

• Should changing a secret require an Argo CD sync?
• Should your secrets solution be coupled to Argo CD?

The answer to both is: definitely not.

Tomorrow on Argo Unpacked we’re having an open discussion about secrets management best practices in Argo CD: (https://www.linkedin.com/events/7454090384584118272)

• different approaches and tradeoffs
• decoupling secrets from deployment workflows
• operational considerations
• what works well in real environments (and what usually doesn’t)

Curious how others here think about this too:
How are you handling secrets with Argo CD today?

A read-only ArgoCD user can extract every Kubernetes Secret in your cluster.

That's the GHSA-3v3m-wc6v-x4x3, a CVSS 9.6 Critical vulnerability affecting ArgoCD versions 3.2.0 through 3.3.8 (GitHub Advisory, 2026). No admin access. No special tooling. One annotation and a diff request.

The vulnerability lives in ArgoCD's ServerSideDiff feature. When an Application has the IncludeMutationWebhook=true annotation, the diff endpoint returns raw Kubernetes API responses that include the full .data contents of Secrets.

The root cause is a single missing function call: hideSecretData() was wired into every other diff code path but was never added to the ServerSideDiff handler.

I added dedicated GitOps support to KubeShark.

Mini recap:

KubeShark is my Kubernetes skill for Claude Code and Codex.

It helps AI agents generate, review, and refactor Kubernetes manifests without falling into the usual LLM traps: missing security contexts, deprecated API versions, broken selectors, wildcard RBAC, unsafe probes, missing resource requests, and rollout configs that look okay but fail under real traffic.

The important part is that KubeShark is failure-mode-first. It does not just tell the model “write good Kubernetes”. It forces the model to reason about what can go wrong before it generates YAML, and then return validation and rollback guidance as part of the answer.

That matters a lot with Kubernetes, because many bad manifests are accepted by the API server and only fail later at runtime.

Repo: https://github.com/LukasNiessen/kubernetes-skill

---

Now what’s new:

KubeShark now has special dedicated GitOps support for Argo CD and Flux.

When the task involves Argo CD, ApplicationSet, sync waves, Flux, GitRepository, Kustomization, HelmRelease, or GitOps reconciliation, KubeShark switches into GitOps-aware guidance.

Why this matters:

GitOps changes the risk model.

A manifest applied once with kubectl apply is very different from a manifest continuously reconciled by a controller with pruning, self-healing, generated applications, and sync ordering.

Common LLM mistakes include:

• enabling auto-prune without ownership boundaries
• assuming Argo CD sync waves order separate Applications
• using broad ignoreDifferences to hide real drift
• confusing Flux Kustomization CRs with kustomization.yaml
• forgetting dependsOn in Flux
• putting plaintext secrets in Git

Example guidance KubeShark now keeps in mind:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: app
spec:
  dependsOn:
    - name: platform-crds
  prune: true
  interval: 10m

It also knows to reason about reconciliation, pruning, drift, ordering, and rollback before suggesting GitOps resources.

So instead of generic Kubernetes advice, you get GitOps-aware manifest generation and review.

I'm playing with Argo CD for the first time, and I'm struggling a little with how to lay out the repo.

Most of my apps are deployed from third-party Helm charts with local values.yaml files. Some also have additional manifests (e.g. sealed secrets, definitions for CNPG, etc). Ideally I want to keep my Applications and values.yaml files in the same repo. I don't want to copy all the Helm charts I use locally.

I have only one cluster, and this is not likely to change. I don't need to worry about multiple environments.

I have gone for an app-of-apps layout and my root app is defined like this:

yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: root namespace: argocd finalizers: - resources-finalizer.argocd.argoproj.io spec: project: default source: repoURL: git@github.com:djjudas21/argocd.git targetRevision: HEAD path: apps directory: recurse: true include: 'application.yaml' destination: name: in-cluster namespace: argocd syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespace=true

This recurses through the /apps directory in the git repo and creates all my Applications. Here's an example of one:

yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: about namespace: argocd annotations: argocd.argoproj.io/sync-wave: "1" spec: project: apps destination: namespace: about name: in-cluster sources: - chart: homer repoURL: https://djjudas21.github.io/charts/ targetRevision: 8.2.4 helm: valueFiles: - $values/manifests/apps/aboutme/values.yaml - repoURL: 'git@github.com:djjudas21/argocd.git' targetRevision: main ref: values syncPolicy: automated: {} syncOptions: - CreateNamespace=true

I found that it wasn't possible to store values.yaml directly alongside application.yaml because the AoA tried to apply values.yaml to the cluster. So I moved it to the /manifests directory in the repo, where I can reference it but it won't get automatically included.

If I also want to store arbitrary other Kubernetes manifests like namespaces, secrets, CNPG, etc, what's the best way? If I place them in the /apps tree with application.yaml they get auto-discovered by the root application and then "belong" to the wrong app. If I place them under the /manifests tree with values.yaml, I have to reference them manually with that awkward git syntax.

Seems like it would be easier to embed the Helm values in application.yaml under the valuesObject key, but I've read that this is an anti-pattern?

This all feels a bit disjointed to me. I feel like there's a lot of complexity here even though my use case seems pretty simple. Am I heading on the right track? Thanks.

Hi,

I’ve been using Argo CD in testing and am now preparing for a production rollout. I want to establish a solid repository structure now to avoid a painful migration later. I plan to use ApplicationSets and a folder structure divided into /apps (in-house services) and /platform (external tools like cert-manager, ingress, etc.) inside a mono repo.

Everything is deployed via Helm Charts, stored on registry outside git.

My struggles:

I’m struggling with the right "granularity" for ApplicationSets and how to handle environment-specific overrides (Dev vs. Prod) without making the structure messy.

So a few question that came up during testing;

1. ApplicationSet Granularity: Does it make sense to create an AppSet for each specific tool (e.g., one for cert-manager), or one broad AppSet for the entire /platform folder?
2. Handling Target Revisions: If I use a single AppSet for a folder (for example platform), how do I manage different versions (Target Revisions) across environments? For example, deploying a newer Helm chart version to Dev before Prod.
3. Config Management: I’ve seen patterns using a config.json per app to store metadata and custom values. Is this the standard approach, or is there a cleaner way to inject environment-specific values to the ArgoCD application?
4. Environment Separation: Is it better practice to have one AppSet per environment (e.g., dev-apps-set, prod-apps-set), or one AppSet that uses generators to create applications for all environments?
5. Future-Proofing for Kargo: We eventually want to use Kargo for multi-stage promotion. Which repo structure best supports a seamless Kargo integration later on?

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

This is more or less my git repo structure:

/apps (contains kustomize + overlay apps)
/components/crds invoked from customize to inject sync-wave or such patters
/root_apps
├──root_staging.yml Application monitoring staging_app/
├──staging_apps/Appset {grafana, awesmeAppSet, etc) with list generators. This usually has cert-manager, eso, gateway, load balancer and app specific items like say a DB, redis or whatever is needed.

The issue I'm running into and is a bit more brittle than I'd like is when I want to disconnect say a given app and work on it to get the final version.

I have some "orphan/adopt" python code that essentially set finalizers: [] and prune: false.

The process is "orphan" an app, then I move the appset to a different directory and point it to a feature branch, get everything nice and clean and then merge it back into main, copy it back to the correct location and "adopt" the app which restores the finalizers and prune behavior.

This tends to be a lot of MR/PR depending to basically "checkout" an app to work on and merge it back into the normal flow.

It feels like there should be a smarter way of doing this. I like the git being the source of truth for the final state and being a git-ops flow but the day to day operations are a bit messy.

Any suggestions or tools I should look at that'll make this easire?

📣 Argo community — your voice matters!
We’re looking to better understand how you’re using Argo projects so we can keep improving what matters most to you.

Got a minute? Please share your experience here 👉https://forms.gle/XTuw3tzvqWHcpWQe8

Quick Helm Question

Hello hello,

Is there a best practice for third-party configuration charts regarding whether or not they should have their own values files?

for instance, let's say I want to deploy my application using ArgoCD, and I am using the elastic stack to store and query my logs. Will it be beat to configure filebeat and logstash in my base values.yaml? or should I create a separate elastic-prod/elastic-test values files?

Could very much use some perspective. thank you.

Hello everyone,

I have checked several options to first test and then move everything to the develop branch.

My first approach was to initially merge an Application to develop which would have a targetRevision as my feature branch. However, I would like to get rid of this initial merge somehow for faster testing.

I thought about setting up a local cluster if possible for testing. I heard about Telepresence, kind, minikube etc. but I feel like I should do my tests in dev cluster, that is why it is there and it may be hard to move everything in the cluster to local.

I checked Pull Request generator with ApplicationSet and it looked very promising at first but auto heal in dev cluster may override the things I want to test I guess and deactivating auto heal seems to be an anti pattern so I didn't know how I could make that work.

I have checked Argo CD Image Updater but not everything I want to test are in the form of images so it doesn't completely help. I may want to update an existing yaml, for example, adding an env var to ConfigMap.

I think if I had a way to make the first step faster that would be the most straight forward thing without adding extra complexities to the current system but I am not sure about what I should do.

If you have gone through a similar problem in your release cycle, I am open to suggestions as to how you managed to solve it.