Kratix Ep 8: Developer Self-Service Workflow

1. Discovery: “What can I build?” (WHO & WHERE)

#

WHO: The E-Commerce Application Developer. WHERE: The Platform Cluster.

A new developer joins the E-Commerce team and is tasked with building a caching layer. They need a database. How do they know what databases the Platform Team currently supports and allows?

Because Kratix installs Promises as standard Kubernetes Custom Resource Definitions (CRDs), the discovery process is native to the standard kubectl CLI. The developer does not need to read a stale Confluence wiki page.

The developer runs a simple discovery command against the Platform Cluster:

kubectl get crds | grep kratix

Terminal Output:

NAME                                     CREATED AT
redis.marketplace.acmecorp.com           2026-08-01T10:00:00Z
postgres.marketplace.acmecorp.com        2026-08-01T10:00:00Z
kafka.marketplace.acmecorp.com           2026-08-01T10:00:00Z

The developer instantly sees the active “Marketplace” of available services.

Reading the Documentation (Schema)

#

To understand what parameters the redis API requires, the developer does not need to email the Ops team. They can ask Kubernetes to explain the schema to them:

kubectl explain redis.spec

Because the Platform Team wrote a strict openAPIV3Schema inside the Promise (which we did in Episode 4), Kubernetes will output beautiful documentation directly in the terminal, detailing the exact allowed size strings (small, medium, large) and the required environment variables.

2. Consumption: “Give me a Database” (HOW)

#

The developer now understands the API structure. They create a simple YAML file (the Claim/Resource Request) and commit it into their own application repository, right next to their application code.

# my-app-cache.yaml
apiVersion: marketplace.acmecorp.com/v1alpha1
kind: Redis
metadata:
  name: ecom-session-cache
  namespace: team-ecommerce
spec:
  size: large
  environment: production

They submit the request to the Platform Cluster:

kubectl apply -f my-app-cache.yaml

The Kubernetes API instantly accepts it. (Behind the scenes, Kratix boots the pipeline, Vault generates the password, Kratix pushes to Git, ArgoCD pulls the YAML, and the Worker Cluster physically provisions the Redis instance. The developer is completely oblivious to this complexity).

3. Feedback: “Is my Database ready?” (WHEN)

#

The developer doesn’t have access to the Worker cluster to check the status of the physical pods. They don’t have access to AWS to see if the ElastiCache instance is booting. How do they know when it is done?

Kratix pipelines are designed to write Status Updates back to the Developer’s Claim in the Platform Cluster.

The developer simply runs a standard describe command:

kubectl describe redis ecom-session-cache -n team-ecommerce

They look at the Status: block at the bottom of the terminal output:

Status:
  Conditions:
    - Message: Pipeline executed successfully. Pushed to State Destination.
      Reason: PipelineComplete
      Status: "True"
      Type: Ready
  # The Pipeline injected the connection strings here!
  Connection Details:
    Host: redis-ecom-session-cache.prod-us-east.svc.cluster.local
    Port: 6379
    SecretName: ecom-session-cache-redis-secret

The developer has absolutely everything they need to configure their E-Commerce application. They have the internal host address, the port, and the name of the Kubernetes Secret containing the Vault password. They achieved all of this without ever leaving their terminal, opening a Jira ticket, or talking to an Operations engineer.

4. Day 2 Operations: “I need to downsize” (HOW)

#

Six months later, the massive Black Friday sale is over, and the E-Commerce team wants to save infrastructure costs by shrinking the cache.

In a traditional IT model, they would open a Jira ticket, wait 3 days in a backlog, and an Ops engineer would manually run a Terraform script to resize the cluster, hoping it doesn’t cause downtime.

With Kratix Self-Service, the developer simply edits their original YAML file in their Git repository:

 spec:
-  size: large
+  size: medium
   environment: production

They run kubectl apply again (or let their own application CI/CD pipeline do it).

Kratix detects the update on the Redis object, re-runs the pipeline container, generates the new YAML with medium specs, pushes the new YAML to Git, and the database is resized automatically by the GitOps agent. Total time spent by the developer: 4 minutes. Total time spent by the Platform Team: 0 minutes.

Conclusion & Next Steps

#

This is the true power of a mature Internal Developer Platform. You have abstracted months of infrastructure engineering, complex GitOps synchronization, and stringent security policies into a 6-line YAML file for your developers. You have achieved true Developer Velocity.

However, throughout this series, we have been running kubectl apply from our laptops to install the Promises into the Platform Cluster. If a Platform Engineer updates the Redis Promise pipeline script (e.g., to support High Availability clustering), how do they safely test and deploy that update across the organization?

In Episode 9: Promise CI/CD with GitHub Actions, we will look at how Platform Teams manage their own code lifecycle, setting up CI/CD pipelines to build, test, and release Kratix Promises as software products.