Blog Post Plan

A repository document, rendered for the site. View source markdown.

What this command does. cub installer is a released, open-source plugin for the cub CLI. cub installer setup pulls a catalog package and writes its Kubernetes files locally. It does not apply those files to a cluster; use kubectl, Argo CD, or Flux for delivery. The generated scripts stop before doing any work when the plugin or kustomize is missing.

Generated at: 2026-07-30T12:38:02.000Z UTC · source: committed helm-expt evidence for this rendered repository document.

This is the public-facing story sequence for explaining the Helm experiment without making the reader learn the internal noun ladder first.

1. Stop Approving Helm Guesses

Audience: Helm users who have felt install, upgrade, and audit pain.

Core claim:

Helm is good at producing Kubernetes objects. The operational pain is that
teams often approve values files, not the exact objects those values produce.

Show:

Proof links:

2. Redis In Five Minutes

Audience: practical users asking "what do I run?"

Core claim:

New to cub? Install the cub CLI first. You can pull and render public catalog packages without an account. Commands that save or change ConfigHub data require you to sign in.

Start from a public Redis chart, render through cub installer, upload to
ConfigHub, inspect Units, and verify your own install with receipts.

Show:

Proof links:

3. Proof, Not Promises: What The Top-20 Catalog Verifies

Audience: skeptical platform engineers and reviewers.

Core claim:

The catalog is not a screenshot demo. The claims are backed by committed
receipts and verifiers that fail when artifacts drift.

Show:

Proof links:

4. Variants Are More Than Values Files

Audience: teams that already use multiple Helm values files per environment.

Core claim:

A ConfigHub variant is useful only when it carries exact rendered objects,
labels, scans, receipts, approvals, and operation history.

Show:

Proof links:

5. Live Truth Without A Magic Worker

Audience: operators who care about what is actually running.

Core claim:

ConfigHub stores desired/config truth and receipts. Live cluster truth should
arrive as fresh observation receipts from explicit tools.

Show:

Proof links:

6. The Hard Charts Are The Point

Audience: Helm experts who know real charts include hooks, CRDs, lookups, generated secrets, globals, tpl, and raw manifest slots.

Core claim:

We do not need to pretend Helm charts are simple. We need to surface each pain
point and map it to a recipe, fact, capability profile, lifecycle policy,
scan, gate, or blocker.

Show:

Proof links:

7. Catalog Maintenance, Old Versions, And Patch Value

Audience: customers who need maintained, boring, production-relevant install paths rather than one-off demos.

Core claim:

A useful catalog needs promotion review, production disposition, upgrade
checks, and support for important old versions, not just latest-chart demos.

Show:

Proof links:

8. GitOps Handoff: ConfigHub OCI To Argo CD Or Flux

Audience: teams that already use Argo CD or Flux and do not want a second deployment controller.

Core claim:

ConfigHub should make the reviewed rendered object set available through OCI,
then let the customer's existing GitOps controller sync it.

Status:

The live GitOps/OCI proof lane exists as a separate Pilot/cub-scout path. This
post should make that proof easy to understand and link from the Helm catalog
story, without folding live-cluster requirements into the local npm verifier.

Show:

Proof links: