Argo CD Architectures Explained: Single vs. Per-Cluster vs. Hybrid

By Nicholas Morey and Jesse Suen. Originally published May 2025. Updated July 2026 by Jesse Suen.

Using Argo CD to implement GitOps for Kubernetes looks simple on the surface. Scaling GitOps well, without sacrificing developer experience or security, depends on choosing the right architecture for the organization. This is a decision with real stakes: the 2026 Argo CD User Survey found scaling and performance are now among the most cited challenges for teams running Argo CD at scale, making the right architecture choice more important than ever.

This post covers the most common architectures for implementing Argo CD: single instance, per-cluster instances, and a hybrid model that blends elements of both, along with an agent-based model built for enterprise scale. Each comes with tradeoffs worth weighing before committing to one.

Argo CD Architectures Compared

An Argo CD architecture describes how Argo CD instances and components are distributed across the Kubernetes clusters they manage. The choice determines where control planes, credentials, application controllers, and API connections live, shaping scalability, security, operational overhead, and developer experience.

Table: Argo CD Architecture Tradeoffs

Choosing the right Argo CD architecture matters for scalability, security, and operational efficiency. The different architectures determine how Argo CD manages deployments, how teams interact with it, and how well it integrates with organizations' existing Kubernetes infrastructure.

The sections below cover each architecture in detail, including benefits, challenges, and ideal use cases, along with a side-by-side comparison across security, scalability, and developer experience to help match the right model to the organization's team size, security requirements, and platform engineering capacity.

#1: Single Argo CD Instance (Hub and Spoke)

In this model, one Argo CD instance runs on a dedicated management cluster and deploys to every other cluster in the fleet remotely. There is one control plane, one UI, and one API endpoint, and the workload clusters, also known as "spokes," run no Argo CD components of their own. This is a popular approach for small teams with simple infrastructure or organizations early in their Kubernetes adoption, providing a single view of applications and a strong developer experience.

Figure:  Single Argo CD Instance Architecture

For example, a management cluster mgmt running Argo CD, plus three workload clusters dev, staging, and prod. You register each one once:

Each command creates a service account on the target cluster and stores that cluster's API URL and credentials as a Secret in the management cluster's argocd namespace. From then on, an Application simply points at the cluster by name:

destination:
  name: prod          # matches the registered cluster
  namespace

Advantages of a Single Argo CD Instance 

• Single view for deployment activity across all clusters.

• Single control plane, simplifying installation and maintenance.

• Single server for easy API/CLI integration.

• Strong integration with the ApplicationSet cluster generator.

Disadvantages of a Single Argo CD Instance 

• Scaling requires tuning individual components by hand.

• A single control plane creates a single point of failure for deployments.

• Admin credentials for every cluster sit in one place.

• Running it well requires a dedicated management cluster.

• Traffic between Argo CD and the clusters can be significant.

How the Single Argo CD Instance Architecture Works

The management cluster hosts the entire control plane and connects directly to each workload cluster's API server. Manifest generation and reconciliation happen centrally, giving operators a single server URL for the entire fleet. This model offers the simplest operational experience and lowest overhead of the three approaches, but it concentrates both risk and scaling limits into a single system.

One capability worth highlighting: pairing with an ApplicationSet cluster generator. Pointing the generator at "all registered clusters" creates one Application per cluster automatically. This turns rollout of a standard set of cluster add-ons (monitoring, ingress, policy agents) across the entire fleet into a one-file change.

spec:
  generators:
    - clusters: {}                 # every registered cluster
  template:
    metadata:
      name: 'addons-{{name}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/org/addons.git
        targetRevision: main
        path: kube-prometheus-stack
      destination:
        server: '{{server}}'
        namespace: monitoring
      syncPolicy:
        automated: { prune: true, selfHeal

Security and Scaling Considerations for a Single Argo CD Instance

Single point of failure: every cluster shares one application controller, competing for the same worker pool of status and operation processors, so a noisy cluster, such as a staging cluster with constant redeploys, can keep the controller busy long enough to delay a production sync. If the control plane goes down entirely, workloads already running on the clusters keep running, but syncing, self-healing, and visibility stop until it recovers.

Centralized credential exposure: the management cluster needs direct API server access to every cluster it manages, usually meaning public endpoints or cross-VPC networking, and because it stores admin-level credentials for the whole fleet as Secrets in its own cluster, compromising it exposes all of them at once.

Scaling limits: as the fleet grows, managed clusters get split across multiple application-controller replicas (shards), each tuned to match its share of the load. If the management cluster sits in a different region from the clusters it drives, cross-region traffic adds latency and cost as well.

Recent Improvements to Security

These apply to any Argo CD install, but they matter most when many teams share one instance:

RBAC narrowing: permissions can now target specific resources inside an application, closing an old gap where update or delete on an application implicitly extended to every sub-resource. Combined with AppProjects, this tightly bounds what each team can touch in a shared instance.

Further mitigations: mutual TLS between the repo-server and other components limits the blast radius if one is compromised, automatic OIDC token refresh removes recurring session friction, and extended OpenTelemetry tracing improves visibility into authentication issues.

Developer and Operator Experience with a Single Argo CD Instance

A single server URL simplifies logging into the argocd CLI and setting up API integrations. It also gives operators one location for managing configuration, including repository credentials, SSO, local users, API keys, Argo CD CRDs, and RBAC policies, rather than juggling separate settings per cluster.

The ApplicationSet cluster generator sharpens this advantage further. Managing a standard set of cluster add-ons across every registered cluster becomes a matter of updating one ApplicationSet rather than coordinating changes across many separate instances.

#2: Argo CD Per Cluster (Dedicated Instance Model)

In this model, a full Argo CD instance runs inside every cluster and deploys only to that same cluster. There is no external control plane and no central instance; each cluster is fully self-contained.

Figure: Argo CD Per Cluster Architecture

This is most common in organizations with dedicated platform teams and strict security or compliance requirements, where each environment maps to one Kubernetes cluster. The result is one Argo CD instance per environment, which simplifies security and control. It scales and isolates better than a single shared instance, but at the cost of more moving parts and a heavier engineering lift to maintain

For example, Three clusters, say dev, staging, and prod each running its own Argo CD in an argocd namespace, reachable at its own URL (argocd.dev.example.com, argocd.staging.example.com, argocd.prod.example.com). Every instance deploys only to itself, so its Applications always target the local cluster:

yaml

destination:
  server: https://kubernetes.default.svc   # the local cluster
  namespace

Because the destination is always in-cluster, Argo CD uses its own ServiceAccount and RBAC to apply manifests. There is no cluster Secret, no stored API token for a remote cluster, and no external API-server access to arrange.

Advantages of Argo CD Per Cluster Architecture

• Load is distributed because each instance handles only its own cluster.

• No cluster needs to expose its API server externally.

• No control-plane traffic leaves the cluster to reach a remote controller.

• An outage in one cluster does not affect any other.

• Credentials scoped to a single cluster.

Disadvantages of Argo CD Per Cluster Architecture

• Maintaining many instances means duplicating configuration across them.

• At a certain scale, each instance can still need tuning.

• API and CLI integrations must specify which instance to talk to.

• The ApplicationSet cluster generator adds no value here.

How the Per-Cluster Argo CD Architecture Works

Each cluster runs its own full set of Argo CD components locally: application controller, repo-server, API server, and Redis cache. None of these components cross cluster boundaries, and no cluster needs to expose its API server externally. Each instance sees exactly one cluster: itself.

Security and Scaling Considerations of Argo CD Per Cluster Architecture

Isolated security domain: because Argo CD deploys only to its own cluster through its in-cluster ServiceAccount, no instance holds credentials for any other cluster, and there is no central instance holding credentials for the whole fleet. The few secrets an instance does need (repository access, notification keys) stay inside that cluster. The security domain and blast radius are therefore fully contained: resource pressure severe enough to threaten deployments in one cluster has no effect on any other.

Cost tradeoffs — cloud costs drop, compute costs increase: without a separate management cluster, no control-plane traffic crosses the network to an external application controller, cutting cloud networking costs. Running a full Argo CD instance in every cluster increases compute costs instead.

Scaling limits: each instance handles its own cluster, so load distributes naturally instead of piling onto one shared controller, but a single cluster can still grow large enough in Applications and repositories that its instance needs the same manual tuning a shared instance would.

Developer and Operator Experience with Argo CD Per Cluster Architecture

This architecture takes more engineering effort to run well, and that shows up in the developer experience. Remembering which control plane to point at when using the Argo CD CLI or web UI adds cognitive overhead. A consistent naming scheme for server URLs, with each matching its cluster's FQDN and Argo CD as a subdomain, as in the example above, keeps that friction low.

For operators, running many instances is a heavy lift. Each cluster is a separate login, with its own RBAC policies and API keys to maintain, and any shared configuration change (SSO, repository credentials) has to be duplicated across every instance. Drift is a real risk, which is a good reason to keep lower environments as production-like as possible.

The burden is heaviest around ApplicationSets. The cluster generator, which fans out Applications across every cluster registered to a shared instance, has nothing to fan out here, since each instance only knows itself. Instead, the git generator is used with a folder-per-environment layout in the GitOps repository. Each instance points at its own environment folder:

spec:
  generators:
    - git:
        repoURL: https://github.com/org/fleet.git
        revision: main
        directories:
          - path: envs/dev/*       # this instance reads only its own env
  template:
    metadata:
      name: '{{path.basename}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/org/fleet.git
        targetRevision: main
        path: '{{path}}'
      destination:
        server: https://kubernetes.default.svc   # always local
        namespace: '{{path.basename}}'
      syncPolicy:
        automated: { prune: true, selfHeal

The staging and prod instances run a near-identical ApplicationSet that differs only in the path (envs/staging/*, envs/prod/*). That repetition is exactly where duplication and cross-environment drift creep in which is the trade-off you accept for the isolation this model provides.

#3: Hybrid Argo CD Architecture (Instance Per Logical Group)

This model sits between the previous two: one Argo CD instance per logical group of clusters rather than one for the whole fleet or one for every cluster. It suits mid-sized organizations already organized around teams, regions, or environments, or those that have outgrown a single shared instance but don't yet have the platform headcount for a full per-cluster setup. 

Figure: Hybrid Argo CD Architecture

This shift toward grouping or consolidating instances isn't just a framework preference: the 2026 Argo CD User Survey found the number of respondents running one cluster per instance is declining, as organizations connect more clusters to fewer instances and feel the resulting scaling pressure.

The grouping can follow team boundaries (see Conway's Law), region, environment, or whatever division already makes sense internally. An existing way of grouping applications is usually the right starting point. 

For example, group by region. A US management cluster runs one Argo CD instance managing us-dev, us-staging, and us-prod; an EU management cluster runs a second instance managing eu-dev, eu-staging, and eu-prod. Each hub registers only its own group's clusters:

 # on the US hub's Argo CD
argocd cluster add us-dev
argocd cluster add us-staging
argocd cluster add us-prod

# on the EU hub's Argo CD

Advantages of Hybrid Argo CD Architecture

• Load is distributed across groups instead of one shared control plane.

• Blast radius contained per group; a failure in one group's control plane doesn't reach any other.

• Credentials scoped to a single group.

• Configuration duplication drops sharply compared to per-cluster.

• ApplicationSet cluster generator works within each group.

Disadvantages of Hybrid Argo CD Architecture

• Still requires maintaining multiple instances.

• At a certain scale, each instance can still need tuning.

• API and CLI integrations must target the right instance.

• Each group needs a management cluster to host its instance.

• The cluster-generator ApplicationSet has to be duplicated once per group.

How the Hybrid Argo CD Architecture Works

One Argo CD instance manages each logical group of clusters. That cuts the instance count relative to a strict per-cluster model while still spreading load. Because RBAC, AppProjects, and other settings tend to be similar for clusters in the same group, duplication drops compared to running one instance per cluster.

The ApplicationSet cluster generator still works inside each group, keeping the clusters in that group consistent. Since each hub only has its own group's clusters registered, a plain generator already fans out just to that group:

spec:
  generators:
    - clusters: {}                 # every cluster registered to THIS group's hub
  template:
    metadata:
      name: 'addons-{{name}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/org/addons.git
        targetRevision: main
        path: kube-prometheus-stack
      destination:
        server: '{{server}}'
        namespace: monitoring
      syncPolicy:
        automated: { prune: true, selfHeal

Security and Scaling Considerations of Hybrid Argo CD Architecture

Grouping partitions load across each group's application controller, repo-server, and API server, and contains the blast radius at the group boundary: an outage or compromise in one group doesn't extend to others. It isn't a complete fix, though, since individual components can still need tuning depending on how large the clusters in a group are.

The instances have to live somewhere, and there are two ways to place them:

1. One management cluster per group: a hub failure only affects its own group, and groups share nothing. This costs the most, since it means running a full control plane cluster per group.

2.  One shared management cluster hosting every hub - Install each group's Argo CD as a namespace-scoped instance (argocd-us, argocd-eu, and so on) so several can coexist on one cluster. This is cheaper, but it reintroduces a shared failure domain: a problem with that single cluster affects every group hosted on it.

Developer and Operator Experience with Hybrid Argo CD Architecture

Developer experience improves compared to the per-cluster architecture. A clear, understood convention for the grouping reduces the cognitive burden of knowing where to point CLI and API integrations, and a single view of deployment activity exists for each group rather than for each individual cluster.

#4: The Akuity Platform: The Agent-Based Approach for Enterprise Scale

The Akuity Platform combines the benefits of the per-cluster model and the single-instance model without the tradeoffs of either. Its agent-based architecture lets Argo CD scale to large enterprise use cases, encompassing thousands of clusters and applications under a single control plane (tested at 50,000 Applications and 1,000 clusters).

Figure: Akuity’s Agent-Based Architecture

Advantages of Akuity’s Agent-Based Architecture

• Tested at 50,000 applications and 1,000 clusters.

• No external access to clusters required, a key security benefit.

• Application Controller sized correctly per cluster.

• Built-in disaster recovery and automation via API/CLI.

Disadvantages of Akuity’s Agent-Based Architecture

• Cost of the SaaS platform.

• Less control of the underlying hosting (if not self-hosted).

How Akuity’s Agent-Based Architecture Works

An agent runs inside each managed cluster with outbound access back to the control plane, reversing the connection direction from the traditional models above. The agent runs under a service account inside the managed cluster and talks to the local API server over the cluster network, making it possible to connect clusters that would otherwise be difficult to expose, including a cluster running on a laptop.

This same agent model lets the platform delegate repo-server, applicationset-controller, and image-updater functions to specific clusters, useful for teams needing private internal Git access or tighter local control over these components.

Security and Scaling Considerations of Agent-Based Architecture

Reversing the connection direction removes the security concerns tied to direct cluster access or stored admin credentials entirely: there's no management cluster holding kubeconfigs for the fleet, and no need to expose any cluster's API server externally. This mirrors the security profile of the per-cluster model without its operational cost.

On scaling, the Application Controller is sized correctly for each cluster rather than sharing one controller across the fleet, avoiding the manual shard-tuning burden of a single instance. Automatic snapshotting and disaster recovery remove the single-point-of-failure risk that a traditional management cluster carries.

Developer and Operator Experience with Agent-Based Architecture

No dedicated management cluster is needed: the platform hosts the Argo CD instance and its CRDs directly, giving one place to view every application across the organization alongside a per-instance dashboard for health and sync history. An audit log spans every instance for easier compliance reporting.

Configuration runs declaratively through the akuity CLI and the Akuity Terraform provider, and the ApplicationSet cluster generator works fully out of the box: every agent deployed to a managed cluster registers with Argo CD automatically, so deploying an agent is enough to bootstrap that cluster with any Applications defined through the ApplicationSet.

How to Choose an Argo CD Architecture

The Argo CD architecture chosen for an organization affects scalability, performance, security posture, and day-to-day operational overhead. This isn't a decision to make lightly, or to default to whatever configuration happens to be easiest to spin up first; it shapes how well GitOps holds up as the organization and its Kubernetes footprint grow.

Table: Argo CD Architecture: Structural Comparison 

The number of instances needed depends on several factors: environment size and complexity, number of users accessing the system, and the workloads those instances handle. Weighing these factors against team size, platform engineering capacity, and pace of growth will help identify the right architecture and the appropriate compromises.

Additional Resources:

• Argo CD: Up and Running (O'Reilly) — Free ebook covering GitOps fundamentals and hands-on Argo CD usage for teams managing Kubernetes clusters without deep Kubernetes expertise.

• Akuity Academy: Introduction to GitOps and Argo CD — Free, self-paced course on GitOps fundamentals and core Argo CD concepts.

• [Watch] How to Best Scale and Optimize Argo CD for Kubernetes Deployments — On-demand webinar on scaling Argo CD across the architecture patterns discussed above.

• Argo CD Docs — Official technical reference for installation, configuration, and operation.

Interested in Enterprise-Ready Argo CD?

For platform teams aiming to reduce operational overhead, move faster, and reach enterprise scale, the Akuity Platform's agent-based architecture manages thousands of clusters and applications under a single control plane, tested at 50,000 Applications and 1,000 clusters. Schedule a technical demo today!

FAQ

What is the best Argo CD architecture for a large enterprise?

No single architecture wins outright at enterprise scale; the right fit depends on available platform engineering resources and security requirements. Organizations with a dedicated platform team and strict compliance requirements often choose per cluster for full isolation. Organizations prioritizing operational simplicity at scale increasingly move to the Akuity Platform's agent-based model, which delivers the isolation benefits of per cluster without the operational overhead of maintaining many separate instances.

What is the difference between single instance and per-cluster Argo CD architectures?

A single instance runs one Argo CD control plane that manages every cluster in the fleet from a central management cluster. Per cluster runs a full, separate Argo CD installation inside each individual cluster, with no shared control plane. Single instance offers simpler operations and a stronger developer experience; per cluster offers stronger security isolation and better fault containment, at the cost of more instances to manage.

How many clusters can one Argo CD instance manage?

There's no fixed limit, but performance degrades as the number of clusters, Applications, and repositories grows, requiring manual tuning of individual components (repo-server, application controller, api-server) and careful shard sizing. The 2026 Argo CD User Survey found that scaling and performance are now the most commonly cited challenge among organizations managing more than 2,000 Applications on shared instances.

Does Argo CD 3.0 change how RBAC works?

Yes. Argo CD 3.0 introduced fine-grained RBAC that scopes permissions to specific resources within an Application rather than the Application as a whole, closing a gap in the 2.x model where update or delete access implicitly extended to every sub-resource. Anyone still running 2.x-era RBAC policies needs a configuration upgrade to take advantage of this.

How does the Akuity Platform's agent-based architecture differ from traditional Argo CD architectures?

Instead of a central instance reaching out to every cluster (single instance) or a fully separate instance living inside each cluster (per cluster), an agent runs inside each managed cluster and connects outbound to the control plane. This reverses the connection direction, removing the need to expose any cluster's API server externally or store admin credentials in a central location, while still giving operators a single pane of glass across the entire fleet.