Multi-Cloud Kubernetes Management with Argo CD
Nicholas Morey
Published by Nicholas Morey in February 2024. Updated in September 2026 by Carolyn King.
A single Argo CD instance can manage Kubernetes clusters across AWS, Azure, GCP, and on-premise data centers. The obstacle is network access: open-source Argo CD needs direct network access and root credentials to every cluster's API server. An agent-based architecture inverts this: each cluster dials out to the control plane, so no VPN, VPC peering, or exposed API server is required and no credentials are shared.
Defining Multi-Cloud, Multi-Cluster, and Multi-Environment Kubernetes
Organizations running Kubernetes at scale face two distinct types of complexity: multi-cloud (or hybrid cloud) complexity, and multi-environment complexity.
Multi-cloud Kubernetes refers to where infrastructure runs: clusters spread across AWS, Azure, GCP, or on-premise data centers, often in combination. Teams adopt this model for redundancy, regulatory compliance, cost optimization, or negotiating leverage with cloud providers. The challenge is architectural: how does a single control plane manage and observe clusters that live in separate networks, behind separate firewalls, under separate providers?
Multi-environment complexity refers to what gets deployed: Kubernetes workloads alongside Terraform-managed infrastructure, virtual machines, and serverless functions. Even organizations running entirely within one cloud provider encounter this problem once their delivery process spans more than containers. The challenge here is operational: how does a team promote changes across fundamentally different deployment targets without maintaining a separate pipeline, approval process, and audit trail for each one?
These two problems are often conflated, but solving one does not solve the other. The rest of this post focuses on multi-cloud complexity — how one control plane manages clusters that live in separate networks. Multi-environment complexity returns in the Kargo section below.
Why Teams Run Kubernetes Across Multiple Clouds and On-Premise
Organizations run Kubernetes across multiple cloud providers, and often on-premise alongside them, to create a hybrid environment for reliability, regulatory compliance, cost optimization, or workload placement based on provider-specific strengths. A team might run production workloads on AWS while keeping a secondary region on Azure for failover, or keep certain data on-premise to satisfy a compliance requirement while running everything else in the cloud.
The result: Kubernetes clusters spread across separate providers and networks, each with its own boundaries and access model. Once that hybrid environment exists, platform teams face a practical question: how do you deploy to and observe all of these clusters consistently?
One option is to run Argo CD separately in each cluster or provider. This keeps each instance simple and self-contained, but it also means platform teams and developers have no unified view of what's running where — they have to check multiple Argo CD instances, each with its own login, its own state, and no shared picture of the overall environment. Drift between environments becomes harder to catch, and standardizing deployment practices across clusters means enforcing the same configuration in multiple places instead of one.
This is why many teams instead move toward a single, central Argo CD instance that can deploy to and observe every cluster in the hybrid environment, regardless of where that cluster lives. One control plane, one login, one place to see the state of the system.
Running a separate Argo CD instance per cluster is a valid choice, and it comes with its own tradeoffs — see how many Argo CD instances you need for a full breakdown of the available architecture models.
Multi-cloud proliferation is also one of the primary drivers pushing platform teams toward fleet management — once cluster count grows past a handful, rollout, rollback, and observability need to work across the whole set, not one cluster at a time. See The Fleet Is the New Cluster: The Infrastructure Shift Platform Engineers Can't Ignore.
The rest of this post assumes a central Argo CD instance, given its advantages for multi-cluster Kubernetes management at scale.
Why Open-Source Argo CD Struggles with Multi-Cloud Networking
Open-source Argo CD requires a direct network connection from its controller to the Kubernetes API server of every cluster it manages to read cluster state and apply changes. In a single-cloud setup, this is a solved problem: the control plane and its clusters share a network, and access is straightforward to configure. In a multi-cloud or hybrid cloud Kubernetes setup, it becomes a much harder problem, because the control plane now needs a path into networks it doesn't own.
Teams solve this a few ways, and each comes with real cost:
VPN connections and VPC peering between cloud providers work, but require ongoing setup and maintenance for every new cluster added to the environment.
Direct connections between providers solve the access problem but add ongoing infrastructure cost that scales with the number of environments involved.
Port-forwarding to the cluster API server avoids some of this setup, but does so by exposing the destination cluster publicly, typically mitigated with an IP allow list limiting traffic to the central Argo CD instance.
Figure: OSS Argo CD Hybrid and Multicloud Networking
All three approaches share the same limitation: they depend on network paths that can break. An IP address change on the central Argo CD instance, a dropped VPN tunnel, or a direct connection that no longer justifies its cost all mean lost access to a cluster until someone rebuilds the connection. As the number of clusters and providers grows, so does the number of these fragile connections requiring monitoring and maintenance.
Why Centralized Cluster-Admin Credentials Are a Security Risk
Beyond the networking burden, OSS Argo CD's architecture creates a second problem: how it stores credentials for the clusters it manages. For every cluster Argo CD manages, the central instance holds a secret with cluster-admin access to that cluster. This is what lets Argo CD apply changes and read state across every environment from one place.
That concentration of credentials is also a concentration of risk. If the central Argo CD instance is compromised, an attacker doesn't just gain access to that instance — they gain cluster-admin credentials and direct network access to every other cluster it manages. A single point of compromise becomes a single point of total compromise, spanning every cloud provider and on-premise environment in the hybrid setup.
This risk scales with exactly the thing multi-cloud Kubernetes management is supposed to deliver: breadth. The more clusters a central instance manages, the more valuable a target it becomes, and the more damage a single compromise can do.
The broader Argo CD project has recognized this same limitation. argocd-agent, an open-source project incubating under argoproj-labs, introduces a pull-based agent architecture to address it. As of September 2026, it remains pre-GA.
Multi-Cloud Argo CD Architectures Compared
The three ways to run Argo CD across more than one network, and what each one costs you:
Argo CD per cluster | Central Argo CD + direct access | Central Argo CD + agent | |
|---|---|---|---|
Network requirement | None | VPN, VPC peering, or public API server | Outbound HTTPS only |
Credentials on control plane | N/A | cluster-admin secret per cluster | None |
Blast radius if control plane is compromised | One cluster | Every managed cluster | Control plane only |
Ongoing network cost | None | High | None |
Single pane of glass | No | Yes | Yes |
Solving Multi-Cloud Kubernetes with Agent-Based Architecture
Akuity's agent-based architecture addresses both problems from a single design decision: the central Argo CD instance runs outside of any cloud account or on-premise environment, and each managed cluster runs a lightweight Akuity Agent that connects back to it.
Figure: Akuity’s Agent-Based Architecture
Instead of the control plane reaching into each cluster's network, each cluster reaches out to the control plane. Once the agent is deployed to a cluster, it establishes an outbound-only connection to the central Argo CD instance. The cluster doesn't need to accept inbound connections, and the control plane doesn't need a path into the cluster's network. This removes the VPN tunnels, VPC peering, and port-forwarding rules described earlier, along with the ongoing maintenance each one requires.
The credential problem is solved by the same design. Because the agent runs locally within each cluster and communicates with the Kubernetes API server from inside that cluster's own network, it authenticates using credentials scoped to that cluster alone. The central control plane doesn't hold cluster-admin credentials for the clusters it manages, because it never needs direct access to them in the first place. If the control plane is compromised, an attacker gains no direct credentials or network path to any other cluster. What was a single point of total compromise becomes a set of independent, isolated clusters.
The result is a single interface for multi-cluster Kubernetes management across every cloud provider and on-premise environment in a hybrid setup, without the networking overhead or the concentrated security risk of the traditional approach. Platform engineers and developers get one place to view and interact with the state of their Kubernetes resources, regardless of where those resources run.
Figure: Akuity’s Hybrid and Multicloud Networking
How Kargo Extends GitOps Promotion to Terraform, VMs, and Serverless
Multi-cloud and multi-cluster Kubernetes management solves the location problem, but many organizations run more than Kubernetes. Terraform-managed infrastructure, virtual machines, and serverless workloads often sit alongside containerized applications, each historically requiring its own pipeline, approval process, and audit trail.
Kargo Enterprise extends the same GitOps principles to this deployment-type problem. Teams can run Terraform and OpenTofu steps directly within a promotion, alongside Kubernetes and VM targets, using consistent approval and audit policies across the board. For a full look at this capability, see Akuity's announcement on unified multi-environment delivery and the Kargo v1.9 release notes covering infrastructure-aware promotions in more depth.
Multi-Cloud Kubernetes in Production: CoreWeave and Aleph Alpha
Organizations already run this architecture in production. CoreWeave uses Akuity's agent-based model to keep configuration consistent across staging, production, and multiple clusters from a single source of truth, without exposing public services or altering a customer's firewall. Aleph Alpha uses the Akuity Platform to deploy more than 400 applications across 11 Kubernetes clusters through a centrally managed Argo CD instance, keeping environments isolated while maintaining unified visibility and automation.
For a closer look at how teams manage hybrid and multi-cloud Kubernetes environments in practice, see the panel discussion on GitOps for hybrid and multi-cloud delivery, or browse the full set of customer stories.
Getting Started with Multi-Cloud Kubernetes Management
To see this architecture in action or learn more about best practices for implementing multi-cloud Kubernetes and multi-environment Kubernetes, schedule a technical demo with the Akuity team. The Getting Started guide on the Akuity Documentation site covers the steps for setting up a new Argo CD instance.
Additional resources
For teams evaluating multi-cloud, multi-cluster, or multi-environment Kubernetes management, these related resources go deeper on specific pieces of this architecture:
[Blog Post] GitOps for Hybrid and Multi-Cloud Kubernetes at Scale
[Webinar] Multi-Environment Promotions Made Simple
[Blog Post] Akuity Introduces Promotion Support Across Kubernetes, Terraform, VMs, and Serverless Environments
[Blog Post] The Fleet Is the New Cluster: The Infrastructure Shift Platform Engineers Can't Ignore
[Blog Post] The Fleet Management Gap: What Existing Kubernetes Tools Solve, and What They Don't
Frequently Asked Questions
Can one Argo CD instance manage clusters in multiple clouds?
Yes. A single Argo CD instance can manage clusters across AWS, Azure, GCP, and on-premise environments, provided the control plane can reach each cluster's API server, or each cluster runs an agent that connects outbound to the control plane.
What is multi-cloud Kubernetes management?
Multi-cloud Kubernetes management refers to deploying and operating Kubernetes clusters across more than one cloud provider, such as AWS, Azure, and GCP, often alongside on-premise infrastructure. It requires a way to deploy applications and observe cluster state consistently across providers that don't share a network by default.
What is the difference between multi-cloud Kubernetes and multi-environment Kubernetes? Multi-cloud Kubernetes is a question of location: where clusters run, across which cloud providers or on-premise data centers. Multi-environment is a question of deployment type: whether the delivery process spans Kubernetes workloads alongside Terraform-managed infrastructure, virtual machines, or serverless functions. A team can face either complexity independently, or both at once.
Why is multi-cluster Kubernetes management difficult with open-source Argo CD?
Open-source Argo CD requires a direct network connection from its controller to the Kubernetes API server of every cluster it manages. In a multi-cloud or hybrid cloud Kubernetes setup, establishing that connection typically requires VPNs, VPC peering, direct connections between providers, or port-forwarding with IP allow lists, all of which depend on network paths that can break.
Is storing cluster-admin credentials centrally a security risk?
Yes. Open-source Argo CD stores a cluster-admin secret centrally for every cluster it manages. If the central instance is compromised, an attacker gains direct credentials and network access to every other cluster it manages, not just the compromised instance itself.
How does Akuity's agent-based architecture solve multi-cloud Kubernetes management?
Akuity deploys a lightweight agent to each managed cluster, which establishes an outbound-only connection back to a central Argo CD instance hosted outside any single cloud account or on-premise environment. This removes the need for inbound network access to any cluster and keeps cluster-admin credentials scoped locally rather than held centrally.
Is argocd-agent (the open-source Argo CD agent project) generally available?
As of September 2026, argocd-agent remains pre-GA. It is an incubation project under argoproj-labs, not yet part of core Argo CD.
Does Akuity support deployment targets beyond Kubernetes?
Yes. Kargo Enterprise extends the same GitOps promotion model to Terraform and OpenTofu-managed infrastructure, virtual machines, and serverless workloads, using consistent approval and audit policies across all deployment types.
