State of GitOps 2026

A practical introduction for the team

Internal tech talk · 2026

Today

How we deploy today

Push-based CI/CD. Familiar. Works. But…

The flow

  1. Merge to main
  2. Jenkins / GitLab CI runs
  3. CI pushes to the cluster
  4. Hope nothing drifted since last time

What lives where

  • Git — source code
  • CI server — deploy credentials, kubeconfig
  • Cluster — the "real" state nobody can see without kubectl
Today

The cracks

  • Credentials in CI — Jenkins holds the keys to prod. Anyone with Jenkins access has cluster access.
  • Drift — someone kubectl edits for a hotfix. Git no longer matches the cluster. Nobody remembers.
  • Rollback = new pipeline run — you're not really rolling back, you're re-deploying an older artifact. If the pipeline is broken, you're stuck.
  • No single source of truth — "what's actually running?" requires logging into the cluster.
  • Audit = screenshots — compliance asks "prove what was deployed on 12 March." You can't.

Sources: Octopus — State of GitOps 2025 · CNCF — GitOps in 2025

The concept

What is GitOps?

An operating model where Git is the source of truth for everything that runs in the cluster, and a controller inside the cluster pulls changes and reconciles them continuously.

It's not

  • A product
  • A CI pipeline
  • Just "putting YAML in Git"

It is

  • Declarative desired state
  • Pulled by the cluster
  • Reconciled forever
The concept

Push → Pull

The fundamental flip.

(animation — click Next step to walk through)

The concept

The 4 principles

  1. Declarative — desired state, not imperative steps
  2. Versioned & immutable — every change is a commit
  3. Pulled automatically — the cluster fetches, not CI
  4. Continuously reconciled — drift is detected and corrected forever

(reconciliation loop animation)

Source: OpenGitOps — CNCF Working Group

Reality check

The declarative gap

Everybody claims GitOps. Few actually do it.

64%
claim GitOps adoption
40%
actually use declarative configuration
24 pt
gap between aspiration and practice

The gap is where the hard work lives — legacy deploy scripts, imperative helper tooling, people reaching for kubectl under pressure. We'll come back to this in "challenges."

Source: Octopus — State of GitOps Report 2025

Tools 2026

The two main controllers

Argo CD 3.x

CNCF Graduated

  • Rich web UI — sync status, diffs, rollback
  • Centralized governance, fine-grained RBAC
  • ApplicationSet for fleets of apps
  • Great first impression for newcomers

→ We'll demo this one.

Flux CD v2.8

CNCF Graduated

  • CLI-first, minimalist, Kubernetes-native
  • OCI-native delivery
  • Post-quantum age cipher for secrets
  • Lower overhead, no central UI

→ Philosophy, not competition.

Pick Argo CD for UI-heavy, governance-first orgs. Pick Flux when you want Kubernetes-native minimalism and no central control plane.

Tools 2026

The broader ecosystem

Around the controllers

  • Kargo — promote dev → staging → prod (we'll demo)
  • Backstage / Red Hat Developer Hub — internal developer portal
  • Kyverno — policy-as-code guardrails
  • OpenTofu — community-driven Terraform fork
  • Sealed Secrets / ESO / Vault — secrets that can live in Git

Kargo — the promotion layer

(promotion pipeline animation)

Argo CD deploys. Kargo promotes.

Tools 2026

What's new in 2026

One slide on frontier trends — don't get distracted by shiny.

  • AI-driven compliance — 75% of orgs projected to use AI in compliance by 2026
  • Agentic orchestration — AI agents opening PRs, not just reviewing
  • Edge Kubernetes — K3s at Tesla / CERN, <100 MB footprint
  • Sovereignty — SNCF & EU orgs abstracting from US-cloud lock-in
  • 80% of orgs expected to run an Internal Developer Platform
  • Continuous compliance — audit baked into the pipeline, not retrofitted

Source: CNCF Annual Cloud Native Survey 2025

Live Demo

Argo CD → drift → rollback → Kargo promotion

Switch to browser · 10 minutes

Demo reference

Argo CD — applications view

Argo CD Applications view showing the ecom-demo app
Demo reference

Drift detection — what we'll see

  1. We'll kubectl edit a running deployment
  2. Argo CD marks it OutOfSync
  3. Auto-sync (or manual click) reverts to Git state

(drift → self-heal animation)

Demo reference

Kargo — promoting a freight

Kargo UI showing dev, staging and prod stages with a freight promoted from dev to staging

So — what does it cost, what does it save?

The business case, in plain terms

Value

DORA metrics — before / after

The four indicators of elite engineering organisations.

(animated bar chart)

Source: DORA (Google Cloud) · 2025 DORA Report

Value

What the field reports

81%
report higher infrastructure reliability & faster rollbacks
64%
of DevOps teams integrated GitOps by 2026
75%
of compliance work projected to be AI-automated
80%
of orgs expected to run an Internal Developer Platform
58%
adoption among cloud-native "innovators"
47%
cite cultural change — not tech — as #1 barrier

Sources: CNCF Annual Survey 2025 · State of GitOps 2025

Value

Before / after — what changes

Before

  • Incident — page human, rerun pipeline, hope
  • Rollback — a new deploy of an old artifact
  • Audit — screenshots, tribal knowledge
  • Access — shared kubeconfigs, rotating Jenkins creds
  • Env parity — "works on staging"

After

  • Incidentgit revert; cluster self-heals
  • Rollback — Git history, one commit away
  • Audit — Git log is the audit trail
  • Access — nobody holds cluster creds; controller does
  • Env parity — same manifests, different values files
Value

Developer velocity — what stays, what improves

Unchanged for developers

  • Same IDE, same branches
  • Same PR workflow
  • Same CI for build, test, image push

GitOps replaces the deploy step only. Pipelines get shorter, not rewritten.

What improves

  • Self-service via Internal Developer Portals (Backstage / Developer Hub)
  • Env provisioning via PR — no ops ticket
  • Promotion via Kargo — no bespoke promotion scripts
  • Fewer "please deploy this for me" asks to SRE
Honest

It's not free — what we'll hit

  • Cultural change is the real blocker — 47% of adopters call it #1. "ClickOps under pressure" is a habit, not a tooling problem.
  • Stateful workloads & DB migrations — genuinely hard. Atlas Operator, Argo Hooks, init containers. Plan carefully.
  • Git platform outages — 330 DevOps platform outages in H1 2025 alone. Mitigations: local controller cache, multi-remote.
  • Secrets management — you can't just commit them. Sealed Secrets, External Secrets Operator, Vault. Pick one early.
  • Skill gap — declarative thinking is a learned muscle. Budget for training time.

Sources: State of GitOps 2025 · CNCF — GitOps in 2025

Plan

The "slow-slow-fast" path

From the field — this is how successful teams adopt GitOps.

  1. Slow — pick one app. Non-critical, declarative-friendly, representative. Stand up Argo CD. Migrate deployment only.
  2. Slow — polish the muscle. Let the team learn the pull-based mental model. Document the "break the glass" procedure. Measure before/after DORA.
  3. Fast — scale the proven pattern. Add ApplicationSets, bring in Kargo for promotion, onboard more teams with a portal (Backstage).

What kills adoption: "let's migrate everything in Q2." Nothing ages a GitOps initiative faster than trying to boil the ocean.

Our next steps

What this looks like for us

This quarter

  • Pick one candidate service (suggestions welcome)
  • Stand up Argo CD on our dev cluster
  • Migrate its deploy step from GitLab CI to Argo CD
  • Baseline DORA metrics before

Next quarter

  • Add Kargo for dev → staging → prod promotion
  • Pick a secrets strategy (ESO or Sealed Secrets)
  • Measure DORA after. Share results.
  • Decide: expand or pause.

Small enough to fit around normal work. Large enough to learn whether GitOps suits us.

Questions?

15 minutes — fire away.

secrets db migrations git outages jenkins fit argo vs flux kargo vs argo