Kubara local platform example · ConfigHub Workshop

New to cub? Install the cub CLI first. Public catalog packages pull and render anonymously, and you sign in only once a command saves or changes ConfigHub data.

Generated at: 2026-10-06T13:45:42.258Z UTC · source: committed helm-expt evidence for this rendered repository document.

What it is. Kubara platform kubara-local-platform v0.12.0, as 77 Kubernetes objects.

Install it. The five steps below give the commands.

Needs first. Apply the CRDs first and wait for Established before applying Argo CD custom resources. Apply the hook RBAC and Job, wait for the Job to complete, record the result, then continue. The plan below lists 2 more.

Kubara turns one platform description into the Helm charts and cluster-specific values that Argo CD uses to run a Kubernetes platform. This example uses Kubara v0.12.0's local evaluation profile. It enables Argo CD, cert-manager, External Secrets, a small portal, Prometheus, Metrics Server, and Traefik for one test cluster.

ConfigHub does not replace Kubara. Kubara decides which platform services belong together and generates their source configuration. ConfigHub can keep the exact rendered objects as a base variant, show changes between cluster classes, apply policy, and promote a reviewed platform change through a fleet.

This Space requires approval before apply because it changes cluster-wide platform configuration, even when the target is not production.

What is here

source/config.yaml is the Kubara platform description.
source/values-helm-expt-paths.yaml is a normal Kubara values override. It points the generated Argo CD ApplicationSets at this example's committed directories.
source/values-homer-links.yaml replaces the generated portal's placeholder link with a useful project link. Kubara and Argo CD load it through the normal values-*.yaml convention.
catalog-alignment.yaml maps every exact Kubara-selected public dependency and first-party component against the current ConfigHub Catalog. It records exact offline candidate paths, root-retention and Kubara-compatibility gaps, verified upstream digests, every older retained version, the future adapter contract, and the additive-only rule.
../../../data/kubara-catalog-refresh/candidates/ contains the seven exact, digest-bound offline recipe/package candidates. Candidate verification proves every older retained root remains present; it does not claim live support or complete Kubara wrapper compatibility.
generated/ is the Helm source and cluster values produced by Kubara v0.12.0.
rendered/release-objects.yaml is the exact 77-object render of the generated Argo CD chart.
route-intent.yaml records the CRDs, Helm hook Job, External Secrets prerequisite, and two rendered Secrets that need special handling.
oci-layout/ contains the same literal render as a local OCI artifact.
generation-receipt.yaml states what ran and what has not run.
confighub-upload-receipt.yaml records the live Space, Unit, source digest, omitted Secrets, and approval required for cluster-wide system configuration.
../../../runs/kubara-oci-delivery-proof/receipt.yaml records approval, ordered route work, portable OCI delivery, Argo CD reconciliation, Metrics Server health, and cleanup.

The temporary .env used by Kubara is not committed. It contained only local evaluation placeholders, but it is still treated as a credential file.

Why the route record matters

The rendered file is not the whole installation procedure.

Argo CD custom resources need three CRDs first. The upstream Argo CD chart also uses a pre-install and pre-upgrade Job to create its Redis Secret. A ClusterExternalSecret needs the External Secrets CRD and a working ClusterSecretStore. Finally, cub variant upload deliberately leaves Secret objects out of ConfigHub.

Those requirements are recorded beside the render so an operator or an automation can perform them in the right order and keep a receipt. They are not described as ordinary objects that can be applied in any order.

Reproduce it

Download Kubara v0.12.0 and verify the release checksum in source-lock.yaml. Then run:

npm run kubara-catalog-candidates:generate
npm run kubara-catalog-candidates:verify

KUBARA_BIN=/path/to/kubara \
  npm run kubara-example:generate

npm run kubara-example:verify

The first two commands reproduce and verify the seven digest-bound offline component candidates without changing any retained root version. The example generator then creates a temporary .env, runs kubara generate --helm, builds the pinned Argo CD chart dependencies, renders the chart, and creates the local OCI layout. It also renders the downstream Homer chart with both values files to prove that the override replaces Kubara's generated placeholder. It removes the temporary directory when it finishes.

Inspect the retained v0.12 organization-shape record

The historical proof mirrored source/config.yaml as the untargeted hx-platform/platform-contract Unit. Its exact 53-Space label plan and committed receipt remain available as dated evidence. They are not the desired state of the current Kubara v0.13.0 organization.

Only the offline plan, receipt verification, and retirement self-test are supported:

npm run kubara-org-shape:plan
npm run kubara-org-shape:receipt-verify
node scripts/sync-kubara-org-shape.mjs --self-test

The retired --apply and live --verify modes fail before reading or writing ConfigHub. Do not use this fixture to reconcile the current Kubara organization: follow the current v0.13.0 mini-IDP guide and its kubara-mini-idp:* commands instead. The retained receipt proves only the historical mapping; it does not claim to rebuild or govern the current four-cluster platform.

Kubara-native one-cluster delivery result

Generation, Helm rendering, route analysis, local OCI packaging, and ConfigHub upload have run. The demo org stores all 75 non-Secret objects in one Unit because it had reached its Link quota; the two rendered Secrets were omitted as the command promises. ConfigHub required approval and published a private release.

The live delivery proof installed the Argo CD CRDs first, supplied the target-owned Secrets, ran the Redis initializer, and packaged 69 prepared objects as a portable OCI. Bootstrap Argo CD reconciled that exact digest. Kubara Argo CD became ready and created one Metrics Server Application, which became Synced and Healthy.

The test used one kind cluster, one selected service, and a temporary OCI registry. The ClusterExternalSecret and gRPC Ingress were deferred because their controllers and target data were not present. The full seven-service profile and a multi-cluster promotion wave have not run.

Use this entry in ConfigHub

Every Catalog entry page carries these five steps in this order. Each step says what the Catalog has run for this entry, and a step with a missing precondition gives no command.

Steps 1 and 2 need no account.

What is fixed, and what you supply

Fixed when this entry was built. These went into the build, so the objects already carry them. To change one, build the entry again from its source.

cluster is test-cluster
stage is local
clusterType is hub
enabledServices is argocd,cert-manager,external-secrets,homer-dashboard,kube-prometheus-stack,metrics-server,traefik
helmKubeVersion is 1.34.0
releaseName is kubara-platform
namespace is argocd

Yours to supply or check. The destination must have these before the objects are applied. The words in italics say what the Catalog knows about each.

Argo CD target cluster Declared. Not checked on any destination.
External Secrets ClusterExternalSecret CRD Declared. Not checked on any destination.
ClusterSecretStore=test-cluster-local Declared. Not checked on any destination.
remote image-pull key when private images are used Declared. Not checked on any destination.
approved handling for argocd-secret and cluster-kubernetes.default.svc Declared. Not checked on any destination.

This entry's plan, and how to test it

These are the steps that plain objects cannot carry. ConfigHub stores them and does not carry them out. The words in italics say what the Catalog knows about each.

Once the destination is known. apply the CRDs first and wait for Established before applying Argo CD custom resources Who: not selected. Written down. Not run on a cluster.
Once the destination is known. apply the hook RBAC and Job, wait for the Job to complete, record the result, then continue Who: not selected. Written down. Not run on a cluster.
Once the destination is known. check the CRD and Secret-store facts before applying the ClusterExternalSecret Who: not selected. Written down. Not run on a cluster.
Once the destination is known. create or bind these two Secrets through the approved Secret path before applying the remaining objects Who: not selected. Written down. Not run on a cluster.

Read what a plan is, and why some entries have one.

1. Get the exact objects Run for this entry

The Catalog rendered this entry and retains its 77 objects in one file.

# fetch the retained objects for this entry
$ curl -fsSL -o kubara-local-platform-v0-12-0-base.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/examples/kubara/local-platform/rendered/release-objects.yaml

# check the bytes against the listing
$ shasum -a 256 kubara-local-platform-v0-12-0-base.yaml
fa12bcd9947b46b9423f4876b39fc22c764613574319bcf8a532921ec716c541  kubara-local-platform-v0-12-0-base.yaml

2. Compare with another version or base Not available yet

The Catalog holds no other version or base of this entry's source in the same format. A second entry for local-platform in this format would give this step a sibling.

3. Upload it as a variant Not available yet

This entry is not published, so there is no public artifact to upload. The listing records its literal configuration bundle as held only as a local layout. Publishing the rendered objects as that bundle, with a receipt, would make this step available.

4. Deploy it Not available yet

This step needs an upload command from step 3, and this entry has none. A published artifact for this entry, with a receipt, would make this step available.

5. Promote a change Not available yet

This step needs an upload command from step 3, and this entry has none. A published artifact for this entry, with a receipt, would make this step available.

For agentsThese steps are the nextSteps array of kubara-local-platform-v0-12-0-base.json. Each state was read from flattened.retainedObjects, flattened.inventory, source.ociRef, oci.bundles, oci.runtimes, lifecycle.promotion, lifecycle.coverage and variants.known in the same listing. A command marked needsAccount there contacts ConfigHub. A step's notes hold its cautions, carries lists the CRDs the base brings, and liveWalk links the dated log that ran its commands.

Technical notes and disclaimers

The Catalog has not decided how this entry is kept, so it has no plain-objects test.