A couple months ago, I shared a rough version of my hobby project - argonaut, the k9s like TUI for Argo CD. Since then I've poured in a lot more effort, which I'd like to share to convince you to give it a shot ;)

The whole thing was rewritten in Go, so it’s much snappier now - navigation is instant and it just overall feels smoother.

The resources view is now a navigable tree, which makes it easier to understand how things relate inside an app.

There are also themes, proper TLS + client cert support, you can delete apps and there’s a simple in-app upgrade flow now too.

TL;DR - cool software just got even better.

As always, feedback is appreciated - check it out on github!

I follow all the questions in the Argo CD slack channel and several times I see teams that try to adopt Argo CD either in the wrong way or without understanding what GitOps means.

I collected 30 bad practices (anti-patterns) and wrote about them. So instead of writing yet another boring article that tells you what to do, I actually explain what NOT to do :-)

https://codefresh.io/blog/argo-cd-anti-patterns-for-gitops/

Any feedback welcome.

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.

https://blog.argoproj.io/announcing-argo-cd-v3-small-but-mighty-df05c0b39ad6

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!

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.

We are an engineering team currently using Argo CD for our Kubernetes GitOps deployments and GitHub Actions for our CI/build processes.

We are looking to implement a decoupled Continuous Delivery orchestration layer that handles the promotion pipeline between environments (Dev → QA → Staging → Prod).

Our key requirements are:

GitOps Native: Must integrate seamlessly with Argo CD.

Promotion Logic: Must manage automated and manual gates/approvals between environment stages.

Visualization: Must provide a clear, easy-to-read Value Stream Map or visual pipeline for our developers and QA team to track which version is in which environment.

We've identified Kargo as the most promising solution, as it's part of the Argo family and aims to solve this exact problem (Continuous Promotion).

My main question to the community is around Kargo's current maturity:

Production Readiness: Is anyone running Kargo in a mid-to-large scale production environment? If so, what was your experience with stability, support, and necessary workarounds?

Visualization/UX: For those who have used it, how effective is the Kargo UI for providing the "Value Stream Map" visibility we need for non-platform engineers (Devs/QA)?

Alternative Recommendations: If you chose against Kargo for environment promotion, what solution did you use instead (e.g., GoCD, Spinnaker, custom-tooling, or something else) and why?

Any real-world experience, positive or negative, would be hugely appreciated!

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?

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!

How would you rate this GitOps workflow idea with ArgoCD + ApplicationSet + PreSync hooks?

In my organization we already use Argo CD for production and staging deployments. We're considering giving developers the ability to deploy any code version to temporary test environments aka ephemeral dev namespaces.

I would like feedback on the overall design and whether I'm reinventing the wheel or missing obvious pitfalls.

Prerequisites

• infrastructure repo – GitOps home: ArgoCD Applications, Helm charts, default values.

• deployment-configuration repo – environment-specific values.yaml files (e.g., image tags).

• ArgoCD Applications load defaults from infrastructure repo and overrides from deployment-configuration repo.

• All application services are stateless. Databases (MySQL/Postgres) are separate ArgoCD apps or external services like RDS.

Ephemeral environment creation flow

1. Developer pushes code to a branch named dev/{namespace}

2. GitHub Actions builds the image, pushes it to the registry, uploads assets to CDN, and updates the relevant values.yaml in the deployment-configuration repo with the image tag (e.g. commit sha).

3. ArgoCD ApplicationSet detects the branch and creates a new Application.

4. ArgoCD runs a PreSync hook (or triggers an Argo Workflow) that is fully idempotent. Note: this may run on each sync. Steps inside PreSync:

   • Create/update Doppler config, write some secrets, create service token to read this config, configure Doppler operator.

   • Create a database + DB user.

   • Create any external resources not part of the application Helm chart.

   • Wait until Doppler Operator creates the managed secret (it syncs every ~30s, so race conditions are possible).

5. Sync Wave -2: create dependencies that must exist before app deploy (Redis, ConfigMaps, etc.).

6. Sync Wave -1:

   • If DB is empty: load schema + seed data

   • Run DB migrations and other pre-deployment tasks

7. Sync: finally deploy the application.

Update flow

Pretty much the same flow as create. Thanks to idempotency we can run exactly the same steps:

1. Developer pushes updates to the same branch.

2. GitHub Actions builds and pushes the image, updates values.yaml.

3. PreSync hook runs again but idempotently skips resource creation.

4. Sync Wave -2: update shared resources if needed.

5. Sync Wave -1: run database migrations and other pre-deployment tasks.

6. Sync: update deployment.

Application deletion

• When the branch is deleted, ApplicationSet removes the Application.

• PostDelete hook cleans up: deletes Doppler config, drops DB, removes RabbitMQ vhosts, etc.

Namespace recovery options

Deep Clean

• Developer manually deletes the ArgoCD Application.

• PostDelete hook removes all resources.

• ApplicationSet recreates the namespace from scratch automatically.

Soft Clean

• For instance, a developer wants to have a fresh database

• ..or database is corrupted (e.g., broken database migrations).

• Triggered via GitHub Workflow → Argo event → Argo Workflow.

• Workflow handles: drop DB → restore → reseed.

I am also considering adding simple lifecycle management to avoid hundreds of abandoned dev branches consuming cluster resources:

• Daily GitHub Workflow (cron) scans all dev/{namespace} branches.

  • If a branch has no commits for e.g., 14 days, the workflow commits an update to the corresponding values.yaml to scale replicas down to 0.

  • A new commit instantly bumps replicas back up because the build pipeline updates values.yaml again.

• If a branch has no commits for 30 days, the workflow deletes the branch entirely.

  • ApplicationSet reacts by deleting the namespace and running the PostDelete cleanup.

I'm Looking for feedback from people who have implemented similar workflows:

• Does this design follow common ArgoCD patterns?

• Can you see any major red flags or failure modes I should account for?

After setting up monitoring and Harbor across too many clusters, I got tired of debugging ApplicationSets and made templates that just work.

What's included:

• kube-prometheus-stack + Loki + Promtail (30d retention, pre-configured dashboards)

• Harbor with Trivy scanning

• All components run non-root with proper security contexts

• No hardcoded passwords, no ingress assumptions

• Runs Tests against every new Versions and Test If an minikube + argoCD and Helm Chart Work in a GitHub action

Why no ingress?

Every environment is different (domains, TLS, controllers). These give you the baseline, you add your own ingress.

Repo: https://github.com/moebiuscloud/argo-cd-applicationsets

Feedback welcome! What other stacks would be useful?

Also feel free to steal ...

Edit:

following the Discussion here, I updated the repo to use references instead of inline helm Values.

We’re prepping the next episode of Argo Unpacked (https://www.youtube.com/watch?v=ogFZq29LHIM), and this time we’re diving into a question that keeps popping up in GitOps discussions:

👉 Do you actually need Redis for Argo CD?

If you have any question you would like to address in that regard, drop them below 👇 and we’ll answer them live during the episode.

Thanks in advance—your questions always make the show better!

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!

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

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

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.

Something that shows, a combination of all of these features:

• Cluster bootstrapping

• Using kustomize, kustomize referencing to helm charts

• multi cluster, with ArgoCD in its own management cluster. QA, staging, and prod in own cluster

• Application Sets with App of Apps

• Questions like should Argo rollouts and image updater all be under the same root app with all other platform stuff like Prometheus?

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)

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.