top of page
Search

Turn Pulumi Components into Platform APIs with `kratix init`

Pulumi components are great for reuse, but they don’t give you a platform your developers can safely consume. Most platform teams eventually run into the same issue: handing raw infrastructure abstractions to application teams doesn’t create a clean, self-service experience.

What’s missing is a platform API.


Instead of exposing Pulumi packages directly, platform teams need a way to turn those components into well-defined, self-service capabilities, complete with workflow, governance, and a consistent developer experience.


With the new preview pulumi-component-promise command in the Kratix CLI, you can do exactly that. Starting from an existing Pulumi component schema, you can bootstrap a Kratix Promise and instantly generate a platform API backed by your existing infrastructure code.


The Problem: Contract ≠ API

Pulumi components are a powerful abstraction. They allow platform teams to encapsulate infrastructure patterns from provisioning databases or message queues up to entire application stacks. And Pulumi's superpower is doing all of this using general-purpose programming languages with excellent test harness and runners.


However, when used alone, Pulumi Components have several limitations:


  • No straightforward way to embed approval steps, policy, or supporting automation

  • No clean separation between platform intent and underlying infrastructure tooling

  • Limited continuous governance and drift detection

  • No way to refactor the implementation without affecting the user experience


Slide from a talk introducing how designing and implementing APIs are the key unlock for platform success.
Slide from a talk introducing how designing and implementing APIs are the key unlock for platform success.

This is the same pattern we see at Syntasso with customers using Terraform modules and Helm charts. Reusable infrastructure artefacts are useful, but they are not the same thing as a platform product. Kratix Promises can extend these solutions to enable your platform APIs without rewriting your infrastructure.


Bootstrapping a Promise from a Pulumi schema


The new Kratix CLI “kratix init” command is designed to make the transition from infrastructure as code to platform API seamless, and Pulumi is now available as a solution alongside other popular tools such as Helm, Crossplane, Terraform, and Kubernetes Operators.


The new command takes a Pulumi package schema, selects your chosen component, translates its inputs into a Promise API, and scaffolds the Promise files. In a nutshell, the Kratix CLI command:


  • Wraps your Pulumi component in a Kratix-compatible interface

  • Generates the required directory structure

  • Creates example Promise definitions

  • Sets up input/output handling between Kratix and Pulumi


That means you do not start from a blank directory and a wall of YAML. You start from a working baseline that reflects the Pulumi component you already have, enabling you to focus on your additional business process logic and user-facing API rather than the glue code.


If you’ve used the Kratix CLI for Terraform modules or Helm charts, this workflow will feel familiar.

Just like:



This new command extends the same pattern to Pulumi, and this consistency is intentional. Regardless of the underlying technology, platform teams get a unified way to build APIs.


What the generated Promise actually does


This new command is more than just an API definition; it also transforms a component into the new Pulumi Kubernetes Operator (PKO) format and schedules the workloads to the correct cluster locations without any heavy lifting from the platform teams, allowing users to implement the power of PKO with little refactoring costs.


The provided open source workflow images map a user's request to the selected component's properties and carry over deterministic metadata and naming to generate a valid `Program` resource and `Stack` resource. Each of these resources can then be improved and extended by the platform team as needed, but the baseline creation is done for you.


This matters because it moves Pulumi from being something your developers need to assemble and run themselves into something your platform can generate and manage consistently.


Why This Matters


The value here is not only speed, though it is much faster than hand-writing the first version of the Promise. The bigger win is consistency across your infrastructure as code tools and platform capability offerings.


Enabling a coherent platform experience unlocks a number of benefits:


  • Faster Platform Development: You can go from Pulumi component to platform APIs backed by PKO reconciliation in minutes, not days.

  • Consistent Developer Experience: Developers interact with all platform capabilities in the same way.

  • Reduced Cognitive Load: No need for developers to learn Pulumi or understand infrastructure details. Use the right tool for the job behind the scenes without impacting user experience.

  • Reuse Without Friction: Your existing Pulumi components decouple implementation from use, allowing easier updating and instantly providing more value to users as self-service APIs.


Getting started


Ok, that is enough theory, want to get hands on? Go install the Kratix CLI or make sure to upgrade your version to at least v0.14.2.


Identify a component you already use, or use a community-provided one, such as the AWS IAM component, and fetch the schema JSON document. Once you have this, you can run the command such as:


kratix init pulumi-component-promise iam-user \ --schema "https://www.pulumi.com/registry/packages/aws-iam/schema.json" \ --component "aws-iam:index:User" \ --group syntasso.io \ --kind User \ --dir pulumi-user


From here, you will have a new directory with a fully functional Promise generated.


A condensed view of the Promise output showing alignment with the original Pulumi Component contract and the supported workflow for generating PKO objects.
A condensed view of the Promise output showing alignment with the original Pulumi Component contract and the supported workflow for generating PKO objects.

By default, this Promise will work on a Kratix installation with at least one Destination that has the Pulumi Kubernetes Operator installed on it. If you are new to Kratix or are unsure whether your installation is compatible, please check out the getting started guide and reach out to support for any questions.


What’s Next?


The goal of an Internal Developer Platform is simple: give developers a consistent, self-service experience, regardless of the tools powering it behind the scenes.


At Syntasso, we focus on helping platform teams bridge the gap between the infrastructure they already have and the platform experience they want to deliver. That doesn’t mean replacing your existing tools. It means transforming them into platform APIs.


With Pulumi, you already have powerful, reusable infrastructure components. With Kratix, you can turn those components into consumable platform capabilities that are standardised, governed, and easy for developers to use.


This Pulumi integration is just the beginning. We’re excited to keep building with the Pulumi community and exploring how platform teams can get even more value from the tools they already use.

Try it out, experiment with your existing components, and let us know what you build.

Comments

bottom of page