FAQ for skeptical Helm users.

This page answers the questions an engineer asks before trusting the model. What problem does it solve? What has evidence? What remains limited? When is plain Helm still the right tool?

Each answer says what works today, what is still limited, and where to check the evidence.

Start Here

Is this just Helm with extra paperwork?

answered

No. You keep Helm charts. The catalog adds ready-to-use base variants, recorded render inputs, generated output, scans, receipts, live evidence, and ConfigHub Units when uploaded.

Do I have to rewrite my charts?

answered

No. We do not ask you to abandon Helm charts for a new chart language. We help you make better choices with the charts you already use.

How is cub installer different from cub helm?

answered

cub helm imports an arbitrary chart and values as a ConfigHub base. cub installer reads a maintained catalog package with named configurations and requirements. They are optional preparation tools. The official tutorial teaches the ConfigHub journey after that starting point.

Do you support every Helm values combination?

answered

No. A chart can expose too many combinations for one tested claim. The catalog covers common operating choices with chart-specific base variants. Examples include default, no-CRDs, existing Secret, server-only, HA, and internal service.

Isn't that case-specific?

answered

Yes. Helm charts differ, so the catalog records chart-specific base variants, tests, and notes. AI can help maintain those variants across chart versions. Tests and receipts determine what the catalog accepts.

What is a base variant?

answered

A base variant is a supported Helm configuration for one chart version. It records the values and render inputs. It also captures the Kubernetes YAML and names any extra install work.

Does it only work for easy charts?

answered

No. Redis teaches the path, but kube-prometheus-stack is the serious proof chart. It exercises CRDs, webhooks, RBAC, generated facts, extension slots, target prerequisites, upgrades, and live observations.

What do the current generated counts say?

answered

The current proof counters are generated from committed evidence. They are useful for orientation, but the matrix remains the source for chart-by-chart decisions.

199/199Render parity
198/199In-ConfigHub proof
148/199Local live
139/199GitOps/OCI live pass
139/199Live Helm-vs-ConfigHub parity pass
126/199Complete core lanes

How It Works

How does it actually work, end to end?

answered

Choose a chart and base variant, then record the values and render inputs. Render the YAML and handle any extra install work. Deliver the reviewed result and observe it live. Hooks, CRDs, setup jobs, Secrets, and cluster requirements remain separate decisions until evidence proves each one.

How is config delivered, and what about OCI and credentials?

answered

ConfigHub publishes the reviewed Units in one Space as a release OCI. Argo CD, Flux, or direct apply can use it without rendering Helm again. A hook fixture proves the mechanism. An NGINX receipt proves one catalog base through all three paths at one digest. Other bases need their own receipts. cub cluster up installs the Argo CD pull credential. The Flux test copies it into flux-system without printing it.

How do upgrades and rollback work?

answered

ConfigHub compares the candidate with the Kubernetes objects you already reviewed. It publishes the approved result as OCI. Every Unit keeps its revision history. The Redis live test restored the exact pre-upgrade revisions and published a rollback OCI. It then tested both clusters again. This restores configuration, not database data. Irreversible migrations still need a chart-specific recovery plan.

What is a Unit, a space, or a target?

answered

A Unit is one versioned desired-state record. A Space holds related Units. A Target defines where ConfigHub delivers them. An OCI Target publishes the Space as a bundle.

I already run Argo or Flux. What changes?

answered

You keep your controller. Point it at the OCI bundle that ConfigHub publishes from reviewed Units. The controller no longer rerenders Helm values from Git. Hooks become recorded routes with named execution steps.

What is safe for AI to change?

answered

Ask AI to propose a new base, derived variant, policy change, or object patch. ConfigHub can show the diff and require tests or approval. Do not let AI rewrite live state or bypass the recorded change path.

Hooks, Secrets, And Targets

What happens to Helm hooks?

answered

Hooks are not ordinary static YAML. Each chart page says whether to run setup, use a tested GitOps action, require a decision, or stop. A recorded route does not mean ConfigHub runs it automatically.

What about CRDs?

answered

CRDs need an ownership decision. Some base variants include them. Some base variants leave them out because the target cluster or another controller owns them. If a chart needs CRDs before custom resources apply, the chart page should say that before you install.

Where do Secrets and credentials live?

answered

Do not hide them inside ConfigHub by accident. The catalog separates generated Secrets, existing-Secret references, target facts, and runtime Secret lifecycle where the chart requires that distinction.

What if the cluster is the wrong shape?

answered

A green render is not enough. Some charts need CRDs, Secrets, or cloud identity that a generic cluster does not provide. When a chart needs more than a generic cluster, we mark it clearly and say what's missing.

Can every hook run automatically in the ConfigHub path?

P1 backlog

Not yet. The project can route and observe hook-like lifecycle behavior where evidence exists. Universal automatic execution still needs per-route product support, executor ownership, and live evidence.

Parity, GitOps, And Upgrades

Can I trust a green GitOps sync?

answered

Not by itself. Sync means the controller accepted the desired state. Workload convergence, target prerequisites, controller-owned fields, and semantic parity need separate evidence.

What if a Helm upgrade caused a production crash?

answered

The model breaks the upgrade into visible steps: old render, new render, object diff, and live checks. That reduces opaque upgrades. It does not promise crash-free production.

What should I do with non-green rows?

answered

Use the matrix to read the reason. A watch, blocked, refused, or n/a cell can be the correct answer when the reason is named and linked.

Can a live Kubernetes fix flow back into desired ConfigHub state?

P1 backlog

Not as a shipped product path yet. The reverse-reconcile design defines authority, scoped write-back, attribution, and round-trip proof. The product still needs a gated command and live proof.

Values, Variants, And Catalog Scope

Can I load my existing app, platform, stack, or live cluster?

answered

Yes. Start with a read-only discovery or import. Review the sources, targets, objects, labels, and owners. Then keep the imported Units, create a recipe, or build a managed application.

Which path should I take?

answered

Use the public catalog when a reviewed base variant exists. Use plain Helm when the chart still needs a better base variant or limitation decision. Create a new base variant when Helm inputs change. Create a derived ConfigHub variant when the change is post-render. Ask for managed help when private charts, teams, approvals, fleet operations, or production responsibility enter the path.

I know Helm flags. Why does cub reject --set or -f values.yaml?

answered

cub installer uses declared inputs and named bases instead of Helm's free-form --set model. Today cub rejects those Helm habits safely, but the errors are still too opaque. Use the migration guide until the CLI teaches this directly.

Where would a Helm user go back to Helm today?

watch

The adoption audit lists places where cub is harder than Helm today. They include defaults, one-value changes, direct upgrades, CRD ordering, uninstall, and rollback. Use Helm when one of these gaps blocks a reliable cub path.

How much of the top-100 is ready for a user?

answered

The catalog does not make one claim for all 100 charts. Some are ready to try. Others need cluster prerequisites, operator review, or a better base.

20Ready to try
15Needs target prerequisites
23Needs operator review
33Needs a better base

Can the catalog prove every values combination for a chart?

P1 backlog

No. Claims are per chart, version, base, values path, lane, and target profile. A new values file or overlay needs its own render, scan, receipts, and live evidence.

Can every top-100 or top-500 chart become ready-to-run?

P1 backlog

Not yet. The top-20 has the strongest evidence. The top-100 has clearer readiness records. Most top-500 entries remain analysis and triage data until they gain recipes, bases, and receipts.

Trust, Free Use, And Challenges

What is free and what needs ConfigHub?

answered

Public catalog browsing, local render checks, and catalog package setup are free or low-friction. Private catalogs, teams, approvals, application variants, promotions, fleet operations, and production responsibility are ConfigHub-managed.

What can we build once the objects are data?

answered

The RBAC report tests every committed default render without a cluster or another Helm run. A live example removes unnecessary Secret access. It requires approval, publishes the reviewed objects as OCI, and verifies the Argo CD result on Kubernetes.

What should I do if this breaks on my chart?

answered

Send the public chart and values that expose the problem. The expected response is a public fixture and a pass, watch, blocked, refused, or routed gap with evidence.

My Helm chart broke. Can this help me triage it?

answered

Start by comparing the rendered objects. Inspect cluster prerequisites, lifecycle routes, image pulls, controller status, and workload health. Then classify the problem as a recipe gap or a cluster runtime gap.

Are signatures enough to establish trust?

P1 backlog

No. Signatures help integrity and transport. Trust also needs signer authority, policy context, scans, gates, and live evidence. Keep that boundary visible.

Known Footguns We Surface

Do default bases generate fresh passwords?

answered

No. Keep credential material outside the render. For affected charts, the package default now uses an existing Secret and renders no shared password. The page gives you a command to create fresh Secret material before apply. Fixed-password demo bases are explicit, non-default choices.

Does cub-direct remove resources that disappear during an upgrade?

watch

Plain kubectl apply does not prune. The no-controller cub-direct path can orphan removed resources unless it uses kubectl apply --prune with a safe selector/allowlist, or another explicit delete-set. Argo and Flux are not affected because they prune declaratively.

Can cub-direct first-install CRD charts without ordering?

watch

Not safely yet. A plain apply of a bundle that contains both a CRD and a custom resource can apply the custom resource before the CRD is established. The no-controller path needs CRD-first ordering and a wait/retry step, or a controller that handles ordering.

Does cub-scout catch every live drift?

watch

No. The current live gap proof shows cub-scout detects replica drift but misses container environment-variable drift. Drift detection is valuable, but it must state field coverage until pod-spec coverage is complete.

What happens if someone manually edits a field and cub re-applies?

watch

cub's managed delivery uses server-side apply. If someone edits the same field by hand, Kubernetes can block cub instead of silently overwriting the change. That can be safer, but the CLI must explain it and offer a clear reconcile or force path.