Kratix: building internal platforms from promises in Kubernetes

A platform framework organised around a promise

Kratix is an open source platform framework written in Go and created by Syntasso. Its own project description calls it a framework that combines the flexibility of building a platform from scratch with the on-demand and self-service power of public clouds, and that combination is the whole pitch: a platform team gets to shape its own workflows without giving up request-driven access for developers.

The name is the design brief. The project keeps the Greek phrase κρατήστε μια υπόσχεση with the English gloss Keep a promise, and the repository topics list both product and promise alongside framework, kubernetes and platform. Reading a framework like this is therefore a question of trust: does the machinery deliver what the interface promised? The repository topics also list product, which hints that a promise here is something a product team declares rather than something a user writes.

Ownership and licence are straightforward. The project is hosted under the syntasso organisation, the licence is Apache-2.0, and the licence file sits at the top of the tree as LICENCE. The community channels are a Slack workspace, a [email protected] address, and a community page under kratix.io. The homepage is kratix.io and the documentation lives at docs.kratix.io, with the quick start there being the only onboarding route the README gives.

Custom resources, controllers and a cluster api dependency

The go.mod file is the clearest window into how the framework works, because it names the Kubernetes machinery the code leans on. The module is github.com/syntasso/kratix, it targets Go 1.26.0, and it depends on k8s.io/api, k8s.io/apimachinery and k8s.io/apiextensions-apiserver at v0.36.2. The apiextensions dependency is the tell: custom resource definitions are part of the product surface, not an implementation detail.

The controller layer is sigs.k8s.io/controller-runtime v0.24.1, which is the standard reconciliation library for Kubernetes controllers, and it is paired with sigs.k8s.io/cluster-api v1.7.2, which points at machine lifecycle management as a supported concern. The Makefile keeps that compatibility promise explicit in a comment above the CRD_OPTIONS variable, which asks for CRDs that work back to Kubernetes 1.11 with no version conversion.

The directory layout matches the story. There is api/ for the resource types, cmd/ for the entry point, internal/ and lib/ for implementation, util/ for shared helpers, work-creator/ for the pipeline adapter, charts/ for Helm packaging, config/ for deployment manifests, and a separate sdk/ directory that suggests the framework exposes a surface for writing platform behaviour rather than only for hosting it. A samples/ tree holds an easy-app sample and a paved-path-demo sample, which is a hint about the intended usage pattern: a paved road demonstrated end to end rather than a library of fragments.

One image, two binaries and tini as PID 1

The Dockerfile shows the packaging choice clearly, and it is a choice worth arguing about. A multi-stage build compiles two Go programs from cmd/main.go and work-creator/*.go, then copies both into a single runtime image based on alpine/git:

FROM --platform=$BUILDPLATFORM golang:1.27 AS builder
RUN --mount=target=. \
    --mount=type=cache,target=/root/.cache/go-build \
    --mount=type=cache,target=/go/pkg/mod \
    go build -o /out/manager cmd/main.go

The runtime stage exists for a specific reason, stated in the file itself: the git binary is needed by the Kratix Git Writer, and the image also supplies /usr/bin/env and /bin/sh for the pipeline adapter. The image installs tini and makes it PID 1 with the entrypoint /sbin/tini, --, /manager, and the comment above that line explains the reason: orphaned git remote-https helpers left behind by every git fetch and git push would otherwise pile up as zombies until the container hits its PID limit, which the comment attributes to kratix issue #892.

Two more details matter operationally. The image runs as UID and GID 65532, a non root appuser, with HOME set to /home/appuser and an .ssh directory created and chowned to that user. SSH key access for git operations is therefore expected, and the container is deliberately not root.

The image is the deliverable and the Makefile is the only build path

There is no install command to copy. The project points new users at the quick start documentation and publishes container images, so the practical first step is pulling the published image rather than compiling from source. The Makefile is where the image coordinates live, and they are the variables you would override in a fork or a release pipeline:

VERSION ?= dev
IMG_NAME ?= docker.io/syntasso/kratix-platform
QUICKSTART_TAG ?= docker.io/syntasso/kratix-platform-quickstart:latest
IMG_VERSION ?= ${VERSION}

The default VERSION of dev is worth pausing on. A developer build is not a released artifact, and the Makefile also defines IMG_MIRROR as syntassodev/kratix-platform:${VERSION}, so there are two registries in play, one for the main image and one for development mirrors. A separate WRB_VERSION variable defaults to 0.0.0 and covers the worker-resource-builder binary, which suggests a second release artifact that is versioned independently of the platform image.

Other defaults show the testing stance. RECREATE defaults to true and is passed to the kind cluster targets, and the Makefile only passes the --recreate flag when that value is true, so local cluster runs are destroyed and rebuilt by default. The build runs under bash with -o pipefail and -e, which means a failed step in a piped command stops the build rather than hiding behind a pipeline exit code.

Git operations inside the platform pod shape the runtime image

The dependency list explains why the runtime image is unusual for a controller. github.com/google/go-github v69 and github.com/bradleyfalzon/ghinstallation/v2 sit in the direct requirements, which are the libraries used to talk to GitHub and to authenticate as a GitHub App installation rather than as a personal token. golang.org/x/crypto v0.57.0 is a direct dependency too, alongside the SSH key handling implied by the .ssh directory in the image.

The effect is that a Kratix installation performs git operations itself, and the Git Writer named in the Dockerfile is the component doing it. The tini comment names the operations directly: git fetch and git push. A pipeline that fetches and pushes inside a Kubernetes pod inherits the whole cost of git as a runtime dependency. It needs credentials, it needs a git binary in the image, it needs a process supervisor to reap the helper processes those commands spawn, and it needs a base image that is not distroless and not minimal. That is a deliberate trade of image size and attack surface for a self-service workflow that is genuinely git shaped.

The object storage dependency follows the same logic in a different direction. github.com/minio/minio-go/v7 v7.2.1 is a direct requirement, which points at pipeline steps that read or write artefacts through an S3 compatible API rather than only through a container registry. The pipeline-adapter binary is what a platform author invokes to run a step, so the two binaries in the image split into the long running manager and the short lived executor.

Telemetry and test doubles are part of the shipped surface

The remaining direct dependencies describe how the project expects to be operated and developed. The OpenTelemetry packages are extensive and specific: otelhttp instrumentation for the net/http server, the otel SDK for traces and metrics, and separate exporters for OTLP traces over gRPC, OTLP metrics over gRPC, and OTLP traces over HTTP, at versions 1.45.0 for the core packages and 1.43.0 for the gRPC metric exporter. Choosing both a gRPC and an HTTP trace exporter means the framework can send telemetry to collectors that speak either protocol, which matters when the receiving stack is not yours.

On the testing side, github.com/onsi/ginkgo/v2 v2.28.1 and github.com/onsi/gomega v1.39.1 are the behaviour testing pair, and github.com/maxbrunsfeld/counterfeiter/v6 v6.12.2 is a fake generator, which is how a project of this shape fakes the cloud and git APIs it calls. github.com/patrickmn/go-cache v2.1.0+incompatible and github.com/spf13/cobra v1.10.2 round out the picture: an in-process cache, and a command line interface built on cobra. The presence of a real CLI in the dependency list is the best evidence that operators are expected to run commands against a Kratix deployment, not only to watch it through Kubernetes resources.

For configuration, the project uses gopkg.in/yaml.v2 and sigs.k8s.io/yaml, so YAML is the expected format for anything a platform author writes by hand.

Tags stop in 2024 while the branch keeps moving

Maintenance facts here are mixed, and both halves matter. The repository is not archived, and the last push was on 2026-10-19, with a release named latest dated the same day. That is a project receiving work, not a dormant archive.

The versioned tags tell a different story. The most recent numbered releases listed are v0.125.0 and v0.124.0, and both carry a 2024-07-08 timestamp, with the two releases hours apart on the same day. A numbered version series that stops in mid 2024 while the default branch continues to receive pushes suggests that releases are cut on a different cadence than development, and that a self-hosted operator pinning a numbered tag is pinning something considerably older than the moving branch. The version scheme is also pre 1.0, so the API surface carries no stability promise of the kind a 1.x tag implies.

Documentation is the other soft spot. The project README is short: it names the quick start, links the docs site, points at Syntasso for case studies, and lists the community channels. It does not document a rollback procedure, an upgrade path between numbered versions, or a version compatibility matrix, and the samples/ tree contains an easy-app sample, a paved-path-demo sample and a sample README without the walkthrough detail that would let an operator copy a working configuration. None of that makes the framework unusable, but it means a team evaluating it is signing up for reading the external documentation rather than for reading the repository.

Editorial conclusion

Adopt Kratix if your team already runs Kubernetes and wants a paved road with self-service requests rather than a bespoke operator; the Go codebase, the CRD pipeline and the git aware adapter are a credible foundation for that. Do not adopt it if you need a versioned upgrade contract, because the newest numbered tags v0.125.0 and v0.124.0 both carry a 2024-07-08 date while the last push was on 2026-10-19. Before committing, walk the quick start at docs.kratix.io on a scratch cluster and pin the exact image tag in your own values file rather than tracking a moving latest tag.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. syntasso/kratix on GitHub