Skip to main content


A Kratix Promise can be configured with a series of workflows for both Promises and Resources, defined within the Promise workflows field.

Within the workflows, Promise writers can define a series of actions that will be executed when certain conditions are met in the system.


The supported workflows are summarised in the table below. See the other sections on this page for details.

Trigger(s)Supported Pipelines
Promise ConfigureThe Promise is created, updated, or reconciledMultiple, executed serially
Promise DeleteThe Promise is deletedSingle
Resource ConfigureThe Resource is created, updated or reconciled, or the parent Promise is updatedMultiple, executed serially
Resource DeleteThe Resource is deletedSingle

An example of how workflows are defined within the Promise is shown below.

kind: Promise
- # Pipeline definitions (multiple)
- # Pipeline definition (single)
- # Pipeline definitions (multiple)
- # Pipeline definition (single)

A particular workflow (e.g. resource.configure) is an array of Kratix Pipeline objects that will be executed in order.

See the next section to learn how to define a Pipeline.


A Kratix Pipeline kind is a simple wrapper around a Kubernetes Pod.

Pipelines will automatically mount the necessary Kratix Volumes and set Environment Variables for the provided containers.

An example Pipeline is shown below.

kind: Pipeline
name: # Name (must be unique within the Promise)
namespace: # Namespace (optional)
- # Volume definitions, in addition to `/kratix` volumes (optional)
- name: # Container name (must be unique within the Pipeline)
image: # Container image to run
# Supported fields passed through to underlying Pod spec (all optional):
command: []
args: []
env: []
envFrom: []
volumeMounts: []
imagePullPolicy: # Either Always, IfNotPresent or Never
imagePullSecrets: []

Refer to the Kubernetes Pod Spec documentation for more information on the fields above.


Not all fields from the Pod spec are supported. We will add support for more fields in the future.


To access Secrets in the Pipeline, you can pass in a reference to the Pipeline container's env using valueFrom.secretKeyRef in the standard Kubernetes way.


The Secret must be accessible within the Pipeline's namespace.

Refer to the Kubernetes documentation for more details on Secrets in Kubernetes.


Kratix will run each container in the spec.containers list in order, providing a set of common volumes, as defined below.


Kratix provides an input directory to the container, mounted at /kratix/input. This directory is populated with different files depending on the type of workflow.


In all workflows, all Pipeline containers will have access to an object.yaml file within the /kratix/input directory.

The contents of this file vary as follows:

  • Promise workflows: The object.yaml file contains the full Promise definition.
  • Resource workflows: The object.yaml file contains the Resource Request definition which was submitted to the Kratix platform.

This is a useful way to find out information about the Kubernetes Object the Pipeline is being invoked for. For example, you could read the latest status from this input Object and modify the behaviour of the Pipeline accordingly.

If your workflow contains multiple Pipelines, then the object.yaml is the only way to communicate between the Pipelines (e.g. via status updates).


At the end of a Pipeline, all files present in the output directory mounted at /kratix/output will be written to the State Store.

All containers in the Pipeline can write to this volume, and any container can add, update, or remove documents from this directory.


Files written to /kratix/output in delete Pipelines will be ignored.


All containers in a configure Pipeline have access a shared metadata directory mounted at /kratix/metadata.

Pipeline containers can control aspects of how Kratix behaves by creating special files in this directory:

  • destination-selectors.yaml can be added to any Promise to further refine where the resources in /kratix/output will be scheduled.
  • status.yaml allows the Pipeline to communicate information about the resource back to the requester. See the status documentation for more information.

Passing data between containers

Kratix scans for these files and ignores all other files in the /kratix/metadata directory. If you need to pass additional information to the next container in the Pipeline, you can safely write to the /kratix/metadata directory.

Environment Variables

Kratix will set the following environment variables for all containers in the workflow:

KRATIX_WORKFLOW_ACTIONThe action that triggered the workflow. Either configure or delete.
KRATIX_WORKFLOW_TYPEThe type of workflow. Either resource or promise.
KRATIX_PROMISE_NAMEThe name of the Promise.

By checking the KRATIX_WORKFLOW_ACTION and KRATIX_WORKFLOW_TYPE environment variables, a container is able to discover the context in which it's being invoked (e.g. "I'm running as part of a Promise Configure workflow").

This means that you could write a single container image to be used in all four workflows (promise.configure, promise.delete, resource.configure, and resource.delete), and switch the container's mode of operation based on the context.