Fleet Management for Your Internal Developer Platform: Self-Service + Governance with Kratix

Giving developers autonomy to provision infrastructure is now a table-stakes requirement for modern internal developer platforms (IDPs). But self-service on its own isn’t enough. Platform teams also need a way to manage the lifecycle of those services after they’re provisioned, especially when something goes wrong.

What happens when a critical vulnerability is found in a shared service such as a database? How do you coordinate patches across dozens or hundreds of developer-owned instances? And how do you do that without grinding everything to a halt?

This is where Kratix steps in. It enables you to build internal platforms where developers can self-serve, while providing platform engineers with powerful tools to manage services across the fleet.

From “Request Once” to “Manage Forever”

In many internal platforms, self-service ends at provisioning. Developers request a resource, such as a database, and it gets deployed. After that, any “day 2” operational responsibility often shifts entirely to the team that made the request.

That approach works until the platform team needs to make changes to the service itself. For example, a zero-day CVE might be discovered in a shared database version. Or your organisation might mandate encryption-at-rest across all storage. Suddenly, teams need to upgrade, but you have no central way to identify where those changes need to be made, let alone execute them. You either wait for every developer to respond to ticket requests and direct messages, or patch things manually behind the scenes.

Kratix takes a different approach. Instead of just provisioning resources, it tracks the intent of each request through something called a Promise. Promises define what a service looks like, the parameters developers are allowed to set, and the workflows that should run when it’s requested or changed.

When you update the Promise, Kratix automatically re-applies the new definition to every matching request. In practice, that means the platform team can change how a service is delivered through patches, migrations, or reconfigurations, and Kratix will handle the updates across the fleet.

Watch: Manage your platform services as a fleet, not snowflakes

A Shared Contract Between Platform and Developer

A Kratix Promise is a contract. The platform team writes it to define how a service should be created and managed. Developers then use it to request infrastructure in a controlled and repeatable manner.

That contract can be exposed through Kubernetes APIs or via a user-friendly UI, such as Backstage. From the developer’s perspective, the experience is straightforward: they request a database instance by filling in a few fields, such as major version and region, and Kratix handles the rest. There is no need to touch Terraform, YAML, or cluster internals.

However, behind the scenes, Kratix initiates a custom workflow defined by the platform team. This might involve generating Kubernetes manifests, integrating with GitOps, applying policy checks, or deploying to specific clusters. The workflow encapsulates everything needed to bring the service to life.

And the best part: the same mechanism that provisions these services also handles updates.

Fleet-Wide Security and Operational Changes

Say your platform has hundreds of database instances, all of which are provisioned by different teams. A patch is released for a security vulnerability, and you need to upgrade them all.

Traditionally, this would be a headache. Even with infrastructure as code, coordinating updates across teams is error-prone and time-consuming. You might spend days chasing people to make a change they barely understand.

With Kratix, the platform team updates the MongoDB Promise to reflect the new patch version and defines the workflow for existing instances. Kratix then automatically re-runs that workflow for every affected request—without needing input from developers.

This isn’t just about security patches. You can use the same mechanism to migrate workloads, apply policy updates, or refactor how a service is delivered. The Promise acts as the single source of truth for the desired state of the platform.

Observability Without the Bottlenecks

This model also improves visibility. Because Kratix tracks every request and its current state, both platform teams and developers can see what’s running where and how it was requested.

When integrated with tools like Backstage, this visibility becomes actionable. Developers can view the status of their resources, while the platform team maintains a global view of what has been deployed, where it resides, and whether it’s compliant.

There’s no need for centralised gatekeeping or manual approval flows. Kratix enables the platform team to encode their policies directly into the workflow logic, allowing developers to move quickly within those boundaries.

Why It Works

Kratix combines two things that are often in tension: developer autonomy and operational control. By treating infrastructure requests as long-lived objects and reconciling them through declarative workflows, it provides both parties with what they need.

• Developers get simple, API-driven self-service

• Platform engineers get a consistent mechanism for enforcing policy and rolling out changes

• The organisation gains confidence that services can evolve without downtime or disruption

Self-service isn’t just about making things fast. It’s about making things safe, scalable, and sustainable. Kratix provides you with the tools to accomplish all three.