Helm or cub installer?
Redis is the smallest example on this site, which makes it the clearest place to compare a normal Helm install with the cub installer path.
| Path | Use it when | What you need |
|---|---|---|
| Normal Helm | You want Helm to deploy Redis directly into a Kubernetes cluster. | A Kubernetes cluster. |
cub installer | You want Redis rendered into explicit local config first, so you can inspect it, keep it as OCI, or manage it before delivery. | No cluster or ConfigHub account for the render or the local OCI output. |
Redis answers one question: does the ConfigHub path start from the same Kubernetes objects Helm would create?
| Question | Answer |
|---|---|
| Does this replace Helm? | No. Helm remains the source chart ecosystem and the control path. |
Does cub installer deploy the app? | Not by itself. It renders a reviewed package into explicit config first. |
| Can it write the rendered result as OCI? | Yes, with --output-oci. The output holds the selected preset's non-secret objects, source record, and checks. |
| Do I need ConfigHub for this first step? | No. ConfigHub comes later, for Units, variants, approvals, OCI delivery, observations, and operations. |
1. Install cub and the package plugin
Install the ConfigHub CLI. Then install the plugin that reads catalog packages.
curl -fsSL https://hub.confighub.com/cub/install.sh | bash
export PATH="$HOME/.confighub/bin:$PATH"
cub plugin install confighub/installer
cub installer version
kustomize version
The plugin release contains the program for your operating system. You do not need Go.
If cub is already installed, run cub upgrade first. Upgrade the plugin separately with cub plugin upgrade installer.
If kustomize version fails, follow the official Kustomize installation instructions.
Here is what the command does. cub installer is an open-source plugin for the cub CLI. cub installer setup pulls a catalog package and writes its Kubernetes files locally, leaving delivery to kubectl, Argo CD or Flux. The generated scripts stop before doing any work when the plugin or kustomize is missing.
2. Render the Redis package
The public package contains named Redis configurations. Select the configuration that expects you to provide a Kubernetes Secret before deployment.
Input: a Catalog installer OCI, pinned to the manifest digest in its publication receipt.
Output: readable Kubernetes files plus a local configuration OCI at ./redis-25.oci.
cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/bitnami-redis:25.5.3@sha256:a216ce212424e05b341ef5000f1798e6014b72b8bc3dce9f315285871037af2a \
--base reuse-existing-secret \
--work-dir ./redis \
--namespace redis \
--non-interactive \
--output-oci ./redis-25.oci
The chart renders 13 objects. cub installer adds one explicit Namespace, so the output contains 14 manifest files and no Secret. It also writes a local OCI package.
The command reads the OCI package back and checks that none of the objects changed. It reports pull-back: verified when the comparison passes.
Before deployment: create the required redis-existing-secret Secret in the target namespace. The Catalog records this requirement, and you create the credential yourself.
3. Inspect the result
Read the selected configuration and its objects. Everything so far is local.
cat ./redis/out/spec/selection.yaml
ls ./redis/out/manifests
grep -R "^kind:" ./redis/out/manifests
The catalog keeps the source inputs beside the result. It also records the required Secret and the checks for this configuration.
This Redis configuration has no CRD setup step. For a chart that lists CRDs, do not rely on one plain kubectl apply.
Run the package's prerequisite script, or use its tested Argo CD or Flux route. The CRDs must be established before dependent objects are applied.
Read the full Kubernetes YAML · Read the recorded inputs and requirements · Read the anonymous run result
You have finished the first example
You now have readable Kubernetes files and a local OCI package. Nothing has been applied to a cluster.
Local files work with kubectl alone. Keep them, test them, apply them with kubectl, or commit them to Git.
Next: choose how to deploy the reviewed result.
For your own Helm values or an unexpected result, check your configuration with your AI assistant.
Other paths: choose a Helm, AICR, OCI, YAML, promotion, or fleet example, or continue the detailed Redis walkthrough. Before promoting an upgrade, check it against the next environment, or keep the result in ConfigHub.