Gitops on Chris Wagner

Why I Started Thinking Like a Platform-Engineering Product Owner, Not Just a DevOps Engineer

cw@wagner.org.za (Chrisando Wagner) — Mon, 14 Sep 2026 00:00:00 +0000

Over the last few weeks I’ve been laying out how platform engineering grew out of DevOps practice, and what actually separates the two once you stop treating them as synonyms. This post is smaller than either of those, and more personal. It’s not an argument about where the industry is heading. It’s about a question I noticed I’d started asking myself before any other question, and what changed once I did.

What My Homelab Pipeline Would Look Like as an Internal Developer Platform

cw@wagner.org.za (Chrisando Wagner) — Mon, 07 Sep 2026 00:00:00 +0000

I’ve been building toward this over the last couple of weeks — writing about how platform engineering split off from DevOps as a discipline, and about the difference between “we all own operations” as a culture and a team whose actual job is building the platform other teams stand on. This post is where I stop talking about that distinction in the abstract and point it at something I’ve actually built.

DevOps Is a Culture. Platform Engineering Is a Product Team. That Difference Matters More Than People Admit

cw@wagner.org.za (Chrisando Wagner) — Mon, 31 Aug 2026 00:00:00 +0000

I covered where platform engineering actually comes from last week — the short version is that it’s what happens when “you build it, you run it” hits an organisation large enough that nobody can hold the whole picture in their head any more. This week I want to sit with a distinction that gets blurred constantly, in job specs, in conference talks, in the way people casually use “DevOps team” and “platform team” as if they’re the same noun with a rebrand: they are not the same thing, in kind, not just in degree.

Platform Engineering Didn't Replace DevOps — It's DevOps Grown Up Enough to Ship as a Product

cw@wagner.org.za (Chrisando Wagner) — Mon, 24 Aug 2026 00:00:00 +0000

I keep seeing some version of the same argument on LinkedIn: platform engineering is killing DevOps, or DevOps was always a fad and platform engineering is the “real” discipline that replaced it, or — my least favourite — that the two terms are just marketing labels for the same job with a new coat of paint every few years so vendors have something to sell at KubeCon. None of that matches what I’ve actually watched happen, either in my own homelab or in twenty-five years of building infrastructure for other people’s businesses. So this is post one of five where I want to work through it properly, using a pipeline I actually operate rather than a diagram borrowed from a vendor deck.

GitOps Reached Maturity in 2026 — Here's What That Actually Looks Like Running Your Own Blog

cw@wagner.org.za (Chrisando Wagner) — Mon, 27 Jul 2026 00:00:00 +0000

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.

POPIA, PCI-DSS, and My Proxmox Cluster: Bank-Grade Security at Home

cw@wagner.org.za (Chrisando Wagner) — Mon, 27 Jul 2026 00:00:00 +0000

A recruiter once asked me, half-joking, whether I ran my home network “like a bank.” I laughed, said no, and then drove home and found I’d left a Grafana dashboard exposed on a LoadBalancer IP with no auth in front of it. That was years ago, before the current cluster existed, but the discomfort of that gap never quite left me. My day job is Cloud Architect at a banking group, where POPIA and PCI-DSS aren’t abstractions — they’re the reason certain designs get rejected in review before they ever reach a pull request. My homelab is not a bank. Nobody’s card data lives on it, no regulator will ever audit it, and I will say that plainly and repeatedly in this post so nobody mistakes what follows for a legal claim. What I’ve done instead is take the discipline those regulations instil — because I practise it forty hours a week whether I like it or not — and apply it to four nodes and a Mikrotik router in a room in Johannesburg.

Progressive Delivery with Kargo: Warehouses, Freight, and Blue-Green Promotions

cw@wagner.org.za (Chrisando Wagner) — Mon, 13 Jul 2026 00:00:00 +0000

How This Blog Is Served walked through the full path from git push to a served page, touching every layer along the way. This post stays in one place: Kargo, the piece that sits between “CI built a new image” and “ArgoCD is told to deploy it.” It’s the part of the pipeline most likely to look like magic from the outside, so this is a proper look at what it’s actually doing — plus a couple of real gotchas hit while getting auto-promotion working correctly.

How This Blog Is Served — Kubernetes, Gateway API, and a Full GitOps Pipeline

cw@wagner.org.za (Chrisando Wagner) — Fri, 17 Apr 2026 00:00:00 +0000

This blog runs on a self-hosted k3s cluster, served through a Cloudflare proxy, routed via the Kubernetes Gateway API, and deployed using a fully automated GitOps pipeline. This post walks through exactly how a git push to main makes it to your browser — from webhook to blue-green promotion.

Source: git.wagner.org.za/cw/blog

The Full Picture
#

Before diving into each layer, here is the end-to-end flow:

Homelab Part 4 - k3s Automation

cw@wagner.org.za (Chrisando Wagner) — Mon, 06 Apr 2026 00:00:00 +0000

In Part 3 we deployed k3s manually — great for understanding what each piece does, but not something you want to repeat. This post automates the entire thing: Terraform provisions the VMs, Ansible configures them and installs k3s + Cilium, and ArgoCD bootstraps itself and takes over GitOps management of the full cluster stack.

Source: git.wagner.org.za/homelab/k3s-proxmox-automation

Architecture
#

┌──────────────────────────────────────────────────────────────────────────────┐
│ Proxmox Host │
│ │
│ ┌─────────────────┐ ┌───────────────┐ ┌───────────────┐ ┌────────────┐ │
│ │ k3s-controller │ │ k3s-worker-01 │ │ k3s-worker-02 │ │k3s-worker │ │
│ │ 172.16.10.1 │ │ 172.16.10.2 │ │ 172.16.10.3 │ │172.16.10.4 │ │
│ │ 8 cores / 16 GB │ │ 16c / 32 GB │ │ 16c / 32 GB │ │16c / 32 GB │ │
│ │ vda: 200 GB │ │ vda: 200 GB │ │ vda: 200 GB │ │vda: 200 GB │ │
│ │ │ │ vdb: 512 GB │ │ vdb: 512 GB │ │vdb: 512 GB │ │
│ │ k3s server │ │ vdc: 512 GB │ │ vdc: 512 GB │ │vdc: 512 GB │ │
│ │ Cilium / ArgoCD │ │ k3s agent │ │ k3s agent │ │k3s agent │ │
│ └────────┬────────┘ └──────┬────────┘ └──────┬────────┘ └─────┬──────┘ │
│ └───────────────-──┴──────────────────┴────────────-────┘ │
└──────────────────────────────────────────────────────────────────────────────┘

graph TB subgraph Proxmox["Proxmox Host"] C["k3s-controller-01
172.16.10.1
8c / 16 GB
vda: 200 GB OS
─────────────
k3s server
Cilium · ArgoCD"] W1["k3s-worker-01
172.16.10.2
16c / 32 GB
vda: 200 GB OS
vdb: 512 GB DirectPV
vdc: 512 GB Longhorn
─────────────
k3s agent"] W2["k3s-worker-02
172.16.10.3
16c / 32 GB
vda: 200 GB OS
vdb: 512 GB DirectPV
vdc: 512 GB Longhorn
─────────────
k3s agent"] W3["k3s-worker-03
172.16.10.4
16c / 32 GB
vda: 200 GB OS
vdb: 512 GB DirectPV
vdc: 512 GB Longhorn
─────────────
k3s agent"] end C -->|k3s API :6443| W1 C -->|k3s API :6443| W2 C -->|k3s API :6443| W3 C & W1 & W2 & W3 -->|eBGP AS 65000| R["Router
172.16.10.254"] R -->|advertises LB pool
172.16.1.0/24| NET["Network"]

Each worker gets three disks: