Build an internal developer platform

Try it now

Three steps, smallest first. Each one is a real command or a recorded walkthrough, and every claim behind them links a committed receipt.

$ git clone https://github.com/confighub/kubara-confighub.git

$ cd kubara-confighub

$ cub plugin install confighub/cub-workshop

$ node scripts/create-kubara-platform.mjs --name demo-platform --services cert-manager,metrics-server,traefik --repository https://github.com/acme/platform.git --output ../demo-platform

# Generate local platform files with Kubara
$ kubara --work-dir ../demo-platform --config-file config.yaml --env-file .env.example generate --helm

# Kubara's own output as a stack, each chart rendered with its generated values
$ cub stack from-kubara ../demo-platform

$ cub stack certify ../demo-platform/confighub/stack.yaml

# or the catalog's tested images of the same three charts
$ cub stack sandbox kubara-platform

$ cub fleet up demo-platform

$ cub fleet age demo-platform && cub fleet status demo-platform

$ cub variant promote metrics-server-demo-dev --dry-run

cub cluster up --name demo --space demo-cluster

I am building or operating an internal developer platform on Kubernetes.
My platform components: <list them, for example cert-manager, traefik, metrics-server, kube-prometheus-stack>.

1. Fetch https://confighub.github.io/helm-expt/site/changes.json and check which of my
   components have a checked entry in this catalog.
2. For each covered component, open its catalog page and compare my configuration with
   the recorded objects, prerequisites, hooks, CRDs, and license before I install it.
3. For each component with no entry, say so plainly, and with my approval file it at
   https://github.com/confighub/helm-expt/issues/new?template=problem-chart.yml
   so it gets a checked entry with receipts.
4. Then read https://confighub.github.io/helm-expt/site/kubara.html and tell me which
   of my components the recorded platform journey already covers.

Why hand any of this to an agent? Our committed two-round benchmark measured where agents are already strong and where they cannot be. A bare agent with a shell answered static chart questions at 96.7 percent. Twelve of eighteen questions about time, live state, and accountability needed records the agent could not produce. The toolchain carries day one; the records carry every day after. The benchmark and the full prompt live on the challenge page, and the run data is committed in data/ai-benchmark.

1. Choose services for your developers

This example uses four ordinary platform services and records one optional runtime image. Use the links to check each component, then change the comma-separated service list to suit your platform.

git clone https://github.com/confighub/kubara-confighub.git
cd kubara-confighub
npm run kubara-platform:start -- \
  --name inference-platform \
  --repository https://github.com/acme/platform.git \
  --services cert-manager,metrics-server,traefik,kube-prometheus-stack \
  --runtime-image vllm=vllm/vllm-openai-cpu:v0.27.1-arm64@sha256:e6745d7ba6610f637c6f22fc06cd730342e50245b6c46767235600483adfbbde \
  --output ../my-platform

Replace https://github.com/acme/platform.git with the HTTPS Git repository where you will keep the generated platform.

The command needs Node.js. It does not contact ConfigHub Server, an OCI registry, or Kubernetes.

Website to command line: choose and inspect components here, then run the command with those exact component names. Give the generated files to your AI assistant when you want help with a change; review its file diff before running Kubara again.

Open the exact generated example · Open the smaller three-service starter

2. Review what the starter wrote

3. Generate and inspect the platform

In ../my-platform, review the generated .env.example, create a private .env, and replace every placeholder. Do not commit the private file. Then run Kubara:

cd ../my-platform
kubara --work-dir . --config-file config.yaml --env-file .env generate --helm

Review the generated Kubernetes files and the required CRDs, hooks, setup Jobs, Secrets, certificate issuers, storage classes, and APIs. The Catalog links explain the known behavior of each selected chart, but the final check must use this platform's generated output and intended cluster.

4. Choose where the reviewed result goes

Keep the generated platform in Git, or compile its exact revision into component OCI packages plus a digest-bound platform index. Neither choice needs a ConfigHub account. Use ConfigHub when you want retained platform versions, environment variants, approvals, promotion, release OCI, rollback, or live fleet comparison.

Package the reviewed Git revision as OCI · Continue through ConfigHub and Argo CD · See what can be flattened

See the four-cluster result · Check the evidence · Open the technical runbook

See two applications added, promoted, released, and checked on the platform.

Benefits with explicit acceptance evidence

Each status pill reads one of three ways. A current live pill means a current live run accepted the benefit, and some name the exact result, such as a passed performance gate or zero audited residue. A current deterministic pill means committed deterministic evidence accepts it, without a live run. Any other wording means the deterministic contract still holds while its live acceptance is absent, stale, or not yet accepted.

One gate remains open. Every benefit below was accepted in the project's own retained four-cluster organization. A clean import into a fresh organization that you choose has not run yet, and it is the gate that stands between these results and a claim about your platform.

The status is generated from an exact evidence chain, component by component. Some current live evidence may already pass, but the complete publishable chain is still gated. Missing or inconsistent faithful, source-digest mini-IDP, performance, matrix, wiring, orphan, or GUI evidence stays visible instead of becoming a green marketing claim.

The composition, as evidence

Each component in a stack carries a certified-bundle receipt that names what it is and how it may be flattened, and the eight-bundle EKS inference platform is one worked example. The single composition verdict over a whole stack is specified and runs two ways today. This repository arms it as a regression gate over its own receipts. The workshop plugin's cub stack certify runs it anywhere, refusing a real conflict rather than reporting one. As a gate inside the ConfigHub product it remains proposed. The wiring facts above are the report those checks read.

What stays Kubara, and what ConfigHub adds

Make latest discoverable, not deployable

The adapted lane keeps targetRevision: latest as a discovery address but leaves automated sync off. On the automated path, mutable latest cannot race past approval, promotion, or rollback, and ConfigHub selects the exact OCI digest before Argo CD receives it. Blocking a privileged human or a manual Argo sync needs your own RBAC or admission control.

One adoption journey, in the user's order

The preparer, scanner, package verifier, binding lock, and receipt checks are checkpoints inside these steps. Certify is new here: it turns the pushed revision into a stack and checks it before OCI makes it immutable.

1. 1. Choose components and wiring
   Keep Kubara catalogs, config.yaml, values overlays, and service definitions.

2. 2. Generate the platform and push it to Git
   Run Kubara to generate the familiar platform, add-ons, ApplicationSets, overrides, and wiring. Then prepare, scan, commit, and push one exact portable revision.

3. 3. Certify the platform as a stack
   Turn the pushed revision into a stack with cub stack from-kubara, then run cub stack certify until the composition holds together.

4. 4. Import the Git revision and create OCI
   Publish immutable component/config packages plus a digest-bound platform index.

5. 5. Load the selected ConfigHub organization
   Materialize the recognizable topology, apply twice, and prove zero residue in the declared scope.

6. 6. Deploy applications
   Promote, approve, release, and roll back; local Argo reconciles only the exact ConfigHub-authorized digest.

Open the complete tutorial and its checkpoints.

What we show in ConfigHub

1. The source-bound platform contract and familiar hub/spoke identity.
2. The component-first Catalog, retained versions, and selected instances.
3. Faithful Kubara and adapted ConfigHub delivery lanes side by side.
4. hx-web and Cubbychat across development, staging, and two production targets.
5. Curated native NeedsProvides Links, followed by the full extracted graph.
6. Exact-head production approval, promotion, departure, rollback, release, OCI digest history, and the visible no-auto-sync authority boundary.
7. The 16 journaled selector migrations, including four retained PostgreSQL PVC identities.
8. The 36-cell matrix: desired placement/version/departure, ConfigHub release digest, Argo observed revision/sync/health, and Kubernetes desired/ready counts remain separate; missing runtime evidence is Unknown. Today it observes 24 cells and marks 12 disabled, across 9 components and 4 clusters. See the full colored matrix and the catalog-adapter snapshots on GitHub.
9. The separate exact ConfigHub and scoped Argo/workload residue result.

The deterministic story is current. Live and GUI claims remain gated. Faithful, mini-IDP, performance, health, orphan, matrix, wiring, and all six published screenshots must match this source.

Run the screenshot-free pre-capture gate before opening the browser. Publish exactly six real, source-current frames. Their atomic GUI receipt must bind the source and organization. It must also bind faithful, mini-IDP, orphan, matrix, wiring, image digests, capture times, visible identities, and claim boundaries. Never substitute placeholders or mocked screenshots.

Follow the receipt-bound GUI tour.

The honest boundaries

• This is deterministic adoption, not an AI rewrite. Ordinary catalog and configuration updates may still be required.
• The user explicitly selects the organization. Targets and the local delivery runtime are current prerequisites; the importer does not silently create or guess them.
• Secrets and target-owned facts stay outside the portable Git and OCI payloads.
• Desired state, current live state, historical evidence, OCI publication, and production support remain distinct claims.
• The exact-digest evidence controls the managed automated path. Blocking privileged human or manual Argo sync additionally requires separate RBAC or admission proof.
• The current no-op records 33 ConfigHub CLI read commands and 208 total subprocess calls. It completes in about 77 seconds, with zero ConfigHub mutation attempts and zero Argo sync requests. The fixture regression target is met. CLI commands are not HTTP round trips; this is not a raw-Kubara comparison or a service-level promise.
• The retained four-cluster organization is live-proved. A clean import into a fresh user-selected organization is still a separate graduation gate.

live receipt required means a deterministic contract exists but its current live acceptance chain is absent or stale.

Keep all the detail

The concise buyer journey does not replace the engineering material. Use the complete mini-IDP and maintainer runbook, importer contract, matrix and wiring evidence, and performance analysis.

The example is accepted only after a clean-checkout import into a fresh user-selected organization passes twice. The orphan count must be zero, one application must be healthy, and every published screenshot must be receipt-bound.