Field note · Platform engineering
A public Flagger lab: Gateway API without hiding everything behind make#
I’m publishing a Kind workshop (Cilium, Envoy Gateway, Flagger) where attendees patch YAML to see who actually decides traffic.
The GitHub repository goes public on 13 October 2026 at 10:30 (Paris time).
Link: EtienneDeneuve/flagger-demo-kind.
Kubernetes can replace pods. It does not decide alone whether a revision deserves more traffic.
For platform workshops I packaged a macOS lab — Kind, Cilium, Envoy Gateway, Flagger, Prometheus — with one deliberate constraint: attendees apply files under manifests/tp/ instead of only running make good.
Three exercises:
- Promote — patch Deployment V2, HTTPRoute weights 25→50, then primary.
- Rollback — Ready pods + HTTP 5xx on the canary only; primary stays safe.
- A/B —
applya Canary withx-canarymatch, then a V4 revision for the cohort.
Repo (MIT): EtienneDeneuve/flagger-demo-kind.
English docs: README.en.md.
Upstream: Flagger Gateway API tutorial.
This is not a production template (no GitOps, no TLS, Podinfo app metrics for teaching). It is a lab for seeing the control loop that decides how traffic moves between revisions.

Has your platform become critical while every change gets harder to make safely?
Qualify ownership, failure modes and risks that keep the platform from evolving safely.
See the platform risk review See how I work with teams →
Omnivya is the company I co-founded with Taous, and where I serve as CTO. Structured engagements run through it.
For a question or a conversation without a sales brief: Get in touch · LinkedIn