GitOps Across Multiple Clouds with ArgoCD

By Kokil Thapa | Last reviewed: September 2026

GitOps Across Multiple Clouds with ArgoCD solves a problem every growing platform hits: three Kubernetes clusters on three providers, and nobody trusts a Friday deploy. You want one Git commit to roll out the same application version to AWS EKS, Google GKE, and Azure AKS without SSH, kubectl roulette, or snowflake scripts. Argo CD turns that into a declarative loop—Git is the source of truth, the controller reconciles cluster state, and drift becomes visible instead of silent. If you already run Argo CD on a single cluster, this guide shows how to extend that model across clouds without turning your repo into spaghetti.

What is GitOps Across Multiple Clouds with ArgoCD?

Multi-cloud GitOps means the desired state of every workload lives in Git. Argo CD continuously compares that state to what actually runs in each cluster. When they differ, it syncs—or flags drift for a human. The cloud provider underneath does not change the GitOps contract.

On a production Laravel stack I usually deploy with Deployer and GitLab CI on a single VPS or EC2 host. That model is honest and cheap for many Nepal SMB sites. When a client outgrows one server and needs Kubernetes in two regions plus a DR cluster, GitOps with Argo CD becomes the sane upgrade path. The mental shift is the same: Git drives production, not manual clicks.

Argo CD fits multi-cloud because it is cluster-agnostic. You register each remote cluster as a Secret of type cluster. Argo CD stores the API server URL and bearer token. One control plane can manage dozens of clusters across AWS, GCP, Azure, Hetzner, or on-prem.

The official Argo CD cluster management docs describe registration, labels, and RBAC. Those three pieces matter more than which cloud sold you the nodes.

How do you architect Argo CD for multi-cloud Kubernetes?

Start with topology. Most teams pick one of three patterns. Each trades operational cost against blast radius.

For a first multi-cloud rollout, the central hub on a small, stable management cluster wins. Put it on whichever cloud your platform team already monitors. Register remote clusters with labels like cloud=aws, region=ap-south-1, and env=production. ApplicationSet generators read those labels to target the right clusters automatically.

Install the control plane with HA in mind

Install Argo CD into a dedicated argocd namespace on the management cluster. Enable high availability if this hub drives production revenue:

helm repo add argo https://argoproj.github.io/argo-helm
helm install argocd argo/argo-cd \
  --namespace argocd \
  --create-namespace \
  --set configs.params.server.insecure=false \
  --set redis-ha.enabled=true

Expose the API server behind an ingress with TLS. Lock admin login behind SSO. Platform engineers get Argo CD RBAC roles; application teams get project-scoped access. This mirrors how I restrict production SSH on Linux servers I administer for clients—few people touch prod, everyone else gets scoped credentials.

Register remote clusters safely

Each remote cluster needs a service account Argo CD can impersonate. The common pattern installs an agent SA in the remote cluster, then stores credentials in the hub:

argocd cluster add gke-asia-south1 \
  --name gke-asia-south1 \
  --label cloud=gcp \
  --label region=asia-south1 \
  --label env=production

Repeat for EKS and AKS. Verify with argocd cluster list. Clusters should show Successful connection status before you attach Applications. A misconfigured bearer token is the number-one reason multi-cloud GitOps looks "broken" on day one.

How do you connect AWS, GCP, and Azure clusters to one Argo CD?

Each cloud exposes Kubernetes differently, but Argo CD only needs a reachable API server and a valid token. Cloud-specific work happens before registration.

AWS EKS

Create an EKS cluster with a private API endpoint if security policy allows. Install the Argo CD cluster credentials using the AWS CLI context:

aws eks update-kubeconfig --name prod-eks --region ap-south-1
argocd cluster add prod-eks \
  --name eks-ap-south1 \
  --label cloud=aws \
  --label region=ap-south-1

Ensure the hub network can reach the EKS API. That often means VPC peering, Transit Gateway, or a VPN between the management VPC and workload VPCs. Skipping network planning is a classic multi-cloud trap.

Google GKE

GKE autopilot or standard both work. Use workload identity for in-cluster apps, but Argo CD still needs its own registration token:

gcloud container clusters get-credentials prod-gke --region asia-south1
argocd cluster add prod-gke \
  --name gke-asia-south1 \
  --label cloud=gcp

If your team also provisions infra with Terraform, keep cluster creation in Terraform and GitOps apps in Argo CD. Mixing both in one tool creates ownership fights. The split is covered well in managing multi-cloud state with Terraform and infrastructure GitOps vs application GitOps.

Azure AKS

AKS registration follows the same CLI flow:

az aks get-credentials --resource-group rg-prod --name prod-aks
argocd cluster add prod-aks \
  --name aks-westeurope \
  --label cloud=azure \
  --label env=dr

Label DR clusters explicitly. During failover drills you promote DR by merging a Git change, not by kubectl panic. That discipline shows up in solid multi-cloud disaster recovery planning.

Which Git repository layout works best for multi-cloud ArgoCD?

Repo layout makes or breaks multi-cloud GitOps. A flat folder of YAML files does not scale past two services. Use a structure that separates app code from deployment config.

A pattern I recommend for teams moving off single-cluster Argo CD setups:

• apps/ — Kustomize or Helm wrappers per microservice
• clusters/ — cluster-specific overrides (replicas, ingress hostnames, node selectors)
• platform/ — shared operators, cert-manager, ingress controllers
• applicationsets/ — Argo CD ApplicationSet manifests

Example ApplicationSet that deploys a payment API to every production cluster labeled env=production:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: payment-api-prod
  namespace: argocd
spec:
  generators:
  - clusters:
      selector:
        matchLabels:
          env: production
  template:
    metadata:
      name: 'payment-api-{{name}}'
    spec:
      project: payments
      source:
        repoURL: https://git.example.com/platform/gitops.git
        targetRevision: main
        path: apps/payment-api/overlays/{{metadata.labels.cloud}}
      destination:
        server: '{{server}}'
        namespace: payments
      syncPolicy:
        automated:
          prune: true
          selfHeal: true
        syncOptions:
        - CreateNamespace=true

Validate YAML locally with a JSON or YAML formatter before pushing. A tab-indented file can break an entire sync wave. For larger teams, add CI that runs kustomize build and kubeconform on every pull request.

Compare Argo CD with Flux if your org debates tooling. Both work multi-cloud. Argo CD gives you a strong UI and RBAC out of the box. See GitOps Flux vs Argo CD and FluxCD vs ArgoCD compared for an honest side-by-side.

How do you handle secrets and drift across cloud clusters?

Never commit plaintext secrets to the GitOps repo. That rule does not change because you added a second cloud. Use External Secrets Operator, Sealed Secrets, or cloud-native secret stores behind a consistent interface.

A practical approach for multi-cloud:

1. Store secrets in AWS Secrets Manager, GCP Secret Manager, or Azure Key Vault per cluster.
2. Install External Secrets Operator in each workload cluster.
3. Commit only ExternalSecret manifests that reference remote keys.
4. Let Argo CD sync the ExternalSecret; the operator materialises Kubernetes Secrets at runtime.

This aligns with broader multi-cloud secrets management guidance. Rotate keys in the cloud vault; GitOps config stays stable.

Drift is the other half. Someone will kubectl edit a Deployment during an incident. Argo CD marks the Application OutOfSync. With selfHeal: true, the controller reverts the change. Without it, you get a ticket. Pick the policy per app tier: stateless APIs can self-heal; StatefulSets may need manual review.

Enable notifications to Slack or email on sync failure. Wire Prometheus alerts on argocd_app_sync_total failure rates. Platform visibility beats logging into three cloud consoles. For security boundaries, pair GitOps with zero-trust networking across clouds.

What are common multi-cloud Argo CD failure modes?

Knowing the failures upfront saves weekends. These show up repeatedly on real platforms.

Network paths and API reachability

Argo CD on a management cluster in AWS cannot sync GKE if firewalls block 443 to the GKE control plane. Document required CIDR allowlists before go-live. Test with argocd cluster get eks-ap-south1 and a dry-run sync.

CRD and version skew

Deploying the same Helm chart to EKS 1.31 and AKS 1.29 fails when the chart assumes a CRD only present on one version. Pin cluster minor versions within one skew window. Run chart rendering in CI against each cluster's API version.

Cost surprises

Three clouds means three egress bills. Pulling container images cross-cloud on every pod restart adds up fast. Use regional registries or a single artifact registry with replication. Read FinOps cloud cost optimization basics before you replicate prod in three regions "just because."

Over-automation on day one

Auto-sync with prune on every cluster sounds pure GitOps. It also deletes a namespace someone tagged wrong. Start with manual sync for new clusters. Enable automation after a week of clean diffs. The same caution applies when adopting multi-cluster GitOps patterns with any controller.

For visibility across many clusters, some teams add Rancher or OCM on top. That is optional. Argo CD alone is enough if your cluster count stays under roughly twenty. See Rancher for managing multiple clusters if you need a single pane beyond GitOps.

On booking platforms like Adventure Third Pole Trek, uptime during peak season matters more than Kubernetes novelty. Multi-cloud GitOps earns its keep when DR and regional latency are business requirements—not resume-driven architecture. For broader context, read multi-cloud architecture: a practical guide and multi-cluster Kubernetes across clouds.

Backup strategy still belongs in the plan. Git holds desired state, not persistent volume data. Pair GitOps with snapshot policies documented in backup and disaster recovery on the cloud. If your team ships custom apps rather than only infra, enterprise application development and ongoing support and maintenance keep the application and the GitOps layer aligned.

The Kubernetes cluster administration documentation covers federation alternatives. Most teams in 2026 skip federation and let Argo CD push manifests instead. Simpler mental model, fewer moving parts.

Key Takeaways

• Run one Argo CD control plane on a stable management cluster and register every remote cloud cluster with consistent labels.
• Use ApplicationSet cluster generators so one template deploys the same app to AWS, GCP, and Azure without copy-paste YAML.
• Structure Git with Kustomize bases and per-cloud overlays; never store plaintext secrets in the repo.
• Verify network paths to each cluster API before enabling auto-sync with prune.
• Start with manual sync on new clusters; automate only after diffs and health checks look reliable.
• Pair GitOps with regional registries and FinOps review so multi-cloud egress does not silently drain budget.

People Also Ask

Can one Argo CD instance manage clusters in different cloud accounts?

Yes. Each cluster registers independently with its own API endpoint and service account token. Labels distinguish accounts, regions, and environments. RBAC in Argo CD projects limits which teams can deploy where.

Is Argo CD better than Flux for multi-cloud GitOps?

Both controllers work across clouds. Argo CD ships a mature UI, built-in SSO hooks, and ApplicationSets for multi-cluster templating. Flux is lighter and fits Git-native teams that prefer CRDs only. Many platforms pick Argo CD when platform engineers need a visual ops dashboard.

Do I need the same Kubernetes version on every cloud?

Keep versions within one minor release of each other when possible. Identical versions simplify Helm and CRD compatibility. Test chart renders against each cluster API in CI before merging.

Where should the Argo CD management cluster live?

Place it on whichever cloud or region your platform team already operates and monitors. It does not need to sit in every workload region. Ensure low-latency, reliable network access to every registered cluster API server.

Ship multi-cloud GitOps without the guesswork

GitOps Across Multiple Clouds with ArgoCD gives you one auditable path from commit to running pods on EKS, GKE, and AKS. Start small: one hub, two clusters, manual sync, clear repo layout. Add ApplicationSets, secret operators, and auto-heal once the basics hold. If you want help designing the Git repo, cluster labels, or the first ApplicationSet for a production app, reach out through the contact page or explore the home page for related custom software development services. Solid GitOps beats heroic kubectl every time.