GitOps: Modern Deployment Strategies with ArgoCD and Flux

GitOps takes a straightforward idea - Git as the single source of truth for infrastructure and application state - and turns it into a powerful operational model. Instead of engineers running deployment commands or clicking through CI/CD dashboards, the desired state is declared in Git and a controller continuously reconciles the actual state of the system to match.

The result is deployments that are auditable (every change is a Git commit), reversible (revert a commit to roll back), and reproducible (clone the repo and you can recreate the entire environment). This guide covers how to implement GitOps effectively using the two most mature tools in the ecosystem: ArgoCD and Flux.

GitOps Principles

GitOps is built on four core principles that distinguish it from traditional CI/CD:

Declarative configuration. The entire system - Kubernetes manifests, Helm charts, Kustomize overlays, infrastructure definitions - is described declaratively in Git. There are no imperative scripts that "do things." Instead, you declare what the system should look like and the GitOps controller makes it so.

Version controlled and immutable. Git provides a complete history of every change: who made it, when, why (commit message), and who approved it (PR review). This audit trail satisfies compliance requirements that traditional deployment pipelines struggle with.

Automatically applied. A GitOps controller (ArgoCD or Flux) continuously watches the Git repository and applies changes automatically when the desired state diverges from the actual state. No human triggers the deployment - merging to the main branch is the deployment.

Continuously reconciled. The controller does not just apply changes once. It continuously compares the actual cluster state against the desired state in Git and corrects any drift. If someone manually modifies a Kubernetes resource, the controller reverts it to match Git. This self-healing property eliminates configuration drift.

ArgoCD: Architecture and Setup

ArgoCD is a declarative GitOps continuous delivery tool for Kubernetes. It runs as a set of controllers in your cluster and provides both a CLI and a web UI for managing applications.

Core concepts:

• Application. An ArgoCD Application defines a source (Git repository, path, and revision) and a destination (Kubernetes cluster and namespace). ArgoCD monitors the source and syncs changes to the destination.
• AppProject. Projects group applications and define access controls: which repositories can be used, which clusters and namespaces can be targeted, and which resource types can be deployed.
• Sync. The process of applying the desired state from Git to the cluster. Syncs can be automatic (triggered by Git changes) or manual (triggered by an operator).

Production setup recommendations:

Install ArgoCD in a dedicated management cluster rather than the application clusters it manages. This separation means an issue in a workload cluster does not affect the deployment system. ArgoCD manages itself (its own configuration is in Git) and manages applications across multiple clusters.

Enable SSO integration with your identity provider (Okta, Auth0, Google Workspace) for authentication. Define RBAC policies that restrict which teams can sync which applications. Use AppProjects to enforce boundaries - the frontend team's project should not be able to deploy to the backend namespace.

Repository structure for ArgoCD:

gitops-repo/
  apps/
    production/
      frontend.yaml      # ArgoCD Application manifest
      backend.yaml
      monitoring.yaml
    staging/
      frontend.yaml
      backend.yaml
  manifests/
    frontend/
      base/
        deployment.yaml
        service.yaml
        kustomization.yaml
      overlays/
        production/
          kustomization.yaml
        staging/
          kustomization.yaml
    backend/
      base/
      overlays/

ArgoCD Application manifests in apps/ point to the appropriate overlay paths in manifests/. This separation keeps the application definitions clean and the Kubernetes manifests reusable across environments.

Flux: Architecture and Setup

Flux is the CNCF-graduated GitOps toolkit that takes a more composable approach than ArgoCD. Instead of a monolithic application, Flux consists of specialized controllers that handle different aspects of the GitOps workflow.

Flux controllers:

• Source Controller watches Git repositories, Helm repositories, and S3 buckets for changes.
• Kustomize Controller reconciles Kustomize overlays and plain Kubernetes manifests.
• Helm Controller reconciles Helm chart releases.
• Notification Controller handles inbound webhooks (for triggering reconciliation) and outbound notifications (alerting on sync status).
• Image Automation Controllers update Git when new container images are available, closing the GitOps loop for image updates.

Where Flux shines:

Flux's image automation is its standout feature. When a new container image is pushed to a registry, Flux automatically updates the image tag in the Git repository and commits the change. This eliminates the manual step of updating image tags in manifests after a CI build, creating a fully automated path from code commit to production deployment.

Flux is also lighter weight than ArgoCD. It has no web UI (management is entirely through Git and CLI), which reduces the attack surface and resource footprint. For teams comfortable with CLI-first workflows, this is an advantage.

Flux multi-tenancy model:

Flux supports multi-tenancy through Kubernetes namespaces and RBAC. Each team gets a namespace with a Flux Kustomization that points to their directory in the Git repository. Teams can only deploy to their namespaces, and the platform team controls shared infrastructure through a separate Kustomization.

Deployment Strategies in GitOps

GitOps does not prescribe a specific deployment strategy. You implement progressive delivery patterns on top of the GitOps reconciliation model.

Rolling updates are the default Kubernetes deployment strategy and work naturally with GitOps. Update the image tag in Git, ArgoCD or Flux applies the change, and Kubernetes rolls out new pods incrementally.

Blue-green deployments in GitOps involve maintaining two sets of manifests (blue and green) and switching the service selector between them. The Git commit that switches traffic is the deployment event, and reverting that commit is the rollback.

Canary deployments require a progressive delivery controller like Argo Rollouts (companion to ArgoCD) or Flagger (companion to Flux). These tools automate the canary process: deploy the new version to a small percentage of traffic, monitor metrics, and progressively increase traffic if metrics are healthy.

Argo Rollouts integration with ArgoCD:

Replace standard Kubernetes Deployments with Argo Rollouts resources. Define a canary strategy that sends 10% of traffic to the new version, waits 5 minutes, checks success rate and latency metrics from Prometheus, then increases to 30%, 60%, and finally 100%. If metrics degrade at any step, the rollout automatically rolls back.

Flagger integration with Flux:

Flagger watches Deployments and automatically creates canary resources. It integrates with Istio, Linkerd, Contour, or AWS App Mesh for traffic splitting and Prometheus for metrics analysis. The workflow is similar to Argo Rollouts but operates as a standalone controller rather than a replacement resource type.

Managing Secrets in GitOps

The biggest challenge in GitOps is secrets. If Git is the source of truth, how do you store database passwords and API keys without committing plaintext secrets to a repository?

Sealed Secrets by Bitnami encrypt secrets using a cluster-specific public key. The encrypted SealedSecret resource is safe to commit to Git. The Sealed Secrets controller in the cluster decrypts it and creates a standard Kubernetes Secret. This is simple and effective for smaller deployments.

SOPS (Secrets OPerationS) by Mozilla encrypts secret values within YAML files using KMS keys (AWS, GCP, Azure), PGP, or age. Flux has native SOPS integration - it decrypts SOPS-encrypted files during reconciliation. This keeps secrets in Git (encrypted) while allowing the GitOps controller to decrypt them at apply time.

External Secrets Operator syncs secrets from external stores (AWS Secrets Manager, HashiCorp Vault, Google Secret Manager) into Kubernetes Secrets. The Git repository contains ExternalSecret resources that reference the external secret path. The actual secret value never touches Git.

Recommendation: For most teams, External Secrets Operator with AWS Secrets Manager or HashiCorp Vault provides the best balance of security and operational simplicity. Secret rotation happens in the external store and is automatically reflected in the cluster.

ArgoCD vs Flux: Choosing the Right Tool

Both tools implement GitOps effectively. The choice comes down to operational preferences and ecosystem fit.

Choose ArgoCD if your team values a visual interface, you manage multiple clusters, and you want Argo Rollouts for progressive delivery. Choose Flux if you prefer CLI-first workflows, need native image automation, and want a lighter-weight solution.