<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/one-hub-34-clusters-lessons-from-a-gitops-control-plane-at-scale-dtajzlazo" -->

---
title: One Hub, 34 Clusters: Lessons From a GitOps Control...
description: A single Argo CD hub managed GitOps across 34 clusters spanning 22 AWS accounts and one Oracle Cloud tenancy, built on a repository of 174 Helm charts...
canonical: https://daily.dev/posts/one-hub-34-clusters-lessons-from-a-gitops-control-plane-at-scale-dtajzlazo
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: One Hub, 34 Clusters: Lessons From a GitOps Control Plane at Scale | daily.dev
og:description: A single Argo CD hub managed GitOps across 34 clusters spanning 22 AWS accounts and one Oracle Cloud tenancy, built on a repository of 174 Helm charts...
og:url: https://daily.dev/posts/one-hub-34-clusters-lessons-from-a-gitops-control-plane-at-scale-dtajzlazo
og:image: https://api.daily.dev/og/posts/dtAjZLAZO.png
og:image:alt: One Hub, 34 Clusters: Lessons From a GitOps Control Plane at Scale
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# One Hub, 34 Clusters: Lessons From a GitOps Control Plane at Scale

**[Cloud Native Now](https://daily.dev/sources/cloudnativenow)** · 6 min read · 0 upvotes · 0 comments

## Summary

A single Argo CD hub managed GitOps across 34 clusters spanning 22 AWS accounts and one Oracle Cloud tenancy, built on a repository of 174 Helm charts rendering 1,214 Argo CD Application objects. Each cluster was reduced to a contract file of about twenty keys, from which IAM roles, DNS and Application assignments were all derived. CI rendered every chart against every cluster contract on each merge request and posted the manifest diff for review. Out-of-band drift dropped from 24.3 incidents a month to 0.9 after instrumenting it, and mean cluster onboarding fell from 4.0 days to 1.7 hours. ApplicationSets were set to preserve resources on deletion and clusters got a no-prune setting so a bad commit couldn't cascade into deleting running infrastructure.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://cloudnativenow.com/contributed-content/one-hub-34-clusters-lessons-from-a-gitops-control-plane-at-scale>

## Questions this post answers

### How do I prevent Argo CD ApplicationSets from deleting resources when I remove an entry from the generator?

Configure every ApplicationSet to preserve deployed resources on deletion, which stops removing an entry from the generator list from cascading into deletion of the resources it created. Pairing this with a no-prune setting on cluster objects means reverting a bad commit cannot delete a running cluster, keeping reconciliation blast radius proportional to the risk.

_Anyone running GitOps at fleet scale can compare safe-deletion patterns like this via daily.dev._

### How should I structure per-cluster configuration when managing dozens of Kubernetes clusters with GitOps?

Reduce each cluster to a single contract file of about twenty keys covering identity, account boundary, region, environment, API access, DNS and certificate delegation, and opt-outs, then derive everything else (IAM roles, Applications, Cluster API identity, cost tags) from that file. This made adding a cluster to a fleet as simple as a label change, with matrix generators handling the fan-out.

_Engineers designing multi-cluster GitOps contracts can track patterns like this on daily.dev._

### What onboarding time can GitOps automation achieve for adding a new Kubernetes cluster to a fleet?

Mean onboarding time dropped from 4.0 days across eight manually built clusters to 1.7 hours across eleven clusters after a GitOps cutover, measured from merge to first successful sync. The process required creating IAM roles once in Terraform, writing a cluster values file, opening a merge request so CI rendered the full dependency graph and diff, then merging and labeling the registration.

_Teams benchmarking cluster onboarding speed can follow real GitOps results like this on daily.dev._

## Similar posts on daily.dev

- [GitOps for 15,000\+ Clusters: What Large-Scale Testing with vCluster Taught Us](https://daily.dev/posts/gitops-for-15-000-clusters-what-large-scale-testing-with-vcluster-taught-us-abazxodax) · ITNEXT · 3 upvotes · 1 comments
- [Scaling GitOps: The "pull" architecture for global fleets](https://daily.dev/posts/scaling-gitops-the-pull-architecture-for-global-fleets-erfzm1dhn) · Red Hat Developer · 2 upvotes · 1 comments
- [How Okta Scaled From 12 to 1,000 Kubernetes Clusters With Argo CD](https://daily.dev/posts/how-okta-scaled-from-12-to-1-000-kubernetes-clusters-with-argo-cd-ubu9m5djc) · The New Stack · 1 upvotes · 0 comments
- [DevOps isn’t enough: GitOps strategies for regulated multicloud deployments](https://daily.dev/posts/devops-isn-t-enough-gitops-strategies-for-regulated-multicloud-deployments-qabg3ggfw) · All Things Open · 3 upvotes · 0 comments
- [GitOps Implementation at Enterprise Scale, Moving Beyond Traditional CI/CD](https://daily.dev/posts/gitops-implementation-at-enterprise-scale-moving-beyond-traditional-ci-cd-dn84xij98) · SD Times · 0 upvotes · 0 comments

---

Tags: [#kubernetes](https://daily.dev/tags/kubernetes), [#gitops](https://daily.dev/tags/gitops), [#argocd](https://daily.dev/tags/argocd)

[View this post on daily.dev](https://daily.dev/posts/one-hub-34-clusters-lessons-from-a-gitops-control-plane-at-scale-dtajzlazo)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"One Hub, 34 Clusters: Lessons From a GitOps Control Plane at Scale","url":"https://daily.dev/posts/one-hub-34-clusters-lessons-from-a-gitops-control-plane-at-scale-dtajzlazo","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/one-hub-34-clusters-lessons-from-a-gitops-control-plane-at-scale-dtajzlazo"},"datePublished":"2026-10-27T18:50:15.734Z","dateModified":"2026-10-27T18:55:34.124Z","description":"A single Argo CD hub managed GitOps across 34 clusters spanning 22 AWS accounts and one Oracle Cloud tenancy, built on a repository of 174 Helm charts...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/e73e2f63576dabdda12880ed7a60c82c?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/e73e2f63576dabdda12880ed7a60c82c?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Cloud Native Now","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Cloud Native Now","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/8acc1ecd93ce4299b615252f32d78de5","url":"https://daily.dev/sources/cloudnativenow"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/one-hub-34-clusters-lessons-from-a-gitops-control-plane-at-scale-dtajzlazo","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"kubernetes,gitops,argocd","timeRequired":"PT6M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Cloud Native Now","item":"https://daily.dev/sources/cloudnativenow"},{"@type":"ListItem","position":3,"name":"One Hub, 34 Clusters: Lessons From a GitOps Control Plane at Scale"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/one-hub-34-clusters-lessons-from-a-gitops-control-plane-at-scale-dtajzlazo#faq","mainEntity":[{"@type":"Question","name":"How do I prevent Argo CD ApplicationSets from deleting resources when I remove an entry from the generator?","acceptedAnswer":{"@type":"Answer","text":"Configure every ApplicationSet to preserve deployed resources on deletion, which stops removing an entry from the generator list from cascading into deletion of the resources it created. Pairing this with a no-prune setting on cluster objects means reverting a bad commit cannot delete a running cluster, keeping reconciliation blast radius proportional to the risk. Anyone running GitOps at fleet scale can compare safe-deletion patterns like this via daily.dev."}},{"@type":"Question","name":"How should I structure per-cluster configuration when managing dozens of Kubernetes clusters with GitOps?","acceptedAnswer":{"@type":"Answer","text":"Reduce each cluster to a single contract file of about twenty keys covering identity, account boundary, region, environment, API access, DNS and certificate delegation, and opt-outs, then derive everything else (IAM roles, Applications, Cluster API identity, cost tags) from that file. This made adding a cluster to a fleet as simple as a label change, with matrix generators handling the fan-out. Engineers designing multi-cluster GitOps contracts can track patterns like this on daily.dev."}},{"@type":"Question","name":"What onboarding time can GitOps automation achieve for adding a new Kubernetes cluster to a fleet?","acceptedAnswer":{"@type":"Answer","text":"Mean onboarding time dropped from 4.0 days across eight manually built clusters to 1.7 hours across eleven clusters after a GitOps cutover, measured from merge to first successful sync. The process required creating IAM roles once in Terraform, writing a cluster values file, opening a merge request so CI rendered the full dependency graph and diff, then merging and labeling the registration. Teams benchmarking cluster onboarding speed can follow real GitOps results like this on daily.dev."}}]}
```

