Talks
Upcoming
We GitOps'd Everything Except the Settings That Break Production
Software teams have a delivery process for code. But what about the runtime configuration around that code? It is often self-service for end users, hidden behind admin screens and custom database tables, and changed outside the delivery process. Feature flags, business rules, and specific domain settings can change production behaviour just as much as new code.
This talk starts with application settings that broke production, and each one leads back to the same uncomfortable questions: who made the change, where was it validated, and how do we stop the next one? Could important product configuration live in a separate Git repo, reviewed and promoted like code, while the people who change it never see Git and just use a nice settings screen? The session covers the design of an open-source tool built to explore this, where it gets hard (conflicts, concurrency, and putting real authors on Git commits), and a live demo with the whole audience as admins.
Configuration Deserves a Software Delivery Process Too
Configuration is often some of the most critical logic in a system, yet many teams still manage it with far less discipline than code. It lives in databases, gets edited through admin screens, bypasses proper review, mixes awkwardly with secrets, and moves across environments with limited testing and weak packaging boundaries.
This talk argues that configuration should be treated as a delivery problem, not just a storage problem: capture validated intent through an API, then turn it into configuration that is tested, packaged, versioned, signed, and promoted through environments as controlled artifacts.
(Ab)using the Kubernetes API as a Configuration Backend
Configuration-heavy products often reinvent the same backend machinery: typed objects, validation, permissions, audit trails, and some form of realtime change propagation. Over time, that configuration backend starts to look a lot like a control plane.
This talk explores the Kubernetes API as a backend for configuration-heavy software products rather than as an infrastructure surface, including what the approach enables, which trade-offs it introduces, and where the model starts to break down.
Past
Be BFFs with the Kubernetes API
Kubernetes is famous for running containers, but its API model is the interesting part: flexible resources, desired state, live updates through watches, validation, and advanced access control. Platform engineers use these ideas every day. Frontenders usually only get the boring REST endpoint at the end. Isn't that a missed opportunity?
The talk runs an open-source coffee-ordering demo where the whole audience gets admin rights and configures it from their phones, showing how live updates are not only cool but genuinely useful for handling conflicts. This is not a talk about exposing production infrastructure to the public internet. It is about running a small, dedicated Kubernetes API server as a product backend — and asking whether Kubernetes could become your Backend for Frontend.
GitOps Needs an API
GitOps works well — well enough that high-level business intent ends up in Git too: customer tenants, feature rollouts, access policies. The hard part is not storing it there. The hard part is expecting business stakeholders or customers to manage that intent through pull requests and raw YAML.
Reverse GitOps is an API-first pattern for exactly this problem: a typed Kubernetes API in front of the repo accepts structured intent through CRDs, without giving callers direct access to Git, and a controller turns that intent into YAML files and commits them. From there the GitOps workflow you already trust stays intact — review, policy checks, CI, and a full audit trail. The talk closed with a live demo of the open-source gitops-reverser operator and an honest checklist of where the pattern fits and where it does not.
What If Every Cozystack Change Became a Commit?
Cozystack exposes platform services as Kubernetes API resources — Postgres, Redis, Bucket, Kubernetes. Users interact in the usual ways: kubectl, the Cozystack dashboard, or AI agents via MCP. But who is making all these changes, and why did they do it? Git seems far away. But it doesn't have to be.
What if every platform change automatically appeared as clean YAML in Git? Fully automated — a silent layer that turns API activity into a durable, readable history of infrastructure intent. Instead of digging through logs or dashboards, teams get versioned history they can inspect, diff, and share. The platform continuously writes its intent back to Git. Git stops being the interface — and starts being the memory.
The GitOps Paradox: Why Your Devs Need an API You Don't Want To Build
This session argues that GitOps is valuable, but Git does not always need to be the human-facing front door for every change. Platform teams often end up rebuilding APIs and UIs around workflows that the Kubernetes API already models well. Reverse GitOps explores a different approach: use a small, typed Kubernetes control plane for user intent, then write that intent back into Git so review, promotion, and auditability stay intact.
The talk includes two live demos: a simple application writing user intent into the Kubernetes API and syncing it back to Git; and a higher-level platform resource flowing from API input to Git to preview and production deployment.