Harness GitOps: Scaling Argo CD with Enterprise-Grade Control

Harness GitOps builds on the Argo CD model by packaging a Harness GitOps Agent with Argo CD components and integrating them into the Harness platform. The result is a GitOps architecture that preserves the Argo reconciliation loop while adding visibility, audit, and control through Harness SaaS.

The Control Plane: Argo CD Cluster

At the center of the architecture is the Argo CD cluster, sometimes called the control cluster. This is where both the Harness GitOps Agent and Argo CD’s core components run:

• GitOps Agent: a lightweight worker installed via YAML that establishes outbound connections to Harness SaaS. The GitOps Agent establishes an outbound-only connection to Harness SaaS, executes SaaS-initiated requests locally, and continuously reports the state of Argo CD resources (Applications, ApplicationSets, Repositories, and Clusters).
• Repo-server: pulls manifests from Git repositories.
• Application Controller: compares desired state with live cluster state and applies changes through the Kubernetes API.
• ApplicationSet Controller: automates the creation and management of multiple Argo CD Applications from a single definition, using generators (for example, list, Git, or cluster) to create parameterized applications. This makes it easier to handle large-scale and dynamic deployments. Learn more in the Argo CD docs.
  

The control cluster can be deployed in two models:

• Harness-managed: Harness provides a pre-packaged installation bundle (Kubernetes manifests or Helm configs). You apply these to your cluster, and they set up the required Argo CD components along with the GitOps Agent. Harness makes it easier to get started, but you still own the install action. In the Harness-managed model, Harness provides upgrade bundles for Argo CD components; in BYOA, you retain full responsibility for Argo lifecycle management and version drift.
  
• Bring Your Own Argo (BYOA): If you already operate Argo CD, Harness only provides the GitOps Agent installation instructions. You continue managing the full lifecycle and upgrades of Argo CD yourself.

Target Clusters

The Argo CD Application Controller applies manifests to one or more target clusters by talking to their Kubernetes API servers.

• In the simplest setup, the control cluster and target cluster are the same (in-cluster).
  
• In a hub-and-spoke setup, a single Argo CD cluster can manage multiple remote target clusters.
  
• Multiple agents can be deployed if you want to isolate environments or scale out reconciliation.
  

Git as the Source of Truth

Developers push declarative manifests (YAML, Helm, or Kustomize) into a Git repository. The GitOps Agent and repo-server fetch these manifests. The Application Controller continuously reconciles the cluster state against the desired state. Importantly, clusters never push changes back into Git. The repository remains the single source of truth. Harness configuration, including pipeline definitions, can also be stored in Git, providing a consistent Git-based experience.

Harness SaaS Integration

While the GitOps loop runs entirely in the control cluster and target clusters, the GitOps Agent makes outbound-only connections to Harness SaaS.

Harness SaaS provides:

• User interface for GitOps operations.
  
• Audit logging of syncs and drifts.
  
• RBAC enforcement at the project, org, or account level.
  

All sensitive configuration data, such as repository credentials, certificates, and cluster secrets, remain in the GitOps Agent’s namespace as Kubernetes Secrets and ConfigMaps. Harness SaaS only stores a metadata snapshot of the GitOps setup (Applications, ApplicationSets, Clusters, Repositories, etc.), never the sensitive data itself. Unlike some SaaS-first approaches, Harness never requires secrets to leave your cluster, and all credentials and certificates remain confined to your Kubernetes namespace.

‍

End-to-End Flow

1. A developer commits or merges a change to Git.
   
2. The Argo CD repo-server fetches the updated manifests.
   
3. The Application Controller compares the desired vs live state.
   
4. If drift exists, it is reconciled by applying the manifests through the Kubernetes API.
   
5. The GitOps Agent reports sync and health status back to Harness SaaS for visibility and governance.
   

In short: a developer commits, Argo fetches and reconciles, and the GitOps Agent reports status back to Harness SaaS for governance and visibility.

This is the pure GitOps architecture: Git defines the desired state, Argo CD enforces it, and Harness provides governance and observability without altering the core reconciliation model.

Scaling Beyond a Single Cluster

Most organizations operate more than one Kubernetes cluster, often spread across multiple environments and regions. In this model, each region has its own Argo CD control cluster. The control cluster runs the Harness GitOps Agent alongside core Argo CD components and reconciles the desired state into one or more target clusters such as dev, QA, or prod.

The flow is straightforward:

• Developers push declarative manifests into Git.
  
• Each control cluster fetches those manifests, compares the desired state to the live state, and applies changes to its target clusters through Kubernetes API calls (sync).
  
• The control cluster then reports status, health, and metadata back to Harness SaaS over outbound-only connections.
  

Harness SaaS aggregates data from all control clusters, giving teams a single view and a single place to drive rollouts:

• Unified Dashboards:
  
  
  • Fleet health across clusters
    
  • Drift and sync visibility
    
  • Environment and region filtering
    
• Multi-Cluster Promotion Pipelines:
  
  
  • Gates for tests, approvals, and policies
    
  • Canary or blue/green rollouts with Argo Rollouts or native strategies
    
  • Verification using Harness Verify with integrations to observability tools such as AppDynamics, Datadog, Prometheus, New Relic, Elasticsearch, Grafana Loki, Splunk, and Sumo Logic, enabling automated analysis of metrics and logs to gate promotions with confidence.
    
  • One-click rollback that restores applications, infrastructure, and cluster resources defined in Git, and database schema when migrations are stored alongside your manifests, providing a true rollback to a known good state.
    

This setup preserves the familiar Argo CD reconciliation loop inside each control cluster while extending it with Harness’ governance, observability, and promotion pipelines across regions.

Note: Some enterprises run multiple Argo CD control clusters per region for scale or isolation. Harness SaaS can aggregate across any number of clusters, whether you have two or two hundred.

Next Steps

Harness GitOps lets you scale from single clusters to a fleet-wide GitOps model with unified dashboards, governance, and pipelines that promote with confidence and roll back everything when needed. Ready to see it in your stack? Get started with Harness GitOps and bring enterprise-grade control to your Argo CD deployments.