Spike: Stratos running on CF for Kubernetes (kind-deployment / cf-k8s-releases)

Why this is open

#5907 leaves the Kubernetes question at retire-or-rebuild, and the case for retiring is strong on its own terms. The chart needs six images under names nothing builds, the component images derive from splatform bases six years stale, and no Helm issue has been filed against Stratos since 2020.

The counterweight is cloudfoundry/cf-k8s-releases. It is the reason the Stratos Kubernetes work has not been retired, and the purpose of this issue is to establish whether that reason holds.

What cf-k8s-releases is

It packages the common components of Cloud Foundry to run on Kubernetes — Helm charts plus Dockerfiles, charts published to ghcr.io/cloudfoundry/helm and images to ghcr.io/cloudfoundry/k8s. It is consumed by kind-deployment, with the Kubernetes-specific pieces in k8s-garden-client and k8s-policy-agent.

This is the real CF components on Kubernetes, not a reimplementation of the API — distinct from Korifi. The commit log is largely automated bumps tracking diego-release, credhub-release, loggregator-agent-release, log-cache-release and bosh-dns-release.

All eight core components already carry a chart: capi, uaa, routing, diego, credhub, loggregator, log-cache, cf-networking. They are real charts, not sketches — capi/helm has Chart.yaml, values.yaml, values.schema.json, templates/ and files/.

The observation that matters for Stratos

The component list is capi, uaa, routing, diego, credhub, loggregator, log-cache, cf-networking, nfs-volume, bosh-dns, cflinuxfs4/5, and the buildpacks.

There is no console, dashboard or web UI anywhere in it.

So if this effort goes anywhere, it assembles a Cloud Foundry on Kubernetes with a full control plane and no user-facing UI — which is the gap Stratos exists to fill. That is a reason for a Stratos chart to exist that did not apply when the current one bit-rotted, and it is a different question from whether today's broken chart is worth repairing.

What gives pause

The repository was created 2026-06-02 and was pushed to as recently as 2026-09-11, so it is active. But it carries no Git tags, no LICENSE file, and one star, and the CONTRIBUTING.md its README links to does not exist. That is consistent with early work that has not yet decided what it is.

Committing Stratos effort to it on the strength of three months of history would be premature. Equally, retiring the Kubernetes work while it is actively moving would be a decision we could not easily walk back.

Open questions

1. What is this, organisationally? A working group deliverable with a roadmap, or an experiment? Is there a commitment to it becoming a supported way to run CF?
2. Is a console considered in scope by the people building it, expected to come from elsewhere, or simply not thought about yet? This is the question that most directly decides #5907, and it is answerable by asking them.
3. Is kind-deployment the whole consumption story, or is a production path intended? A dev/test-only target changes what a Stratos chart would be for.
4. If Stratos rebuilt its chart, should it follow the house pattern — per-component folder, docker-bake.hcl, chart to ghcr.io/cloudfoundry/helm, image to ghcr.io/cloudfoundry/k8s? And would the chart live in this repo or stay in ours?
5. Does their image pattern make #5907's six-image problem cheaper? Their images build from current sources with automated dependency bumps, which is precisely what the splatform bases fail to do. A template we could copy changes the cost of "rebuild" considerably.
6. How does this relate to Korifi, and which does Stratos target? There is existing Korifi work on our side. Two CF-on-Kubernetes futures with one Stratos is worth being deliberate about.

What would settle it

Question 2, asked directly of the cf-k8s-releases maintainers or the relevant working group. If a console is wanted, the Kubernetes work has a purpose and #5907 resolves toward rebuild against a pattern that already exists. If it is not, or if nobody has decided, #5907 resolves toward retire and this closes with the answer recorded.

Related: #5907, and #5917 on distribution formats more broadly.

Start with the cf-k8s-releases README and the capi/helm chart, then inspect how kind-deployment consumes the component charts. Ask the maintainers whether a console is in scope and record the answer, along with the supported production or development target, to determine whether #5907 should be rebuilt or retired.