How to scale GitOps without maxing out
Note: This was originally published on Jan. 12, 2026, and has been updated with information from the live event.
When Argo CD v1.0 was released in 2019, it unleashed the concept of GitOps. By enabling cloud native teams to manage infrastructure as code, GitOps uses automation to make complex deployments faster while also making it easier to detect drift and reconcile workflows.
While Argo CD is the most widely used, Argo is actually a family of four Kubernetes-native, open source projects, explained Dewan Ahmed, principal developer advocate at Harness, in a January 20 webinar with The New Stack:
- Argo CD enables GitOps teams to deploy applications in Kubernetes in a declarative, repeatable way. It’s the most popular project in the Argo family.
- Argo Workflows is used for continuous integration (CI) pipelines, data processing, batch jobs, and machine learning workflows.
- Argo Rollouts makes software releases safer by enabling canary, blue/green, and other deployment strategies.
- Argo Events brings event-driven automation, like reacting to git events or webhooks.
However, all too often, GitOps becomes a victim of its own success, said Ahmed and Eric Minick, Harness senior director of DevOps solutions. One cluster and one Argo CD instance quickly sprawl into 50 clusters and 50 Argo instances, held together by glue code and custom scripts.
Broken processes require the team to maintain custom dashboards and brittle orchestration scripts, wasting precious engineering hours that could be spent on more important projects.
What is the ‘Argo ceiling?’
This pain point is called the “Argo ceiling,” said Minick. And the key to raising the roof is a GitOps control plane that centralizes management without ripping and replacing the tools that devs know and love.
Ahmed and Minick outlined five symptoms that show a team has hit this ceiling:
- Fragmentation and lack of central visibility.
- Reliance on glue code, where scripts rapidly become legacy.
- Awkward promotion flows with extra manual steps in delivery.
- Secret sprawl, where managing secrets is a pain point.
- Difficulty in auditing and scattered changed records.
Scaling GitOps: What’s needed?
Adopting GitOps should not hinder your CI/CD orchestration, they said. GitOps should provide a more developer-friendly and Kubernetes-centric experience that allows your organization to scale as needed.
During this free webinar, Minick, Ahmed and TNS Host Chris Pirillo discussed how to break through the Argo ceiling by implementing a GitOps control plane.
If you’re having to script heavily to manage your GitOps environment, watch Avoiding the Argo Ceiling: Scaling GitOps Without Maxing Out, now available on demand.
Watch on demand today
What you’ll learn about scaling GitOps
By watching, you’ll learn best practices, real-world examples, and actionable tips, including:
- Use isolation, not fragmentation: You should run multiple Argo instances for security, but you shouldn’t manage them individually. A control plane gives you the security of isolation with the visibility of centralization.
- Stop writing ‘glue code’ for orchestration: If you’re writing a script to trigger a test before a sync, you’re building a platform, not shipping features. Orchestration should be a native feature, not a maintenance burden.
- Implement zero-config governance: At scale, manual role-based access control (RBAC) fails. Enterprise governance means policies are embedded in the pipeline and enforced automatically, eliminating the “security vs. speed” trade-off.
Watch for free today!
