How Do You Implement GitOps in the Enterprise?

Enterprise teams that have containerized their workloads and adopted Kubernetes face a consistent operational question in 2026: how do you manage deployments at scale, across multiple environments and clusters, with the auditability and consistency that engineering organizations require? The answer most platform and DevOps teams have converged on is GitOps — a model where the desired state of your infrastructure and applications is declared in a Git repository, and an automated agent running inside your cluster continuously reconciles actual state to match it. Rather than pushing changes through a CI pipeline with direct cluster credentials, a GitOps controller inside the cluster pulls changes from Git and applies them. The difference sounds minor. In practice it changes your security posture, your audit trail, and your ability to scale delivery consistently across teams.

GitOps adoption has crossed a tipping point. As of 2026, over 64% of teams managing production Kubernetes workloads have adopted GitOps as their primary delivery mechanism, up from under 20% three years prior. ArgoCD has exceeded 100,000 GitHub stars and is a graduated CNCF project; Flux CD is similarly graduated. The tooling is stable and the patterns are well-understood. What most implementation guides leave out are the specifics that determine whether GitOps adoption succeeds or stalls at the pilot stage — repository structure, secrets handling, multi-cluster fleet management, access control, and the path for migrating from a push-based CI/CD model.

This guide walks through each of those specifics: the four GitOps principles, the ArgoCD vs Flux decision, repository patterns that scale, secrets management approaches, multi-environment fleet control, security posture, and the practical migration path from traditional CI/CD. Teams working with us on cloud infrastructure and DevOps get this delivery layer configured as part of that engagement.

What Is GitOps and Why Enterprise Teams Are Adopting It

GitOps was formalized by Weaveworks in 2017 and codified by the OpenGitOps project as four principles: the system is declarative (desired state is described, not commanded); it is versioned and immutable (all changes are tracked in Git with full history); changes are pulled automatically (a controller applies changes from Git rather than a pipeline pushing into the cluster); and the system is continuously reconciled (the controller detects and corrects drift between declared and actual state automatically). The fourth principle is what distinguishes GitOps from simply storing config in Git. A traditional CI pipeline stores config in Git and pushes it — there is no continuous reconciliation, no drift detection, and no single source of truth that is enforced rather than just referenced.

• →Every deployment is a Git commit: author, timestamp, and message are automatic — the audit trail compliance teams require exists without additional tooling
• →Rollbacks are reliable: reverting production to a known-good state is a git revert — not a manual re-deployment or a configuration database entry to track down
• →Developer credentials no longer need direct cluster access: the GitOps controller handles reconciliation with its own scoped service account, reducing the blast radius of a compromised developer credential
• →Drift is detected continuously: if someone manually edits a cluster resource outside the GitOps workflow, the controller detects the divergence and can alert or auto-correct
• →Self-service within guardrails: teams ship to production by merging a pull request through standard review — no separate deployment approval ticket required

GitOps vs Traditional CI/CD — What Actually Changes

In a conventional push-based CI/CD pipeline, your build system compiles code, runs tests, builds a container image, and then pushes the result to a cluster using kubectl, Helm, or a deployment API call. The pipeline is the deployment mechanism and it requires credentials that can write to production. In GitOps, the CI pipeline still builds and tests — but it stops at publishing the image and updating a version reference in a config repository. A controller inside the cluster detects that change and pulls it in. The cluster configures itself; nothing external holds the credentials to push in.

This separation has concrete operational consequences. When a push pipeline fails mid-deployment, recovery is manual — an engineer must diagnose what state the cluster is in and issue corrective commands. When a GitOps deployment fails, the desired state in Git has not changed; the controller retries automatically toward the declared state. Your production state is always either the last successful reconciliation or an in-progress retry — never an unknown intermediate.

Repository Structure: Monorepo, App-of-Apps, and Overlay Repos

Repository structure is the first architecture decision in any GitOps implementation and the most common source of maintenance problems later. The dominant patterns each have different scaling characteristics.

• →App repo plus config repo: application source code, Dockerfiles, and tests live in one repository; Kubernetes manifests and Helm values live in a separate config repo. This is the pattern the OpenGitOps project recommends and the one that scales best — code commits and config commits have different cadences, different reviewers, and different rollback semantics
• →Monorepo: all manifests and configs in a single repository. Simple to start, difficult to enforce granular access controls as team count grows, and causes unnecessary sync events when unrelated services change
• →App-of-Apps or ApplicationSet (ArgoCD): a parent Application manages child Applications declaratively. Changes to the parent trigger discovery and sync of new workloads. Best for teams managing dozens to hundreds of services where fleet-level rollouts need to be programmatic
• →Kustomize overlays: a shared base set of manifests with environment-specific patches applied on top — different image tags, resource limits, replica counts. Eliminates duplicate manifests across dev, staging, and production without adding a separate templating engine

The most operationally durable pattern at enterprise scale is the app-repo-plus-config-repo layout with Kustomize overlays per environment. The CI pipeline writes the new image tag to the config repo after a build passes; the GitOps controller detects the change and applies the environment overlay in sequence, with promotion gates between environments.

ArgoCD vs Flux CD — Which GitOps Tool Is Right for Your Team?

ArgoCD and Flux CD are the two CNCF-graduated GitOps engines for Kubernetes. Both implement pull-based reconciliation and can support all the patterns above. The decision is primarily about where your team's operational weight should fall.

• →ArgoCD ships with a web UI, a built-in multi-tenant RBAC model via Projects, and an ApplicationSet controller for fleet-level declarative application management. In 2026, ArgoCD 3.x introduced a significantly faster manifest parsing engine — sync time for large workload sets dropped from minutes to seconds compared to the 2.x branch. Best for enterprises where multiple teams share clusters and operators need a visibility-first experience
• →Flux CD is modular — the Flux toolkit is a set of composable controllers: source-controller, kustomize-controller, helm-controller, and notification-controller. No built-in UI (though Weave GitOps provides one as an optional layer). Flux has stronger Helm release management and more mature image update automation. Best for platform engineering teams who want composable infrastructure primitives and prefer a CLI-first workflow
• →Both engines support multi-cluster management, integrate with standard secret management backends, and emit Kubernetes events and Prometheus metrics for observability pipelines
• →For most enterprises starting a new GitOps practice, ArgoCD is the lower-friction entry point: the UI reduces onboarding time and makes debugging sync failures accessible to operators who are not yet GitOps experts

Managing Secrets in a GitOps Workflow

The most common misconception about GitOps is that secrets are incompatible with it because secret values cannot go in Git. Git is not the right place for secret values — but GitOps does not require them to be there. The correct pattern is to store references to secrets in Git and values in an external secrets management backend. Three approaches handle this well in production.

• →External Secrets Operator (ESO): the most widely adopted pattern in 2026. Secrets live in AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, or Azure Key Vault. ESO synchronizes them into Kubernetes Secrets on a configured schedule. Your config repository contains ExternalSecret resources that declare which secret should exist and where it comes from — not the values themselves. Rotation happens in the external store; ESO picks up new values on the next sync cycle
• →Sealed Secrets: Bitnami Sealed Secrets encrypts secret values with a cluster-specific public key before they are committed to Git. The SealedSecret CRD is safe to store in Git; the controller decrypts it inside the cluster. The limitation is cluster-specificity — a sealed secret cannot be reused across clusters without re-encryption
• →Vault Secrets Operator (VSO): for enterprises already running HashiCorp Vault as their secrets management plane, VSO syncs Vault secrets directly into Kubernetes Secrets or mounts them into pods, with support for Vault's native lease and rotation model. Provides the tightest Vault integration for teams already invested in that platform

External Secrets Operator is the right default for most enterprise GitOps implementations: it works with any major cloud secrets backend, supports rotation without cluster-side changes, and keeps references — not values — in your config repository where they belong in the audit trail.

Multi-Cluster and Multi-Environment Fleet Management

Operating GitOps across more than one cluster — multiple environments, multiple regions, or multiple teams with dedicated clusters — requires fleet management thinking from the beginning, not as an afterthought. Two architectural patterns dominate production deployments.

• →Hub-and-spoke (ArgoCD): a central ArgoCD instance runs in a management cluster; workload clusters are registered as sync targets. All application management and sync decisions happen from a single control plane. Operations teams get unified visibility. The management cluster needs high-availability configuration — it is a single operational failure point
• →Federated Flux: each cluster runs its own Flux controllers and reconciles from the same config repository, or from cluster-specific branches or directories. No central management plane — observability is aggregated from each cluster's Flux events. More resilient to management plane failures; more complex to achieve fleet-wide visibility
• →Environment promotion via Git: the clean pattern for multi-environment management is that promotion is a pull request. The CI pipeline writes a new image tag to the dev environment overlay after a successful build. A promotion check — automated integration tests or a human approver — opens a PR to update the staging overlay, and the same flow continues to production. The full promotion chain lives in your Git history
• →Progressive delivery integration: multi-cluster GitOps pairs naturally with Argo Rollouts or Flagger. You declare that a new version targets the dev cluster first, requires a manual promotion gate to staging, and then rolls to production clusters with an automatic rollback condition if error rate thresholds are crossed

GitOps Access Control and Security Posture

GitOps meaningfully reduces your security surface — removing direct kubectl access from developer credentials substantially limits the blast radius of a compromised account. But it introduces specific access control requirements that need deliberate design. For the CI pipeline security controls that sit alongside your GitOps access model, our DevSecOps and CI/CD pipeline security guide covers the build pipeline side of the delivery boundary.

• →Treat the config repository as production: everyone who can merge to the main branch of your GitOps config repo can deploy to production. Protect it with branch protection rules, required reviews, and CODEOWNERS files that route manifest changes to the team that owns each service
• →Least privilege for the GitOps controller: ArgoCD's service account and Flux's controllers should hold only the permissions needed to reconcile their target namespaces — not cluster-admin. Use namespace-scoped Applications where the workload pattern allows it
• →Policy enforcement before sync: integrate OPA/Gatekeeper or Kyverno policies that block sync of manifests violating your security baseline — images from unapproved registries, containers running as root, missing resource limits, or pods with host network access
• →Require commit signing on the config repo: the Git commit log is your deployment audit trail, but only if commits are attributed and history is not rewritten. Require signed commits and branch protection that prevents force-pushes
• →Scan manifests in CI before merge: run Checkov, Trivy, or kubeaudit on every pull request to the config repo. Shifting policy enforcement left means finding violations before they can be merged, not at admission time

Observability, Drift Detection, and Recovery

Continuous reconciliation means continuous observability — the GitOps controller knows at all times whether the cluster state matches the declared state in Git. ArgoCD and Flux both emit health and sync status as Kubernetes events, Prometheus metrics, and notification webhooks. Integrating these signals into your broader observability stack is covered in our OpenTelemetry enterprise observability guide, which covers fleet-level signal aggregation, alerting, and correlation across services and infrastructure.

• →Alert on OutOfSync status in production rather than auto-syncing: give operators visibility and a confirmation step before automatic corrections apply in production environments
• →Track DORA metrics from GitOps events: deployment frequency, lead time to production, and mean time to recovery all emerge naturally from commit timestamps and reconciliation events — wire them into your engineering metrics dashboard
• →Configure rollback triggers: Argo Rollouts can automatically roll back on error rate thresholds; pair this with GitOps promotion gates to prevent bad builds from propagating beyond the first affected environment
• →Maintain a break-glass procedure: define and test a runbook for applying emergency fixes directly to the cluster when Git is unavailable. After the emergency is resolved, reconcile Git to match the emergency state immediately — keep Git as the source of truth even in exceptional situations

Migrating from Traditional CI/CD to GitOps

If you are running push-based CI/CD today — GitHub Actions deploying to production via kubectl, a Jenkins job running Helm upgrades, or any pipeline with direct cluster credentials — migration to GitOps does not require rewriting everything at once. The safest path is incremental, service by service.

• →Start on a non-production environment: deploy the GitOps controller on a dev or staging cluster first and run it in parallel with the existing pipeline. Validate that the reconciliation loop works and that developers understand the new workflow before touching production
• →Migrate one service at a time: move configuration into the config repo service by service. Disable the push pipeline step for migrated services while leaving others unchanged. Run both approaches in parallel temporarily until the team is confident in the GitOps behavior
• →Separate the pipeline at the image boundary: the CI pipeline's job ends when the image is published and the config repo is updated with the new tag. It no longer needs cluster credentials. Revoke those credentials from CI service accounts as each service migrates
• →Audit and import existing cluster resources: after migration, identify cluster resources that were manually applied and are not tracked in Git. Import them into GitOps state or document them for removal — any resource outside Git is an undeclared dependency
• →Decommission push credentials: the goal state is a cluster where no external system holds credentials that can modify cluster resources directly. Reaching that state is when GitOps has fully replaced your push model and the security benefits are realized

Frequently Asked Questions

What is the difference between GitOps and CI/CD?

CI/CD describes a broad practice — continuous integration and continuous delivery. GitOps is a specific delivery model where Git is the authoritative source of truth and a controller inside the cluster continuously reconciles actual state to match what is declared in Git. A GitOps workflow still uses CI to build, test, and publish images — but the delivery step is handled by the reconciliation controller rather than a push-based pipeline. The core difference is pull vs push and continuous reconciliation vs point-in-time deployment execution.

Should I use ArgoCD or Flux for enterprise GitOps?

ArgoCD is the better starting point for most enterprise teams: its built-in web UI, multi-tenant Projects model, and RBAC make it easier to onboard operators and give multiple teams visibility into their deployments from day one. Flux is better for platform engineering teams building a self-service deployment platform — its modular controller architecture integrates more cleanly with custom Kubernetes tooling. Both are CNCF-graduated and production-ready at scale.

How do you manage secrets in a GitOps workflow?

Use External Secrets Operator with a managed secrets backend — AWS Secrets Manager, HashiCorp Vault, or GCP Secret Manager. Your Git repository contains ExternalSecret declarations: which secret should exist, from which backend, and how it maps to a Kubernetes Secret key. The actual secret values never appear in Git. ESO syncs them into Kubernetes Secrets on a configured schedule. For teams already operating HashiCorp Vault as their secrets management plane, the Vault Secrets Operator provides a native alternative with tighter Vault integration.

How do you handle multiple environments with GitOps?

Use Kustomize overlays: a base set of manifests shared across environments, with environment-specific patches applied on top for different image tags, replica counts, and resource limits. Each environment overlay lives in its own directory in the config repo. Promotion between environments is a pull request — the CI pipeline updates the dev overlay after a successful build, a human or automated check promotes to staging, and the same pattern continues to production. The full promotion history is captured in Git.

What is the biggest challenge of implementing GitOps at enterprise scale?

The hardest challenge is cultural, not technical. Developers accustomed to pushing deployments directly resist moving to a model where shipping to production means merging a pull request and waiting for a reconciliation cycle. Platform teams need to invest in making the GitOps workflow as low-friction as the previous push pipeline was. The technical complexity — multi-cluster management, secret handling, fleet rollouts — is tractable with the right tooling. The change management of rerouting how dozens of teams think about and trigger deployments is what most commonly stalls enterprise GitOps adoption.

How Belsoft Helps Implement GitOps

Belsoft designs and implements GitOps for engineering teams — from greenfield setups to migrations from existing push-based CI/CD — without disrupting production. We architect repository structures that scale to multi-team environments, configure ArgoCD or Flux for your cluster topology, integrate the secrets management backend that fits your security posture, and instrument the full delivery pipeline for observability. Our infrastructure and DevOps services cover the full stack from cluster design to delivery tooling — schedule a technical conversation to discuss how these patterns apply to your environment.

Teams scaling GitOps across a Kubernetes fleet often find that cost governance and delivery governance need to evolve together. Our Kubernetes cost optimization and FinOps guide covers right-sizing and spend governance practices that integrate naturally with a GitOps control model. If you are building the broader internal developer platform on top of GitOps, our platform engineering and IDP guide covers golden paths, self-service deployment, and the platform team operating model.

“GitOps is not a tool you install — it is a model you adopt. The Git repository is not where you store config; it is where your infrastructure makes its promises to you.”