Argocd App of Apps for Mixed Workloads: Overkill or Justified
ArgoCD App of Apps can manage mixed YAML/Helm workloads but may introduce unnecessary complexity.
ArgoCD App of Apps can manage mixed YAML/Helm workloads but may introduce unnecessary complexity; evaluate against simpler tools like Keel based on team needs and scale.
Diagnosis: When App of Apps Makes Sense
App of Apps is designed for hierarchical, multi-application deployments. For a single folder with mixed YAML and Helm charts, it’s often overkill. The added abstraction introduces sync latency, RBAC complexity, and operational overhead. Use it only if you need:
- Structured dependency management across multiple apps
- Declarative Git-driven lifecycle control for nested resources
- Fine-grained sync policies (e.g., per-app health checks)
If your use case is a flat directory of resources (e.g., a few Helm charts + raw YAML), simpler tools like Keel or plain ArgoCD (without App of Apps) are better.
Workflow: Implementing App of Apps vs. Keel
For ArgoCD App of Apps
- Create root App manifest: Define the folder as a parent app with
project,sourceRepo, anddestfields. - Generate child apps: Use Kustomize to patch Helm charts and YAML files into App of Apps manifests.
- Sync:
argocd app sync --repo <repo> --path <path> - Validate: Check sync status and health via UI or
argocd app get <name>.
For Keel
- Define HelmRelease or Kustomization CRs: Create YAML files in your repo specifying resources to manage.
- Deploy Keel: Apply the operator and configure Git repository webhook.
- Sync: Keel auto-detects changes and applies updates.
Policy Example: App of Apps vs. Keel
App of Apps (Kustomize Patch)
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- helmrelease.yaml
- crd.yaml
generatorOptions:
disableNameSuffixHash: true
Keel (HelmRelease CR)
apiVersion: keel.sh/v1
kind: HelmRelease
metadata:
name: my-app
spec:
chart: ./charts/my-chart
version: 1.2.3
values:
env: dev
Tooling Comparison
| Feature | ArgoCD App of Apps | Keel |
|---|---|---|
| Sync Mechanism | Declarative GitOps | Event-driven (webhooks) |
| Learning Curve | Steep (complex RBAC, sync) | Low (CRD-based) |
| Use Case Fit | Multi-app hierarchies | Single-app automation |
| Drift Detection | Built-in | Limited (image-based) |
Tradeoffs and Caveats
- App of Apps: Adds 2-3x operational overhead (e.g., managing App manifests, sync loops). Useful for large teams with strict governance but risky for small projects.
- Keel: Lacks granular sync policies and health checks. Ideal for teams prioritizing simplicity over fine-grained control.
Troubleshooting Common Issues
App of Apps
- Sync failures: Check
argocd app sync --retryand verify Helm version compatibility. - RBAC denied: Ensure
argocdservice account hasget,listpermissions on target namespaces. - Child app drift: Use
argocd app diffto detect unapplied changes.
Keel
- Webhook timeouts: Increase
readTimeoutin Keel operator args. - Image pull errors: Verify
imagePullSecretsin HelmRelease CRs. - No sync after push: Check GitHub/GitLab webhook delivery logs.
Final Verdict
Use App of Apps only if you need its hierarchical control. For most single-folder mixed workloads, Keel or plain ArgoCD is simpler, faster, and less error-prone. Start small, and escalate complexity only when required by scale or compliance.
Source thread: ArgoCD App of Apps for a single folder with mixed YAML/Helm — overkill? Considering Keel instead

Share this post
Twitter
Google+
Facebook
Reddit
LinkedIn
StumbleUpon
Pinterest
Email