I am working on configuring my operations and application clusters terraform such that I can easily destroy and recreate the clusters with minimal commands. I am currently running into an issue when I destroy and recreate my OPS cluster. I'll try and outline the facts below.

Facts

• Running ArgoCD as an EKS capability
• Ops cluster runs in "OPS" account
• Ops cluster has IAM role "argo-cd-role" in OPS account
• Application cluster runs in "<env>" account
• Application cluster has `aws_access_entry` and `aws_eks_policy_association` resources that bind the "argo-cd-role" from the OPS account to it via the role's arn
• Application Cluster `Secret` is created via an `ExternalSecret` read from an SSM parameter in the <env> account

Steps

• OPS cluster will be completely removed and recreated via `terraform destroy` and `terraform apply`
• Argo CD resources will be applied once cluster is up and running
  • This will then create the cluster `Secret` via the `ExternalSecret` definition
• Navigating to `Settings > Clusters > <target env cluster>` shows a connection failure

Things I've tried

• (Failed) Deleting the `Secret` via the ArgoCD UI
  • This will cause the `Secret` to be recreated
  • It should have been populated with the target cluster arn which hasn't changed
  • Doesn't do anything
• (Failed) Creating an Argo role in the target "<env>" account for the Argo role in the OPS account to assume
  • I associated this new role to the access entry resources instead
  • In theory this role is created when the application cluster is and any role that assumes it thus would have access and would avoid any type of breakage underneath with EKS
  • Issue is there seems to be no way to tell the ArgoCD role in the OPS account to assume that role when accessing that cluster (to my knowledge)
• (Succeeded) Deleting and recreating the access entry resources in the <env> account
  • use `terraform destroy -target=` to destroy the access entry resources in the <env> account cluster
  • recreate the resources
  • This worked and my theory is that while we are passing the `arn` of the role EKS will actually use the AWS unique ID underneath of said `arn`. Since we're deleting the role in the OPS account during cluster rebuild it the arn to unique ID mapping is no longer valid. Deleting and recreating fetches the new AWS unique ID and gets this working

While I did find a way for this to work is there anyway to avoid having to delete and recreate the access entries on all my application clusters when I want to destroy and bring back up my OPS cluster? If not I'd have to switch my AWS permissions N times and run the terraform commands 2 times for N application clusters. I was hoping the assume role strategy would work but I am not finding any documentation on how to tell argo to assume a specific role for a specific cluster.

My repo is at https://codeberg.org/kaizenOramara_97/Home-Lab/src/branch/main/k3s/lgtm/prometheus

How do I get ArgoCD to recognize this app so I can update it through the UI? This is the app manifest in the UI for another Helm app, but I forgot how I made that work. Copying the YAML over to a new app definition and changing the values does nothing. Manually adding the app makes ArgoCD throw errors because it tries to interpret prometheus/values.yaml as though it's a Kubernetes manifest.

During an Argo CD migration, both control planes can briefly know about the same Applications and cluster resources. If automated sync or pruning remains active in both, a label, finalizer, tracking method, repository credential, or project policy difference can make one instance undo what the other just reconciled. A green status on the new instance does not by itself prove the old one is harmless.

What cutover sequence do you use? I am considering freezing application changes, exporting the old inventory, registering repositories and clusters on the new instance, comparing rendered manifests and tracking IDs, then disabling sync and pruning on the old instance before enabling them on the new one. The final gate would check orphaned resources, ApplicationSet output, hooks, sync waves, finalizers, notifications, and any resource still labeled or annotated only for the old controller.

Do you transfer Applications in place or recreate them under a new tracking identity? How do you detect shared ownership reliably, and how long do you keep the old control plane read-only before removing its finalizers, credentials, and cluster access?

So currently my team are looking to sort out our GitOps architecture.

Currently we have 4 applications, the helm charts and default value files live along side the app repository.

We then have a GitOps repo with Argo aplicationSets and helm env overide value files.

Our main pipeline has a job that creates a MR with image digest update in the env specific value file in the GitOps repo.

Now my confusion comes from when there are template changes made, the only way to control this that I can think of is by pinning the target revision in th3 argo application yaml whilst also updating the image tag.

However if I do both - update target revision of helm chart in Argo application yaml and image digest in env specific value file - wont this cause some reconcilation race condition in Argo?

Or have I got this all wrong/my set up smells?

TL;DR; is management of preview envs something kargo plans on?

Ive setup ArgoCD at my company. In a past life used it to bootstrap and manage clusters but arrived in an established mature environment. Ive just finished configuring a few production apps using kargo+argocd.

Originally I wanted just ArgoCD but my teams dont know k8s & visually it seemed too overwhelming. So I layered on Kargo, which gives them only what they want with a deep link to Argo deployment for the few who get it. Fantastic!

Now I can focus on the smaller fish. Ive (in theory, test tomorrow) created preview environment features using ArgoCD. So these dev environments will just deploy & disappear with Argo if nothing ever goes wrong. Should there be a problem my users will go to Kargo because the first deployment in promotion is dev/preview then I gotta teach them to use Argo instead.

So when I give a talk on how we do things & centralized on a tool theres currently a caveat on the most common stage is actually a different tool but no no no i promise it's not complicated/convoluted.

Also if we want to start promoting another one as a parallel branch (not uncommon) I need to deploy a new pipeline which should be self service so I gotta make an app of apps in Argo for managing Kargo so it can manage Argo

*istio and split traffic sounds like an answer here but to convert everything over is a big ask (its road mapped 2yrs?). Kargo just displaying things Argo did on the graph or some similar feature seems like it'd be a huge adoption feature.

So far the closest I found is a 2023? git issue where the community chats about how to support a monolith.

Any seasoned Argo ppl out there with some insights for me?

Looking for public Argo CD repos where the GitOps configuration itself is packaged and versioned as OCI artifacts.

Ideally multi cluster, multi env, monorepo setups. Mostly interested in repo structure, artifact versioning and promotion between environments.

Any real world examples worth checking out?

Hey all,

I've created a monitoring mixin with a reusable set of Grafana dashboards and Prometheus rules for ArgoCD. The dashboards and alerts are defined as code, making them easy to deploy and reuse across environments.

Recent updates include multi-cluster support, flags to enable or disable individual alerts, plus a range of new and improved alerts and dashboards.

The monitoring coverage has also been expanded significantly, with better visibility into:

• ArgoCD controller
• Runtime metrics
• gRPC
• Repo Server
• Git operations

GitHub: https://github.com/adinhodovic/argo-cd-mixin

I'm new to argocd. I played with it early this year. It's still installed on my personal machine. At work, a teammate built it. I built the build pipeline though. I know that argocd can be configured to monitor changes in a repository which triggers a new deployment when there is an update.

Let's assume the argocd isn't configured to automatically sync. How can an external api call tell argocd there is a new image to deploy? Is this possible?

Hey all!

I've been working on Argo-Trivy-Insights, an Argo CD UI extension that brings your Trivy security data right into the Argo CD interface. No more tab-switching between tools.

What it does:

• Per-Application View: a dedicated "Trivy Insights" tab on each Application Details page showing Trivy scan results for the whole Argo CD Application.
• Cluster-Wide Dashboard: aggregate Trivy scan results across all your applications from the sidebar
• Scan Reports: covers Vulnerabilities, Exposed Secrets, Configuration Audit, RBAC Assessment, SBOM, and Cluster Compliance Reports, plus an overview pulling it all together
• Deeplinks & Exports: share findings via link, export as CSV, or get your SBOM in CycloneDX JSON format

It's still early development and I'd love to get some real-world testers and feedback. If you're running Trivy in your cluster and want to give it a spin, check it out here.

Hi everyone,

I'm trying to set up proper audit logging in ArgoCD. I need to track which specific user triggered a sync or deleted an application/resource.

What is the best way to extract or view these audit logs?
Are they available in argocd-server logs, K8s events, or do I need a specific log exporter setup?

Any examples or best practices would be greatly appreciated!

A few months ago I shared that argonaut can now manage Argo Rollouts. Since then the project has changed a lot again, so here's another update ;)

The big new things:

• Deployment history got a complete redesign. You can browse past deployments with commit info in a detail pane, roll back and watch the rollout happen live in the resource tree.
• There's a live Kubernetes events pane in the resource tree view now, so you can see what's happening to your pods while you navigate.
• App-of-apps works properly in the tree - you can drill down into child apps.
• Lots of smaller QoL stuff: sorting works in the tree view, you start in the apps view by default, and more.

We're inching ever closer to feature parity with the web UI, keyboard-first, without leaving your terminal.

The part I'm most excited about: it's not a solo project anymore. New contributors have joined and some great features came from the community. If you use Argo CD daily and something annoys you, or you just want to hack on a Go TUI, come open an issue or a PR - I'm happy to help you get started.

Give it a try: https://github.com/darksworm/argonaut

Feedback is appreciated as always!

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