This guide explains the journey from a public Helm chart to a ConfigHub Space. Use it when you want to know why this preset exists, what problem it solves, how to repeat it, and what still needs care.
It is generated from the same records that build the package, chart page, render intent, scripts, and receipts. The proof links are lower down.
Why this preset exists
Helm charts often expose many settings, but a values file alone does not tell the whole operations story. A team still needs to know what Kubernetes objects will be created, which Secrets or CRDs must already exist, whether hooks or setup jobs need special handling, and what evidence backs the result.
This preset is a named answer for one useful operating choice. It keeps the upstream chart, records the inputs and rendered YAML, and gives the team a repeatable starting point instead of a private values-file guess.
What this is
This is the ha-raft-ui preset config for hashicorp/vault@0.32.0. The repo also calls this a base variant. Use this when you want the reviewed high-availability shape instead of the simplest default.
The matching catalog page is hashicorp/vault@0.32.0.
The chart journey
We keep the Helm chart. We lock hashicorp/vault@0.32.0, choose the ha-raft-ui preset config, render it with the recorded values, namespace, release name, and Kubernetes capabilities, then save the output as files.
That captured output is the render variant: recipes/hashicorp/vault/0.32.0/revisions/ha-raft-ui/r001/rendered/release-objects.yaml. It contains 18 Kubernetes object(s): Service x6, ClusterRoleBinding x2, ServiceAccount x2, ClusterRole x1, ConfigMap x1, Deployment x1, MutatingWebhookConfiguration x1, PodDisruptionBudget x1.
The public package is oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/hashicorp-vault:0.32.0. Users can pull it without cloning this repo. When someone runs cub installer upload, ConfigHub stores the rendered Kubernetes YAML in a Space so it can be searched, compared, reviewed, changed, and delivered. The example script defaults to Space helm-vault-ha-raft-ui, but users can choose another name with CUB_SPACE=....
What to check
This preset config records 1 prerequisite: 1 other item. Follow the instructions below before you apply the rendered objects.
The catalog does not currently record a separate hook, setup job, or cleanup step for this preset.
For this preset, the main change from plain Helm is that the render inputs and output files are recorded before upload.
Why you can trust it
- The chart version, source, namespace, release name, values, and capability profile are recorded in the render intent.
- The render variant is committed as YAML and contains 18 Kubernetes object(s).
- The installer package OCI ref points to the package users pull for this chart version.
- Render parity is recorded as passing for this preset config.
- Prerequisites are named before apply, so they are not discovered after rollout.
This is a claim about this recorded preset config. It is not a claim that every possible values file for this chart has been checked.
Repeat it
Fast path with no ConfigHub account:
bash <(curl -fsSL https://confighub.github.io/helm-expt/site/sh/hashicorp-vault-0-32-0/ha-raft-ui/try.sh)Fast path with a ConfigHub account:
bash <(curl -fsSL https://confighub.github.io/helm-expt/site/sh/hashicorp-vault-0-32-0/ha-raft-ui/confighub.sh)The core render command is:
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.
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.
cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/hashicorp-vault:0.32.0 --base ha-raft-ui --work-dir ./hashicorp-vault-0-32-0-ha-raft-ui --non-interactive --namespace vaultAfter upload, create environment versions with cub variant create and move reviewed changes with cub variant promote. The walkthrough is After Upload: Create A Variant And Promote Changes.
Preset details
| Item | Value |
|---|---|
| Chart | hashicorp/vault@0.32.0 |
| Preset config | ha-raft-ui |
| Namespace | vault |
| Release name | vault |
| Values | recipes/hashicorp/vault/0.32.0/effective-values-ha-raft-ui.yaml |
| Render intent | data/helm-render-intents/intents/hashicorp-vault-0-32-0-ha-raft-ui.yaml |
| Render variant | recipes/hashicorp/vault/0.32.0/revisions/ha-raft-ui/r001/rendered/release-objects.yaml |
| Package base | packages/hashicorp/vault/0.32.0/bases/ha-raft-ui |
| Scripts | try.sh · confighub.sh |
Prerequisites and lifecycle steps
| When | What | How it is handled |
|---|---|---|
| Before install | ClusterFeature: minimum schedulable nodes 3 | use a target with at least 3 schedulable nodes before applying this base |
Evidence
| Check | Status |
|---|---|
| Render parity | yes |
| ConfigHub scan/upload proof | yes |
| Earlier local-cluster test | no |
| GitOps OCI live run | watch |
| Live Helm vs ConfigHub comparison | watch |
| Lifecycle routes | 0 |
Limits
- Local kind evidence is no for this preset config.
- GitOps OCI live evidence is watch for this preset config.
- Production support is target-scoped. Use production support decisions before claiming production readiness.
Source files
- Chart page: https://confighub.github.io/helm-expt/site/charts/hashicorp-vault-0-32-0.html
- Render intent:
data/helm-render-intents/intents/hashicorp-vault-0-32-0-ha-raft-ui.yaml - Rendered YAML:
recipes/hashicorp/vault/0.32.0/revisions/ha-raft-ui/r001/rendered/release-objects.yaml - Package source:
packages/hashicorp/vault/0.32.0/bases/ha-raft-ui - Generated scripts:
site/sh/hashicorp-vault-0-32-0/ha-raft-ui - Preset doctrine: Helm Chart Presets And Values