Building a Multi Cloud GitOps Automation

Author

Govardhana M K
May 31, 2025

In partnership with

TechOps Examples

Hey — It's Govardhana MK 👋

Welcome to another technical edition.

Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.

Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.

👋 Before we begin... a big thank you to today's sponsor MINDSTREAM

ChatGPT at Work: Free Resource Bundle

Power up your productivity with Mindstream's exclusive ChatGPT toolkit, designed for professionals who want to work smarter, not harder.

Your free bundle includes:

  1. ChatGPT Decision Flowchart

  2. Advanced Prompt Templates

  3. 2025 AI Productivity Guide

  4. Task Automation Framework

  5. Industry-Specific Use Cases

Join thousands of AI-powered professionals by subscribing to our daily newsletter. Get the complete bundle instantly after signup - no extra steps required.

👀 Remote Jobs

📚️ Resources

Looking to promote your company, product, service, or event to 47,000+ Cloud Native Professionals? Let's work together. Advertise With Us

🧠 DEEP DIVE USE CASE

Building a Multi Cloud GitOps Automation

While the promise of GitOps and multi-cloud automation is exciting, it’s important to first ground ourselves in how a conventional DevOps CI/CD pipeline operates.

In DevOps flow, the pipeline is responsible for the full flow. A developer commits code, unit tests run, artifacts are built, container images are created and pushed to a registry, and finally, the deployment happens directly into the Kubernetes cluster.

It’s efficient, centralized, and gives immediate feedback. But the deployment logic is tightly coupled with the CI system. The same pipeline that builds the app is also typically triggers the push into production, often leaving little room for separation, visibility, or control.

As teams began scaling and demanding safer, more traceable deployments, GitOps emerged as a cleaner alternative to conventional CI/CD. In a GitOps-driven flow, the CI pipeline still handles tests, builds, and image pushes. But deployment shifts out of the pipeline. Instead of pushing directly to the cluster, the new container version is reflected in a Git commit to a deployment repo.

That repo becomes the single source of truth. A GitOps controller watches for changes, and only then syncs the declared state to the cluster. Deployment decisions now come from version-controlled Git commits, not scripts embedded in pipelines.

Now that the difference between DevOps and GitOps pipelines is clear, it’s time to understand how GitOps push and pull approaches handle deployments differently.

GitOps Push Approach

  • The CI pipeline handles testing, image building, and deployment in one flow.

  • After updating the manifest or Helm chart, the pipeline executes a deploy step using tools like kubectl or Helm.

  • The CI system holds direct access to the Kubernetes cluster, often via service accounts or kubeconfig.

  • Any pipeline error, script issue, or misconfiguration can directly affect live environments.

  • Centralized control is achieved, but at the cost of higher security risk and tighter coupling.

  • Scaling this model across multiple clusters or clouds requires complex secrets management and permissions setup.

GitOps Pull Approach

  • The CI pipeline stops after updating the Git repository with new image versions or manifests.

  • A GitOps agent (like ArgoCD or Flux) inside the cluster continuously monitors the Git repo.

  • The cluster pulls changes when detected, then reconciles its state to match the repo.

  • The CI system has no access to the cluster, reducing security risks and improving auditability.

  • Each cluster acts independently, pulling from the same or environment-specific Git repos.

  • Rollbacks are simplified by reverting commits in Git, and the system heals itself automatically.

Once the differences between push and pull are clear, the next question is scale. What happens when you are no longer managing a single cluster or even a single cloud?

This is where Multi-Cloud GitOps Automation becomes necessary. You are dealing with multiple cloud providers, isolated workloads, and tenant-specific deployments, all of which need to be provisioned, updated, and monitored consistently.

I am giving away 40% OFF on all annual plans of membership offerings for a limited time.

A membership will unlock access to read these deep dive editions on Thursdays and Saturdays.

Offer ends soon.

Multi Cloud GitOps Automation Architecture

Upgrade to Paid to read the rest.

Become a paying subscriber to get access to this post and other subscriber-only content.

Already a paying subscriber? Sign In.

Paid subscriptions get you:

  • • Access to archieve of 170+ use cases
  • • Deep Dive use case editions (Thursdays and Saturdays)
  • • Access to Private Discord Community
  • • Invitations to monthly Zoom calls for use case discussions and industry leaders meetups
  • • Quarterly 1:1 'Ask Me Anything' power session