Somewhere in the last year, “GitOps” quietly stopped being a talk track at KubeCon and started being the thing platform teams assume is already in place before a project even gets a name. Argo and Flux both sit at CNCF graduated status now, the highest maturity tier the foundation hands out, and the conference circuit has moved on from “should you adopt GitOps” to “how do you build a self-service golden path on top of it.” That’s the industry’s definition of maturity: a pattern boring enough that nobody has to argue for it any more.
I want to test that claim against something small and unglamorous — this blog. Not because a Hugo site is an impressive workload, but because it’s the opposite of one, and the pipeline that ships it doesn’t know that. Every push to main goes through the same promotion discipline — build, scan, gate, promote, verify, cut traffic — that I’d expect from a production banking platform. Nobody has to remember a manual step, because there isn’t one.
What “Mature” Actually Means#
Graduated CNCF status is a governance signal — it tells you a project has multiple independent adopters, a documented security process, and isn’t going to disappear if one maintainer changes jobs. It doesn’t, by itself, tell you anything about whether the pattern built on top of that project has become boring in practice. Those are different claims, and the industry narrative tends to blur them.
The pattern is mature when three things are true at the same time:
- A change lands in Git and reaches production without a human doing a deploy step — not “without a human clicking a button they could theoretically skip,” but genuinely no manual action required for the common path.
- Failure is caught before it’s customer-visible, by something the pipeline runs automatically, not by someone noticing the site looks wrong.
- The tools involved have become narrow and boring — each one does one job, and nobody’s tempted to make ArgoCD decide when to promote, or Kargo decide how to route traffic, just because it happens to have API access to do so.
That third point is where I see the most GitOps setups quietly fail the maturity test, even with graduated tooling underneath them. People bolt promotion logic into ArgoCD sync waves, or wire traffic-shifting into a CI script, because it’s possible, and possible is a bad reason to do anything with the deploy path.
The Proof, Not Re-Explained#
I’ve already written up the mechanics twice, in detail, and I’m not doing it a third time here. How This Blog Is Served covers the full path — Gitea webhook, Argo Events, Argo Workflows building and scanning, ArgoCD syncing, Argo Rollouts cutting blue-green traffic. Progressive Delivery with Kargo covers the layer in between: Warehouses, Freight, Stages, and the two silent-failure gotchas that took longer to find than to fix.
What matters for this post is the shape, not the steps:
(automated)"] B --> C["promotion gate
(automated)"] C --> D["verify
(automated: Playwright + k6)"] D --> E{"human decision"} E -->|"cut traffic"| F["live"]
There is exactly one human decision point left in the entire path, and it’s deliberate rather than accidental: kubectl argo rollouts promote blog -n blog, the moment production traffic actually moves. Everything upstream of it — the build, the CVE scan, the SonarQube gate, the Freight promotion, the Playwright run against the preview URL — happens with nobody watching. That’s not a claim about how sophisticated the tooling is. It’s a claim about how little of my attention this blog’s deploys currently cost me, which is the only metric that actually matters for “mature.”
Two Very Different Scales, One Shape#
The part I find genuinely interesting isn’t that this pipeline exists — it’s that the shape of it is identical to what I design professionally, at a scale where the stakes are real money and regulatory exposure rather than a static site going down for ten minutes.
| This blog (homelab) | Banking platform (day job) | |
|---|---|---|
| Source of truth | Git repo, one operator | Git repos per team, GitOps-managed landing zones |
| Build gate | SonarQube + Trivy, fail on CRITICAL | Security gate before any image touches an environment — no exceptions |
| Promotion logic | Kargo Warehouse/Freight/Stage, auto-promote to preview | Change-managed promotion, environment-gated, audit-logged |
| Verification | Playwright + k6 AnalysisTemplate against a preview URL | Automated pre-promotion testing plus manual sign-off for regulated changes |
| Final production cut | One human, one kubectl argo rollouts promote | Deliberate go/no-go, often with a second approver |
| Why the gate exists | I don’t want to break my own blog | POPIA/PCI-DSS-scoped systems where a bad release has compliance consequences, not just downtime |
| Cost of getting it wrong | Ten minutes of a personal site being stale | Audit finding, regulatory exposure, real customer impact |
The rows that differ are the stakes. The rows that match are the discipline — and that’s the part the “GitOps has reached maturity” narrative is actually describing. It’s not that a homelab blog and a banking platform run the same software. It’s that the pattern of “nothing reaches production without passing through the same automated gate, every time, regardless of who’s watching” no longer needs to be justified from scratch at either scale. Five years ago I’d have had to argue for it. Today it’s just how the pipeline is built, at both ends of the size spectrum I operate in.
A pipeline you have to remember to use correctly isn’t GitOps yet — it’s a runbook with extra steps.
What’s Still Genuinely Hard#
None of the above means GitOps has become a solved problem you can install and forget. Maturity moved the hard parts, it didn’t remove them. Three that I keep running into, all on a pipeline I’d otherwise call boring:
Secrets rotation. This blog’s Git credentials for Kargo’s bot commits, the ArgoCD repo credentials, the Cloudflare API token cert-manager uses for DNS-01 challenges — all of it is SealedSecrets-encrypted in Git, which solves “can a secret live safely in a public-ish repo” and does nothing for “when did this token last rotate, and what breaks silently if it expires mid-promotion.” SealedSecrets protects the secret at rest; it has no opinion on its lifecycle. That’s still a manual calendar reminder, not a pipeline step, and I don’t think that’s unique to a homelab — rotation discipline is one of the things I see enterprise GitOps rollouts underestimate too, because the tooling makes storing secrets easy and says nothing about ageing them out.
Promotion policy tuning. AutoPromotionEnabled living on a separate ProjectConfig resource rather than the Stage itself, or an authorization annotation that silently mis-parses a comma-separated value — these aren’t bugs in the sense of something being broken. They’re the accumulated small decisions a promotion policy is made of, and getting them right the first time requires already knowing the failure mode you’re trying to avoid. I hit both of the Kargo gotchas mid-setup, not because Kargo is immature, but because my policy was under-specified in ways that only showed up as silence, not errors.
Debugging a stuck sync. ArgoCD’s job is narrow by design — diff Git against cluster, reconcile — and that narrowness is exactly why a stuck sync is hard to debug: the tool that would tell you why isn’t the tool that decided anything upstream. A Freight sitting fully “Fulfilled” against a Stage with no Promotion firing looks identical, from the ArgoCD dashboard, to a dozen other unrelated failure modes. The fix, both times it happened here, was kubectl -n kargo logs -l app.kubernetes.io/name=kargo and status.conditions on the Kargo resources themselves — because the layer that owns the decision is the only layer that can explain the silence.
None of these are arguments against the pattern. They’re the residue “mature” leaves behind once the deploy step itself stops being the interesting problem. The industry conversation has mostly moved past “should GitOps own your deploys” to “how do you build self-service golden paths on top of it” — and that shift only makes sense once you’ve accepted that the boring, reliable core is a given, and the actual engineering work has moved to the edges: policy, verification, and the slow accumulation of small operational knowledge about how your pipeline fails.
Summary#
GitOps reaching maturity in 2026 doesn’t mean the problem is solved — it means the deploy step itself has stopped being where the interesting engineering happens, at scales as different as a personal blog and a regulated banking platform. Git push to live traffic, on this blog, now involves build, scan, promotion gating, and automated verification with exactly one deliberate human decision left in the loop — the same shape I design professionally, just with lower stakes if it breaks. What’s left to get right is no longer “does GitOps work” but the unglamorous edges around it: rotating what’s encrypted rather than just encrypting it, tuning a promotion policy before its gaps show up as silence, and knowing which layer’s logs actually explain a stuck sync. That’s what maturity looks like from the inside — not less work, just work that moved.