Platforms as a product: KSail provisions and manages a complete opinionated platform without a hand-written GitOps config

> 🤖 Generated by the Agentic Engineer

## Direction

**Maintainer direction, interactive session 2026-09-04.** KSail should be able to **package and
deliver complete, opinionated platforms**, so adopters save years of assembly work. The approach must
be **configurable** — users select the stack they want and KSail provisions and manages it.
`devantler-tech/platform` is the **continuous reference target** for what a production-ready platform
configuration contains. Framed as *platforms as a product, managed by KSail*.

Clarified in the same session: this is **additive, not a replacement**. KSail does not stop being a
CLI and does not lose its other interfaces — desktop app, web UI, operator. As a hosted operator it
*additionally* becomes a platform that provisions platforms, while remaining all the other things.

Two shaping decisions were taken in that session:

1. **The stack is built into the code — an extensive GitOps config must not be a prerequisite.** This
is an enhancement of the existing feature set (the one where you already choose a policy engine,
CNI, CSI…), extended far enough that KSail can provision and manage a platform like the reference
one with the configuration built in and managed by KSail. **Non-negotiable counterpart:** users
must still be able to **extend or override every KSail-managed component and configuration via
GitOps**, so it is always possible to tune it further. Defaults are **opinionated toward best
practice**.
2. **Capability slots are the substrate, with granular presets on top** — so one selection brings up a
fully working platform quickly, while every slot stays individually configurable.

## Evidence — the gap is a known distance, not a guess

KSail already has the mechanism this epic grows. `spec.cluster` exposes **14 selectable capability
slots** today: `cni`, `csi`, `certManager`, `policyEngine`, `gitOpsEngine`, `imageVerification`,
`loadBalancer`, `oidc`, `sops`, `autoscaler`, `metricsServer`, `nodeAutoscaling`, `localRegistry`,
`cdi` — alongside `distribution`, `provider` and version pinning.

The reference platform runs roughly **30 components**, and the difference is almost entirely the
*production* layer that a cluster-level tool has never covered:

| Capability class | Present in the reference platform | Slot in KSail today |
|---|---|---|
| Secrets management | OpenBao, External Secrets, trust-manager | ❌ (only SOPS) |
| Observability | Coroot, OpenCost, tracing policies | ❌ |
| Backup / DR | Velero, Barman (Postgres) | ❌ |
| Progressive delivery | Flagger | ❌ |
| Identity / access proxy | Dex, oauth2-proxy, auth-proxy | ⚠️ `oidc` only |
| Runtime security | Kubescape, Tetragon | ⚠️ `policyEngine` only |
| Data services | CloudNativePG | ❌ |
| Event-driven autoscaling | KEDA | ⚠️ `autoscaler` is cluster-level |
| Feature flags | OpenFeature operator | ❌ |
| Config reload | Reloader | ❌ |
| Resource composition | kro, resource-graph-definitions | ❌ |
| Policy reporting | policy-reporter | ❌ |
| VM workloads | KubeVirt | ⚠️ `cdi` only |
| Chaos engineering | Chaos Mesh | ❌ |

Beyond components, the platform also hand-maintains the **cross-cutting wiring** that makes them a
platform rather than a pile of charts: cluster policies, cluster secret stores, security exceptions,
cluster roles and bindings, the gateway, and audit-log forwarding.

## Audience and problem

Someone who wants a production-ready Kubernetes platform today has two bad options: assemble ~30
components and their wiring themselves (the years this epic exists to save), or fork a reference repo
and inherit an extensive GitOps config they must then understand and maintain. `platform-template`
serves the second path. Neither gives them *"choose the stack, get a working platform, keep the
ability to change anything."*

## Hypothesis

If KSail's existing slot mechanism is extended to the full production capability set, with built-in
opinionated defaults and presets that compose them, then a user can go from nothing to a
production-shaped platform in one selection — and, because every managed component stays
GitOps-overridable, they never hit the ceiling that made them fork.

## Success signal

The honest end-state test: **KSail can stand up a platform materially equivalent to
`devantler-tech/platform` from configuration alone, with no hand-written GitOps config required**, and
that equivalence is re-measured rather than assumed as the reference platform evolves.

Interim signals, measurable before that: number of reference-platform capability classes reachable
from configuration; whether a preset yields a cluster that passes the platform's own policy and
posture gates; and whether an override applied via GitOps survives a KSail reconcile.

## Hard constraints

- **Additive identity.** KSail remains a CLI for creating, operating and delivering to Kubernetes
clusters, and keeps every existing interface. Nothing here removes or de-prioritises those.
- **No mandatory GitOps config.** A working platform must not require the user to author an extensive
GitOps repository first. Built-in and KSail-managed is the default path.
- **Total overridability.** Every KSail-managed component and configuration is extensible and
overridable through GitOps. A slot the user cannot escape is a defect.
- **Opinionated, not arbitrary.** Defaults track best practice and the reference platform, and each
default is justified where it is declared.
- **Feature-flag-first.** New platform capability lands default-off and tested in both states, per the
portfolio's delivery contract.

## Supersedes a standing constraint

[#6359](https://github.com/devantler-tech/ksail/issues/6359) currently records an agent-authored
guardrail — *"never to re-found it as a platform distribution"*, and that a capability making KSail a
platform distribution is *"belongs to another product"* by default. **That guardrail is superseded by
the maintainer direction above** and is being annotated on that epic, so its capability-by-capability
survey is judged against this direction rather than against the old boundary. The half of #6359 that
survives is the part this epic also asserts: KSail keeps being a CLI and keeps its other interfaces.

## Relationship to existing work

- **#5441** (multi-cluster/multi-provider scaffolding) is complementary and partly upstream: its item 3
— declarative `environments × providers` expansion — is the wiring generation this epic assumes.
- **#6359** supplies the competitive survey; its verdicts should be re-derived under the new boundary.
- **#5827** (web UI / Headlamp parity) is the interface half of *platforms as a product*.
- **#4899** (per-component operator lifecycle) is the mechanism day-2 management builds on.
- `platform-template` and `platform-tenant-template` represent the current fork-and-edit path this
epic aims to make unnecessary for most adopters — not to retire them.

## Decomposition

Children are listed on this epic as sub-issues. The first is a Spike, because the slot/preset schema
and the override contract must be decided before any component work is worth starting.

## Size

Extra large — a multi-quarter programme, delivered slot by slot behind flags. No single PR closes it.

Begin with the first Spike sub-issue and inspect the existing spec.cluster capability slots, then compare them with the referenced devantler-tech/platform configuration. Define the slot/preset schema and GitOps override contract before component work begins; completion is a documented, testable direction for the multi-quarter decomposition rather than a single implementation PR.

Written by the indexing model from the issue text.