Turn Helm Charts into Scalable Platform APIs with Kratix

Abby Bangser
Sep 5
4 min read

Updated: 2 days ago

Helm is one of the most widely used tools in the Kubernetes ecosystem. It’s often the first step in managing shared tooling within an organisation. Helm charts provide a common way to package applications, services, and even infrastructure, thanks to projects like Crossplane, Google Config Connector, and AWS Controllers for Kubernetes (ACK). As a result, many teams have already invested heavily in complex and battle-hardened Helm charts.

But Helm has its limits, especially when it comes to building internal platforms that scale across business requirements, teams, and technologies.

At Syntasso, we believe platform engineering is about more than just templating YAML. It’s about delivering APIs that developers can rely on, while allowing platform teams to manage and evolve those APIs without causing friction. That’s why we built Kratix.

In this blog, I’ll walk through how Kratix lets you take your existing Helm charts and turn them into powerful platform APIs with a single kratix-cli command.

Helm Isn’t Enough on Its Own: You Need APIs

Helm charts define inputs and outputs clearly, but they don’t act as APIs. A values file may serve as a sort of contract, but it’s not something teams can query, extend, or plug into a wider system without managing a complex web of dependencies. Updating a chart typically involves coordinating with developers, managing dependencies across multiple repositories, and ensuring that no changes disrupt production.

What’s more, Helm only templates YAML. It doesn’t include any of the business processes most organisations need, such as manual approvals, security scans, or cost controls. These must live in an outside system and often fall to CI/CD pipelines or other tooling that are not meant for this type of work, which adds complexity and increases the risk of setup and maintenance errors.

In short, Helm can’t easily scale to support enterprise needs.

From Templating to APIs with Kratix

That’s where Kratix comes in. With a single CLI command, you can take any public or private Helm chart from any version and turn it into a Kratix Promise.

What does that mean?

A Promise wraps your Helm chart and creates a Kubernetes Custom Resource Definition (CRD). This resource provides an actual API: a reusable, governed, and self-service entry point into your internal developer platform. This API enables users to make HTTP requests (via the Kubernetes API) as well as declarative YAML specifications, which can be applied using GitOps tools.

Once your Helm chart is wrapped as a Promise:

It appears as a catalogue item in your internal platform
It’s exposed only after any provided setup is complete confirmed complete
It supports updates to the platform implementation without breaking user contracts
It enables users to manage the creation, update, and deletion of their resources without help
It stores the rendered manifests in Git for full GitOps integration

Instead of just templating code, you define and expose platform services that teams can consume through a consistent API.

Seamless Integration with Developer Portals

If you’re using Backstage or another internal developer portal, Kratix Enterprise makes integration seamless. Any Promise you create becomes a component in Backstage automatically. This means that operations engineers with expertise in infrastructure no longer need to design and implement user experience improvements through JavaScript or TypeScript code.

Portal templates are automatically generated, allowing developers to request services (such as a PostgreSQL database) through the portal UI. Behind the scenes, Kratix runs the business logic needed to fulfil that request.

This can include:

Compliance workflows (e.g. checking if a service meets company policies)
Cost controls (e.g. tracking resource use or requiring approval for high-cost options)
Manual approvals (e.g. getting sign-off from security or legal)

From the developer’s point of view, it’s a simple request. From the platform team’s view, it’s a secure, governed, and automated process. And from the organisation's point of view, they can introduce additional interfaces with ease and without significantly increasing maintenance costs. Organisations often depend on a range of portals, ticketing systems, CLI tools, chatbots, and more.

This is Platform Engineering, Not Platform Plug-in Juggling

The big win here is that Kratix doesn’t just expose your chart through a new interface. It creates a platform-native API that leverages your organisation’s workflows.

Platform teams stay in control and can update, improve, or patch the underlying implementation without breaking the contract with users. At the same time, developers receive a consistent and simple experience that feels like any other API request.

And because the Promise can include Git storage for the rendered manifests, your existing deployment workflows continue to work exactly as before, whether that be through Helm install commands or GitOps deployments. No need to start from scratch.

Wrapping Up: APIs, APIs, APIs…

Helm is still a valuable tool. But to build scalable, flexible, and secure internal developer platforms, you need more than templating. You need APIs.

Kratix helps you:

Turn Helm charts into platform APIs
Manage updates, security, and compliance centrally
Enable self-service without giving up control
Use your existing infrastructure as code investments more effectively

If you’re already using Helm, Kratix is the next step in your platform journey. You don’t need to throw anything away; you just need to wrap what you have and grow from there.

Watch the full demo