// the find
flux-subsystem-argo/flamingo
Flux Subsystem for Argo
Flamingo wraps ArgoCD with a Flux reconciliation backend, so Flux Kustomizations and HelmReleases show up in the Argo UI with full sync status. It's for teams that already have Flux doing the actual reconciliation but want ArgoCD's UI and ApplicationSet machinery on top. The 'loopback' trick is clever: ArgoCD thinks it owns the app, but Flux actually drives the cluster state.
1. The loopback reconciliation approach is architecturally sound — Flux owns the desired state, ArgoCD just reads and reports it, so you're not fighting two reconcilers. 2. OCI repository support comes for free since it inherits Flux's source controller, which Argo CD native still handles inconsistently. 3. The CLI (`flamingo generate-app`) makes it practical to adopt incrementally: point it at an existing Flux object and get an Argo app without rewriting manifests. 4. Container image is a drop-in replacement for the equivalent ArgoCD tag, so upgrading Argo doesn't require a separate migration process.
1. The project is explicitly seeking sponsorship to survive — last push was November 2024, the README leads with a funding plea, and with 44 forks that's a thin contributor base for something sitting in your control plane. 2. Multi-cluster support only handles static credentials (client certs/keys); EKS, GKE, and anything using exec-based auth requires manual secret creation, which is most real-world fleets. 3. You're now on a custom ArgoCD image maintained by a small team, meaning CVE patches depend on Flamingo maintainers backporting them — the README claims this is fast, but with the current staffing situation that's optimistic. 4. No clear story for what happens to your cluster if the project goes unmaintained and you need to upgrade Kubernetes or ArgoCD — you'd need to migrate back to pure Flux or pure Argo.