2 posts tagged with "gitops"

We love GitOps.

Kratix, a framework for building platforms on top of Kubernetes, has GitOps at its core, and it's a fundamental part of our recommended platform architecture. It’s what allows Kratix to schedule workloads to any type of Destination, what enables Compound Promises, and a central piece of the declare-and-converge philosophy we follow.

But what happens when hundreds of commits are pushed in a short period? Or when customers want to know "who did that?", but the answer is buried under thousands of automated commits? Or even when you can't commit to the repository at all?

In this blog, we will cover how our health checks turned a GitOps repository into a commit firehose, why switching to buckets was not enough, and how the new Health Source in SKE puts the Platform back in control.

Application repositories contain much more than application code. Platform teams often need to manage agent instructions, linter configuration, CI workflows, security policies, dependency rules, or service catalogue metadata.

Making the first commit is the easy part. The real challenge comes later, when the organisation changes its standards. Someone then needs to find every repository, update the right files, correct manual drift, and remove files that are no longer required.

A Kratix Promise can own that complete lifecycle. The user identifies their Git repository and describes what they need. The Promise generates the desired files, and Kratix schedules them to that repository. When the platform team updates the Promise, Kratix rolls the change out to the repositories it manages. It also corrects drift and removes the managed files when their Resource requests are deleted.

The files become managed platform resources, not the forgotten output of a one-off scaffolding task.