Many Platform Engineering teams maintain a set of abstractions which development teams use to deploy their applications - often in the shape of a Helm chart.
Even after the chart is mature, the Platform team needs to introduce bug fixes, security patches, the occasional improvement.
For an app team to onboard each of this changes, they need to read the changelog, decide if it's safe, bump a version, run a deploy.

In Banking Circle, we had around 200 applications across 25 teams. With an average of 8 chart releases a month and 30 min needed to onboard each release on any app, we were wasting hundreds of engineer-hours a month. Moreover, as you can imagine, not every update reached every app, so fleets quietly drifted out of date. It also left us non-compliant, because security wanted periodic redeploys nobody had time to run.

So we flipped ownership. This talk is about the Blueprint Update Orchestrator (BUO): a GitOps-native system that makes the Platform team own chart versions, and pushes non-breaking upgrades to hundreds of apps automatically, without ever touching a team's `values.yaml`, and without opening a PR.

BUO stages rollouts through test apps, dev, and regional prod with change-approval gates, and every change lands as a signed Git commit with a full audit trail. Only minor/patch versions auto-apply, breaking changes still go through an explicit migration path, and any team can opt out.

Pushing chart upgrades to production on a schedule sounds reckless. It turned out to be safer. By upgrading continuously instead of in rare big jumps, we surfaced bugs minutes after they were introduced.
We'll share the skepticism we hit, how we hardened testing before flipping the switch, and how reluctant developers came around once the system kept quietly working.