u/Metozz

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?