UNOFFICIAL/EXPERIMENTAL. The bar that actually matters for adoption: people want something better than helm install, but they avoid anything different or confusing. So the gaps worth hunting are not "cub is incomplete" - they are "cub is worse than, or more confusing than, plain Helm on the common journey, such that a user bails back to Helm." And for each, the question is: is it solved (as easy as Helm), or at least managed (guided, graceful, surfaced), or an unmanaged footgun?
This audit scores the common chart journey. Evidence is the gap-hunt PRs (#1008–#1015) plus direct CLI checks. It is deliberately balanced - cub wins are listed too.
The scorecard
| Journey step | Helm as-is | cub today | Winner | Managed? | Evidence |
|---|---|---|---|---|---|
| Install with defaults (e.g. redis) | generates a random per-install password; runs + is unique | ships a fixed shared password (confighub-redis-password, same for everyone, committed) | Helm | ❌ unmanaged - base named generated-passwords misleads; no "replace me" warning | #1012 |
Customize one value (--set replicaCount=3) | one flag, works | --input replicaCount=3 → rejected (unknown input); must edit the base's kustomize | Helm | ❌ unmanaged - error is unknown flag/input, 0/72 idioms guided | #1009 |
| Upgrade that removes a resource | tracks release state, prunes the removed object | cub-direct (kubectl apply) orphans it | Helm (vs cub-direct) | ⚠️ partial - Argo/Flux prune; cub-direct is silent | #1013 |
| First install of a CRD chart (cert-manager) | installs CRDs first, works | cub-direct fails (CR before CRD established) | Helm (vs cub-direct) | ⚠️ partial - controllers handle it; cub-direct fails | #1015 |
Uninstall (helm uninstall x) | one command, per release | cub unit destroy (+ delete/space cleanup); per-unit, Unit/Space concepts | Helm (ergonomics) | ⚠️ partial - capability exists, no uninstall verb | CLI check |
Rollback (helm rollback x 2) | one command, per release | cub unit apply --revision N; per-unit, revision numbers | Helm (ergonomics) | ⚠️ partial - capability exists, no rollback verb | CLI check |
Typo a value (--set replicaCont=3) | silently absorbed (Helm's footgun) | rejected (unknown input) | cub | ✅ caught at the tool | #1008 |
| Review what will change before apply | none native (diff plugin) | deterministic config-as-data diff | cub | ✅ | #1011 |
| Detect drift after deploy | nothing | cub-scout detects (misses env, but real) | cub (net-new) | ✅ partial | #1014 |
The pattern that decides adoption
cub's wins are downstream - config review, determinism, typo-catching. Its losses are in the first three steps a user takes - install, customize, upgrade - and those losses are unmanaged (a silent shared password, an opaque unknown flag, a silent orphan). A Helm user evaluating cub hits the losses first and bails before ever reaching the wins. That is the adoption trap: "better, but I bounced off the confusing part."
So the rule this audit argues for: a worse-than-Helm step is only acceptable if it is managed. Unmanaged worse-than-Helm steps on the first-run path are adoption-fatal regardless of how good the downstream model is.
What "managed well" looks like (the fixes)
| Loss | Solve (make it as easy as Helm) | …or manage (guide / graceful / surfaced) |
|---|---|---|
| Shared default password (#1012) | generate real per-install entropy in the default base | rename generated-passwords → placeholder-passwords; print "this is a placeholder, replace before prod" at setup |
| Customize friction (#1009) | expose the common values (replicas, resources, image) as declared inputs | migration guidance in errors (--set → "use --input/edit the base; see cub installer doc"); the cheat-sheet (#1010) |
| cub-direct upgrade orphans (#1013) | the cub-direct applier uses kubectl apply --prune (allowlist) | default users to a controller for upgrades; state cub-direct's limits in the doctrine |
| cub-direct CRD first-install (#1015) | apply CRDs first + wait in the cub-direct applier | same - default to a controller for CRD-bearing charts |
| Uninstall / rollback ergonomics | add cub rollback / cub uninstall aliases over unit apply --revision / unit destroy | cover them in the migration cheat-sheet so a Helm user finds them |
Honest: where cub genuinely beats Helm (so we don't only sell the model on these)
Typo-catching (declared inputs reject what Helm absorbs, #1008), deterministic renders that make a config-as-data diff trustworthy (#1011), and drift detection Helm doesn't have (#1014). These are real - but they are earned after the first-run friction is managed, not before.
Next hunts (still under this lens: worse-than-Helm + managed?)
- A concrete side-by-side journey proof: same task (install redis, set one value, upgrade) via Helm vs via cub, counting steps + outcomes.
- Secret rotation (change a password): one
helm upgradevs the cub flow. - Server-side-apply field-ownership conflicts on re-apply (cub-direct vs Helm).