Composable Fulfillment: Teaching a Developer Portal What Your Platform Actually Did

A service can declare what it needs like an API dependency, a datastore, a cache independent of where or how it's deployed. But showing those declared requirements on a developer portal's component page is only half the story platform teams also need to show what was actually fulfilled, by what, and by whom.

This talk walks through building that second half for an open-source Backstage plugin, end to end correlating a Kubernetes custom resource (delivered via a Kratix Promise) to a catalog entity by git-URL identity rather than fragile labels, designing a fulfillment API from a single terse GitHub comment into a working spec. A real platform composes independent automation (a Kratix Promise for network policy, a separate one for certificates, another for secrets), and naively modeling one fulfillment = one adapter breaks the moment two of them report against the same requirement concurrently.

We'll cover the data-modeling decisions (resources as arrays, automation scoped per-resource, environment counts that don't double-count concurrent adapters), the Backstage-specific plumbing (the Kubernetes plugin's proxy API, linking fulfillment resources back into the Kubernetes tab, the new backend system's default-deny auth policy), and a live demo built and tested against a real kind cluster

1. Identity over labels: why correlating a declared requirement to a component by its git source location survives multi-cluster deployment in a way Kubernetes label matching doesn't.
2. A real spec grows from one comment: how a maintainer's single detailed GitHub comment became a POST/GET API, and how that API's shape had to change again once a one-adapter assumption broke.
3. Composable platforms need composable data models: why resources: [] and per-resource automation (not one automation field per fulfillment) is what actually lets independent Kratix Promises, Crossplane compositions, or Sveltos profiles report concurrently without clobbering each other.
4. Backstage internals worth knowing: the Kubernetes plugin's proxy is an unrestricted pass-through gated by RBAC, not a fixed allowlist; the new backend system denies unauthenticated requests by default; detailPanel on Table is the lightweight way to model one-to-many data without a new page.
5. Testing locally means more than it sounds like: what "spin up a kind cluster" actually required (RBAC gaps, a missing CRD, Node/node-gyp version mismatches, a stale fixture pointing at a dead temp path).