Status: experimental planning document.
Purpose
This project should make experienced Helm users believe that ConfigHub is the safest way to operate popular public Helm charts after day 0.
The entry point is simple:
Use Helm charts. Ship ConfigHub variants.The product value is not only pre-rendering Helm. Rendering creates the first trust boundary: the user can see the exact Kubernetes objects. The larger value is what happens after that: base variants, derived ConfigHub variants, scans, gates, promotion, observation, upgrade review, and blast-radius control.
Redis remains the fast teaching chart because it is small and shows generated facts, target facts, and Secret choices clearly. kube-prometheus-stack is the main proof chart because it has high object count, CRDs, webhooks, RBAC, dependencies, and enough field density to make blast radius visible.
Product Promise
Correct variants, safe operations, immediate proof.For a Helm user, that means:
- choose a reviewed base variant instead of inventing a values file from scratch;
- see the exact objects before install;
- create environment, region, customer, or target variants without rerendering Helm unless the object shape changes;
- scan and gate the objects that will actually be delivered;
- promote changes in controlled waves;
- show receipts for render, upload, apply, GitOps sync, and live observation;
- know when a chart needs target facts, lifecycle policy, or manual production review.
Personas
1. Helm User Trying A Popular Chart
This user wants Redis, NGINX, Prometheus, or another common chart to work without learning a new platform first.
They need:
- a clear catalog page;
- a small set of recommended base variants;
- local verification that the artifact is what the catalog claims;
- a live proof path that does not require handing over private data.
Free value:
- browse public catalog entries;
- inspect rendered objects, variants, pain reports, and receipts;
- pull or download public artifacts with digest and signature checks where available;
- run local verification.
Paid or authenticated value begins when the user wants private variants, production records, long-lived receipts, or organization workflows.
Success signal:
I can try the chart as quickly as Helm, but I can see and prove more.Redis is the first five-minute example. Prometheus is the first serious confidence example.
2. Application Team Or Service Owner
This user owns an application and needs dev, staging, and production variants. They care less about Helm internals and more about safe changes.
They need:
- a base variant that matches their install shape;
- a derived ConfigHub variant for target, namespace, region, secret reference, labels, approvals, and observation policy;
- a small preview of what changed;
- checks before the variant can be approved or applied.
Free value:
- public base variants and examples.
Paid or authenticated value:
- storing private variants in ConfigHub;
- team approval flows;
- target-bound variants;
- private values and secret references;
- audit history.
Success signal:
I can create prod from a reviewed base and see the few changes that matter.3. Platform SRE Or Fleet Operator
This user manages many clusters, environments, or tenants. They do not want uncontrolled fanout from raw Helm values.
They need:
- variant inventory across chart, component, environment, region, target, and version;
- bulk scan, bulk patch, and bulk promotion with explicit scope;
- wave-based rollout;
- clear blast-radius summaries before any operation;
- live freshness and drift evidence after delivery.
Free value:
- public examples showing how fanout is controlled.
Paid or authenticated value:
- private fleet inventory;
- bulk operation execution;
- policy and compliance rollups;
- promotion waves;
- SLO-based observation receipts.
Success signal:
I can change 100 variants without guessing which clusters or objects are in scope.The first high-fanout proof should use kube-prometheus-stack or Prometheus, not Redis. Redis teaches the method; Prometheus shows why the method matters.
4. Security, Compliance, Or Audit Reviewer
This user needs proof that the reviewed object set is the object set that was scanned, approved, published, and observed.
They need:
- rendered object digests;
- scan receipts bound to those digests;
- gate decisions and approvals;
- image, RBAC, CRD, webhook, hook, and secret handling notes;
- observation receipts with freshness.
Free value:
- public chart pain reports;
- public scan/gate examples;
- signed or digest-pinned artifacts when available.
Paid or authenticated value:
- organization policy packs;
- private scan evidence;
- compliance reports;
- retention, signatures, and audit export.
Success signal:
I can prove which objects were checked and what was observed later.5. GitOps Operator
This user already runs Argo CD or Flux and does not want ConfigHub to replace the controller.
They need:
- OCI or Git handoff that GitOps controllers can consume;
- digest-pinned desired state;
- controller sync evidence;
- a clear boundary between ConfigHub proof and GitOps reconciliation.
Free value:
- public GitOps examples and local verification.
Paid or authenticated value:
- private OCI access;
- signed release artifacts;
- target assignments;
- GitOps import and runtime receipts across clusters.
Success signal:
I can keep Argo or Flux, but the input becomes reviewed and provable.6. Chart Or Managed-Service Catalog Maintainer
This user maintains a catalog of charts, wrapper charts, platform overlays, or customer-specific managed service packages.
They need:
- an import path from chart plus values plus dependency closure into a durable installer package;
- per-chart pain reports;
- weirdness and mitigation notes;
- base variants for common render-time choices;
- derived variants for post-render customer and target differences;
- refresh and patch review for old chart versions.
Free value:
- public methodology and examples for popular charts.
Paid or authenticated value:
- private chart import;
- private overlays;
- old-version patch support;
- managed catalog review;
- custom lifecycle migration for hooks and CRDs.
Success signal:
I can turn maintained Helm usage into a supported catalog, not a pile of values files.Product Boundaries
Free Or Public
The public experience should show enough value that a Helm user can trust the model before signing up for a production workflow:
- public catalog browsing;
- public chart pain reports;
- public base variants;
- local verification;
- live examples where practical;
- signed or digest-pinned public artifacts where available;
- rate-limited or authenticated public OCI pulls if ConfigHub provides the gateway.
Anonymous browsing can be useful. Anonymous production infrastructure is not a goal. OCI pulls should be protected with rate limits, scoped credentials, or other abuse controls when ConfigHub operates the gateway.
Paid Or Managed
Paid value begins where the user asks ConfigHub to store, govern, operate, or support private or production state:
- private charts and private values;
- customer overlays and wrapper charts;
- private OCI artifacts;
- derived ConfigHub variants;
- approvals, gates, and audit history;
- fleet-wide scan, patch, and promotion;
- live observation receipts across many targets;
- old-version patch SLAs;
- commercial support for hook, CRD, storage, and upgrade complexity.
Main UX Requirement
Users should not be forced to learn every proof artifact before they get value. The public path should route them by intent:
| Intent | First page or action |
|---|---|
| I want to try a chart | Catalog entry with recommended variants |
| I want to deploy safely | Base variant plus verify-your-install path |
| I want prod from staging | Derived ConfigHub variant and promotion guide |
| I operate many clusters | Bulk operation and blast-radius guide |
| I need audit evidence | Receipts, scans, gates, and observation freshness |
| I have private values | Managed import and private overlay path |
The proof remains available underneath each path, but the user should first see the chart, the variants, the operation, and the expected result.
Success Metrics
- A first-time Helm user can identify the right Redis or Prometheus variant in less than two minutes.
- The user can tell whether a choice is a base variant, a derived ConfigHub variant, or a managed/private import case.
- Each top-20 chart shows its variant choices, pain report, live status, and production disposition.
- Bulk operations show the selected scope and blast radius before mutation.
- Day-1 and day-2 guides explain promotion, scanning, patching, and observation more prominently than pure render tests.
- Public docs separate current capability from planned or paid capability.