The Problem with Shared Staging

▶ Watch (1:22)

Shared staging environments carry high maintenance cost and frequent downtime. Pipelines diverge across teams with no standard tooling. Review cycles stretch because feedback arrives late. App teams want self-service. Platform teams need governance and centralized control. AI-assisted coding adds a new wrinkle: it generates code faster than any shared environment can validate it. The answer Bianchi and Prodan present is a declarative, GitOps-native preview environment owned by platform teams but triggered by developers applying a single label on a GitHub pull request.

Three Repos, One Label

▶ Watch (2:52)

The setup uses three repositories in an open source organization. A platform repo holds the Flux operator config, cluster bootstrap, and all infrastructure resources. An app repo (called App X) is the only place developers work. They have no access to secrets or environment config. A Helm charts repo, also owned by the platform team, supplies the generic chart. CI builds and pushes a container image. Flux operator does the rest. CI never touches the cluster and does not know a cluster exists.

How Flux Operator Wires a PR to a Helm Release

▶ Watch (8:52)

A resource set input provider tells Flux which repo to scan, which label to watch (here, deploy-flux-preview), and how many concurrent environments to allow. The default cap is 100 preview environments per app repo. When the label appears, Flux resolves the head commit SHA, images the PR number into a tag formatted as PR-{id}-{short-sha}, and creates a Helm release named after the PR number. Pull request 9 gets a release called app-9. Each new commit upgrades that same release in place. Flux then posts a comment back to the PR confirming deployment and can also write to the GitHub Deployments API, adding a green check directly on the commit.

Catching Failures the CI Build Missed

▶ Watch (17:55)

A second PR intentionally introduced a typo in the Dockerfile. The Docker build succeeded, so CI showed green. The pods crashed on startup inside Kubernetes. Helm controller waited its default five-minute timeout, then marked the release failed. Flux posted the failure back to the PR. The developer saw the broken state without ever touching kubectl. This is the core value of the pattern: CI cannot surface what only happens once an application runs in Kubernetes, receives traffic, and connects to other services.

Flux MCP Server and AI-Assisted Debugging

▶ Watch (21:33)

With the Flux MCP server installed, Copilot connected to the local kind cluster and identified that PR 10’s Helm release was in a crash loop because ingress-nginx was missing. It traced the failure to the Dockerfile entrypoint typo. The MCP server exposes tools to read, modify, and delete Kubernetes resources, so Prodan recommends running it with the --read-only flag until teams are comfortable. That flag restricts the agent to suggesting fixes only. RBAC in the cluster provides a second layer of control regardless of which AI tool connects.

Q&A

Can Copilot commit a fix directly from the MCP session? Technically yes via the GitHub MCP in the Copilot CLI, but the speakers recommend read-only mode until you trust what the agent will do. ▶ 23:42

Notable Quotes

no matter how much testing you are embedding here in CI, it will never cover uh you know what actually happens with the application once it runs in Kubernetes. Stefan Prodan · ▶ 06:58

by by default we have u uh 100 we we’ll create a maximum of 100 preview environments for a particular uh app repo. So now depending on how much money you want to spend on previews you have some control here. Matteo Bianchi · ▶ 09:49

if you are adopting this technology, my recommendation is don’t do yolo mode everywhere like yeah maybe keep it only unless you until you get more comfortable with what it can do. Stefan Prodan · ▶ 26:58

save tokens. Read the docs. They’re expensive, Matteo Bianchi · ▶ 28:39

Key Takeaways

  • Flux operator creates one Helm release per labeled PR and destroys it on close or merge.
  • A cap of 100 concurrent preview environments per repo keeps cloud spend bounded.
  • The Flux MCP server surfaces cluster failures to AI agents without giving developers direct cluster access.
  • Run the MCP server with --read-only until you have verified what the agent will change.
  • CI green does not mean Kubernetes green; preview environments catch the gap.

About the Speakers

Matteo Bianchi is a Solutions Engineer at GitHub, CNCF Ambassador, former startup CTO, and semi-retired DevRel. He has contributed to Kubernetes upstream and served on the Kubernetes Release Team from v1.31 through v1.34, with active Release Engineering work from v1.33. He also sings in a metal band.

Stefan Prodan is a Principal Engineer at ControlPlane with over 20 years in software engineering. He created Flagger, the progressive delivery operator for Kubernetes, and is a core maintainer of the CNCF Flux project. He also built the Flux operator and the Flux UI.