Kubara platform configuration

This is the same README you will find in the matching demo Space in Hub. It explains why the Space exists, what problem it demonstrates, and what to inspect first. View source markdown.

Generated at: 2026-07-30T12:38:02.000Z UTC · source: generated README for this demo Space, built from committed helm-expt evidence.

Kubara generated the Helm source and cluster values for a small Kubernetes platform. ConfigHub stores the exact rendered objects as one reviewed base variant.

Start here when you open this Space in Hub. This page explains the problem this example is meant to show, what to inspect, why it matters, and where the evidence lives.

Why this example exists

Kubara can choose a platform stack and generate its source configuration. The operations problem starts after that: teams need to review the exact result, compare cluster versions, and move a tested change through a fleet.

Kubara still generates the platform. ConfigHub gives the team one place to review the result, compare cluster versions, approve changes, and see what each cluster should run.

What this example shows

Where each setting comes from

PlaceWhat this Space records
Starting configurationOpen the upstream Space or source link named on this page. That is the configuration this Space started from.
ConfigHub changesOpen Unit revision history. It records changes made after the starting configuration was saved.
Install workUse the linked chart or route evidence for required Secrets, CRDs, hooks, setup jobs, and target facts.
Live clusterUse target observations to compare the cluster with the reviewed Units. A live-only edit is drift until it is recorded or removed.

If an upstream change and a local ConfigHub revision touch the same field, review the overlap before promotion.

What to inspect in Hub

Evidence and source

Limits