State of GitOps 2026
A practical introduction for the team
Internal tech talk · 2026
Welcome. 1 hour total: about 40 min of slides, 10 min of live demo,
15 min Q&A. Goal is for the team to leave with a clear mental model
and for leadership to see the business case. Keep it conversational.
Today
How we deploy today
Push-based CI/CD. Familiar. Works. But…
The flow
Merge to main
Jenkins / GitLab CI runs
CI pushes to the cluster
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
Quick show of hands — who has debugged a deploy that worked in
staging but failed in prod? That's the problem we're going to
solve. Don't dwell — this is setup for the next slide.
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
Land each pain point with a half-second pause. These are the
enemies. Everything after this is how GitOps beats them.
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
Core line: "Git is the source of truth, cluster pulls, reconciles
continuously." Everything else is commentary.
The concept
Push → Pull
The fundamental flip.
(animation — click Next step to walk through)
Walk through the animation. Emphasize: in push, CI has
credentials and initiates; in pull, the controller watches Git
and initiates from *inside* the cluster. That one architectural
flip unlocks everything.
The concept
The 4 principles
Declarative — desired state, not imperative steps
Versioned & immutable — every change is a commit
Pulled automatically — the cluster fetches, not CI
Continuously reconciled — drift is detected and corrected forever
(reconciliation loop animation)
Source:
OpenGitOps — CNCF Working Group
Slow down on principle 4. "Continuously reconciled" is the
superpower — it's why drift disappears as a category of problem.
These 4 principles are directly from OpenGitOps (CNCF WG).
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
Foreshadow the challenges section. Don't spend long here — the
number is the point. Move on.
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.
Not a "vs" — both are CNCF graduated. Different tastes. We use
Argo for the demo because the UI sells the concept in seconds.
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
Argo CD deploys . Kargo promotes .
Key distinction: Argo CD answers "how does what's in Git get to
the cluster?" Kargo answers "how does what's in dev get to
prod?" Different problems, complementary tools.
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
Brief on purpose. The audience needs fundamentals more than
futures. Keep it at 45 seconds.
Live Demo
Argo CD → drift → rollback → Kargo promotion
Switch to browser · 10 minutes
Before switching windows: say what we're going to see.
1) Argo CD UI tour
2) Deploy a change through a git commit
3) Manually break things in the cluster — watch Argo heal
4) Roll back via git revert
5) Promote dev → staging in Kargo
Then come back to the deck for the business case.
Demo reference
Argo CD — applications view
Fallback slide if the live demo breaks — you can narrate over
this and the following screenshots.
Demo reference
Drift detection — what we'll see
We'll kubectl edit a running deployment
Argo CD marks it OutOfSync
Auto-sync (or manual click) reverts to Git state
(drift → self-heal animation)
The animation previews the live demo moment. If the demo works,
flash through this quickly. If the demo broke, this is your
fallback explanation.
Demo reference
Kargo — promoting a freight
Say out loud: "The green arrow means Kargo wrote a commit back
to the staging environment's Git folder. Argo CD then picks it
up and syncs. Two tools, one story."
So — what does it cost, what does it save?
The business case, in plain terms
Shift of voice here — this section is for decision makers. If
leadership is in the room, look at them.
Value
DORA metrics — before / after
The four indicators of elite engineering organisations.
Source:
DORA (Google Cloud) ·
2025 DORA Report
Don't read the bars — let the animation speak. Then say: "Every
one of these moves in the direction that reduces cost or
increases revenue velocity."
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
Point out the 47% — it's the one leaders tend to miss. The
hardest part of this change isn't buying a tool.
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
Incident — git 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
Don't read each line. Let leaders scan. Say: "Every row on the
right is either fewer engineering hours spent on incidents, or
lower risk at audit time. Both show up on the P&L."
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
This is the slide that answers "will this slow us down?" Answer:
no — and self-service means fewer ops bottlenecks.
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
Being honest here builds credibility. Don't hide the hard parts —
leadership already suspects they exist.
Plan
The "slow-slow-fast" path
From the field — this is how successful teams adopt GitOps.
Slow — pick one app. Non-critical, declarative-friendly, representative. Stand up Argo CD. Migrate deployment only.
Slow — polish the muscle. Let the team learn the pull-based mental model. Document the "break the glass" procedure. Measure before/after DORA.
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.
Emphasise: the first two stages are meant to be slow. That's
where the culture actually shifts. Fast only works because slow
came first.
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.
Close on a decision point. We're not asking for a blank check —
we're asking for one service and one quarter.
Questions?
15 minutes — fire away.
secrets
db migrations
git outages
jenkins fit
argo vs flux
kargo vs argo
If no questions: "let me prime with the ones I usually get" and
walk through the pills. That unsticks people.
Prep answers:
- Secrets: Sealed Secrets / External Secrets Operator / Vault. Never plaintext in Git.
- DB migrations: Atlas Operator, Argo CD hooks, init containers. Acknowledged hard.
- Git outage: Controller has last known state, multi-remote options, 330 outages H1 2025 per source.
- Fits Jenkins/GitLab CI how? CI still builds/tests. Deploy step moves to Argo CD.
- Argo or Flux? Argo for UI+governance, Flux for minimalist K8s-native.
- Kargo vs Argo? Argo deploys, Kargo promotes across stages.