XRDs & self-service claims

Publish a platform API developers claim.

A Composite Resource Definition (XRD) defines the API for your composite — its name, its fields, and their schema and validation. Publishing an XRD does two things: it creates the composite type (the XR the platform team manages), and optionally a claim type — a namespaced, simplified resource that developers create in their own namespace. The claim is the self-service front door; the XR and composition are the machinery behind it.

apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata: { name: xpostgresinstances.acme.io }
spec:
  group: acme.io
  names: { kind: XPostgresInstance, plural: xpostgresinstances }
  claimNames: { kind: PostgresInstance, plural: postgresinstances }   # dev-facing
  versions:
    - name: v1alpha1
      served: true
      schema:
        openAPIV3Schema:
          properties:
            spec:
              properties:
                size: { type: string, enum: [small, large] }   # the only knob devs get

Self-service, safely

Now a developer provisions a production-grade database with a tiny, validated manifest — they pick size, and the composition supplies the encrypted, backed-up, correctly-networked reality. The platform team controls what fields exist (the XRD schema) and how they are fulfilled (the composition), so self-service does not mean a free-for-all: developers can only ask for what the API allows, and it is always built your way.

# what a developer writes, in their own namespace
apiVersion: acme.io/v1alpha1
kind: PostgresInstance
metadata: { name: orders-db, namespace: team-orders }
spec:
  size: small
  writeConnectionSecretToRef: { name: orders-db-conn }