UNOFFICIAL/EXPERIMENTAL
This page answers the questions a Helm user actually asks about the top-100 charts. The numbers come from the generated top-100 user-readiness data; this page explains what they mean. Counts below are the snapshot at writing - trust the generated file over this prose.
This is the user-facing view of the same data summarized in Top-100 Readiness. The readiness summary has four operating buckets. This page splits the promotion-review bucket into two practical user cases: charts that mostly need target inputs, and charts that need operator review before they are presented as a catalog offer.
| User-facing group | Readiness bucket | Charts |
|---|---|---|
ready-to-try | try-from-public-catalog | 20 |
works-with-target-prerequisites | promote-after-review | 13 |
works-with-operator-review | promote-after-review | 14 |
needs-better-base-variant | needs-useful-variant | 46 |
not-ready-yet | limitation-decision-first | 7 |
Can I use these charts today?
It depends which of five groups the chart is in:
| Group | Charts | What it means for you |
|---|---|---|
| ready-to-try | 20 | Yes. Catalog-supported, a reviewed first base, live evidence on a local cluster. Pull it and inspect the exact objects. |
| works-with-target-prerequisites | 13 | Yes, once you provide something: usually an existing Secret, a StorageClass, or a CRD ownership choice. The render proof already holds. |
| works-with-operator-review | 14 | Probably, but have an operator read the chart's named review item (hooks, lifecycle, HA shape) before relying on it. |
| needs-better-base-variant | 46 | Not as a supported offer. The mechanism is proven, but the install shape you probably want has not been built and reviewed yet. |
| not-ready-yet | 7 | No. A named limitation needs a support / disclose / defer decision first. The chart may work fine under plain Helm; this catalog will not yet vouch for it. |
Which ones are easiest?
The 20 catalog-supported charts. Each has a reviewed start-here base - the shortest list is the start-here table. Redis is the small teaching example; kube-prometheus-stack is the deliberately hard one (CRDs, webhooks, RBAC, generated facts) kept in the catalog to show the model under real complexity.
Which top-100 charts are closest next?
The current fast-track promotion candidates are elastic/logstash@8.5.1 and prometheus-community/alertmanager@1.37.0. Both have render proof, two-cluster kind parity, clean scan/gate state, and selected live Helm-vs-ConfigHub parity evidence.
They are still not catalog-supported. The remaining user-relevant decision is operational: open the generated storage/rollback review, choose the target boundary for backup, restore, retention, rollback, and storage-class fit, then record a target-scoped support decision.
Use the generated fast-track page for the current list: Top-100 Promotion Fast Track.
Which ones need cluster prerequisites?
Charts whose gap is something only you can supply: an existing Secret the chart refuses to generate, a StorageClass decision, CRD ownership, webhook or cert readiness. The per-chart "you provide" column in the user-readiness summary lists exactly what, and the live lanes check those prerequisites against a real cluster before anything claims to work.
Which ones are hard because of hooks, CRDs, secrets, or storage?
Every chart's quirk flags are in the readiness data, and the Helm Quirk Support Matrix says how each quirk class is handled at each lifecycle stage. The honest version:
- Hooks are classified and routed (desired objects, pre-install prerequisite, post-install lifecycle, controller-owned runtime, or unsupported/manual). Routing receipts exist; hook execution receipts do not yet.
- CRDs are split into explicit bases and checked live; Kubernetes-version capability mismatches become published watch rows instead of silent passes.
- Generated secrets are rendered for proof, separated out of the published artifact, and verified present before and after install.
- Storage choices are base variants plus a StorageClass you provide; PVC binding is checked at runtime.
How does this differ from plain Helm?
With plain Helm you approve inputs - a values file - and find out later what they produced. Here you approve outputs:
- the exact rendered objects, proven equivalent to regular Helm for the same chart, values, and flag profile;
- named base variants instead of ad-hoc values drift, and derived variants for environment/region/customer changes that never re-render Helm;
- receipts at each boundary (render, upload, delivery, live observation), so "deployed" and "working" stay distinct claims;
- failures that surface as routed watch/blocked rows with a next action, instead of silent drift off the chart's supported path.
What plain Helm still does better today: anything in the needs-better-base-variant group - until someone builds and reviews the install shape you want, helm install with your own values is the more direct route, with the trade-offs above.
Where to look next
- Top-100 user-readiness summary - per-chart detail behind every claim here.
- Methodology and limits - how the groups are derived, and what they refuse to infer.
- Current proof status - the question-to-file evidence map.
- What we refuse to claim - why the blocked rows are the trust model.