Case 04 · Flagship

GitOps: Argo CD & Flux

GitOps is not just a deployment tool choice. It is a platform contract for how teams promote, observe, roll back, and audit Kubernetes state.

01

How it works

From Git intent to a reviewable sync.

GitOps delivery by Andrey Lesnikov — declare desired state, sync with Argo CD or Flux, prove health, and design rollback before pressure.

Architecture diagram of GitOps delivery: Git sources, control plane, cluster state, ownership contract
Control plane first: declare → sync → health / drift → rollback contract.
Animated GitOps lifecycle: Declare, Sync, Health, Rollback
Lifecycle — Declare → Sync → Health → Rollback
  1. 01

    Declare desired state

    Repos layouts, overlays, and secret references make intent reviewable before anything reaches the cluster.

  2. 02

    Sync with ownership

    Argo CD or Flux applies state under clear promotion rules — tool choice follows the platform contract, not the other way around.

  3. 03

    Prove health

    Sync waves, health checks, and drift detection keep cluster reality honest against Git.

  4. 04

    Rollback on purpose

    Rollback paths are designed while calm so production pressure does not invent the recovery story.

02

Evidence

From problem to proof.

How the system is framed, operated, and proven — not a slide deck summary.

01
Problem

Teams often discuss Argo CD versus Flux as a preference debate. The harder question is ownership: who controls sync, environments, secrets, drift, rollback, and developer feedback?

02
Architecture

A GitOps platform defines repository layout, environment overlays, sync waves, health checks, policy boundaries, secret handling, and rollback contracts.

03
Trade-offs

Argo CD offers strong visual operations; Flux fits controller-native workflows. The right decision depends on team model, governance, and platform ownership.

04
Latest evidence

gitops-duel runs Argo CD and Flux side by side on kind and benchmarks them with N=3 samples (median, min/max). Profile equal-10s: time to ready 3.759 s (Argo CD) vs 6.167 s (Flux), self-heal 3.666 s vs 12.767 s, deletion recovery 3.130 s vs 70.208 s, commit→ready 19.068 s vs 8.289 s (Demo results run 38131680035, docs/results.md). The ui-backend is hardened: namespaced RBAC, allowlisted git-manifests hosts and size limits; API bearer token is always required for /api (PR #30) — startup fails without UI_API_TOKEN unless AUTH_DISABLED=true for local lab (GitOps Duel CI run 38137426553). Lab timings on sample nginx apps, not production sync SLOs.

Constraints

Multi-environment promotion, drift detection, rollback safety, secret handling, and developer feedback loops.

03

Related

Nearby systems.

Case 14 · Pattern

Argo CD App of Apps

  • Root App
  • Children
  • Waves

As platforms grow, application onboarding, add-ons, and environment drift become hard to reason about

Platform bootstrapable from Git

Case 12 · Pattern

Multi-Region GitOps

  • Git
  • Overlays
  • Sync

Multi-region systems need repeatable promotion and rollback without turning every deployment into manual coordination

Regional drift stays auditable

Case 24 · Flagship

Architecture Rehearsal

  • Go
  • Kubernetes
  • Helm

Teams discover architectural blast radius only after a change lands in production

Pre-deploy break risk → verified after change

Available for meaningful infrastructure conversations

Build systems that stay calm under pressure.

Available for conversations

Talk infrastructure

Book a working session

Meet ↗

Evidence first

For deep dives

Explore the systems

All cases ↗