Detailed Redis walkthrough

Use the short Try page if you only want the first local package run.

Install cub and the installer plugin

The catalog commands use cub installer, a released open-source plugin. Install the cub CLI, install the plugin from its GitHub release, and make sure kustomize is available:

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 cub installation script puts the CLI at ~/.confighub/bin/cub. cub plugin install downloads the release for your operating system and architecture. If cub is already installed, run cub upgrade first. Upgrade the plugin separately with cub plugin upgrade installer. If kustomize version fails, use the official kustomize installation instructions; Go is not required to install cub installer. If you installed an early source build with no recorded source, run cub plugin uninstall installer once, then repeat the install command above. Full cub setup notes are in the ConfigHub docs.

The catalog paths on this page run on your laptop and need no sign-in anywhere.

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.

The fastest first run

Five steps take you through the first run. They render the recommended Redis configuration and create its required Secret separately. They then apply the files to a throwaway cluster and show you what the cluster received.

# 1. Install cub and its installer plugin once
# Use the install block immediately above.
cub installer version

# 2. A throwaway cluster (needs Docker; skip if you already have one)
kind create cluster

# 3. Render Redis without putting a password in the files, then install it
bash <(curl -fsSL https://confighub.github.io/helm-expt/site/sh/bitnami-redis-25-5-3/reuse-existing-secret/try.sh)

# 4. It is running
kubectl -n redis get pods

# 5. It is all files you can read; this one is what the cluster received
cat ./bitnami-redis-25-5-3-reuse-existing-secret/out/manifests/configmap-redis-redis-configuration.yaml

The script says what it does at every step. It generates a fresh password locally, creates redis-existing-secret in the throwaway cluster, and keeps that password out of the rendered package files. Every chart page links its own try.sh; base variants that need target resources name them instead of guessing. Clean up with kind delete cluster. The longer path below shows the same process next to plain Helm.

1 · Pull, inspect, and verify Redis

Start without a cluster. Pull the public Redis package, select the existing-Secret configuration, write the Kubernetes files, and write the same non-secret objects as a local OCI image layout.

reuse-existing-secret is a base variant: a reviewed way to use the chart with its Helm inputs, rendered output, checks, and required Secret recorded together.

# No ConfigHub account, Google registry login, or Kubernetes cluster.
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 \
    --non-interactive --namespace redis \
    --output-oci ./redis-25.oci

# Read the files before deciding whether to deploy.
ls ./redis/out/manifests
cat ./redis/out/spec/selection.yaml

The command writes 14 Kubernetes objects and no Secret. The password remains outside the files and OCI. The output ends with pull-back: verified because cub reads the OCI back and compares its object-set digest before reporting success.

Open the full rendered Redis YAML, the recorded Helm inputs and prerequisites, or the anonymous 25.5.3 to 27.0.0 walkthrough proof.

Install only after you have read it

If you want a live test, use a throwaway cluster. The generated script creates a fresh password in a separate Kubernetes Secret. It applies the 14 files, waits for Redis, and tells you how to remove the cluster afterward.

kind create cluster
bash <(curl -fsSL https://confighub.github.io/helm-expt/site/sh/bitnami-redis-25-5-3/reuse-existing-secret/try.sh)

The live parity proof ran normal Helm and this cub path on a clean cluster. The 13 chart objects matched field for field, cub added the explicit Namespace, and both Redis installations became ready and answered PING.

Helm combines render and install. cub separates them.

2 · Upgrade the same Redis configuration

Now move the same work directory from Redis chart 25.5.3 to 27.0.0. With no account, cub can retain the package selection and inputs it knows about. The recorded ConfigHub proof also checks one specific post-render change: a replica count that the newer base does not change.

# Re-enter the same work directory with the newer public package.
cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/bitnami-redis:27.0.0@sha256:d38f3fecadcc4c4cb26d9fb6c1fc58402c7dfa1cf08673afe7b00041c7614ae6 \
    --work-dir ./redis --reuse --non-interactive --namespace redis \
    --output-oci ./redis-27.oci

cat ./redis/out/spec/selection.yaml
# base: reuse-existing-secret

# Record the 25.5.3 objects.
cub installer upload --work-dir ./redis --space my-redis \
    --component redis-upgrade --variant base

# Record one exact change in ConfigHub: two Redis replicas.
cub k8s get sts --space my-redis
cub run set-replicas --space my-redis \
    --unit <replica-statefulset-unit> --replicas 2 \
    --change-desc "Keep two Redis replicas through chart upgrades" --wait

# Pull 27.0.0. setup reads upload.yaml; plan shows the comparison.
cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/bitnami-redis:27.0.0@sha256:d38f3fecadcc4c4cb26d9fb6c1fc58402c7dfa1cf08673afe7b00041c7614ae6 \
    --work-dir ./redis --reuse --non-interactive --namespace redis
cub installer plan --work-dir ./redis
cub installer upload --work-dir ./redis --yes

What the managed run did after the upgrade

The Redis upgrade and rollback proof continued the same example. It identified development and staging as the affected environments and promoted them in order. It published one reviewed OCI and reconciled that digest on two Argo CD clusters. Both Redis installations became ready and answered PONG. It then restored the exact pre-upgrade revisions, published a rollback OCI, and verified both clusters again.

The proof also records its limits. The promotion dry run produced no readable mutation output. The portable OCI used a temporary registry. The rollback restored desired Kubernetes objects, not database data.

3 · See why the Redis base matters

The Redis default catalog base is retained as an explicit static-password demonstration. Its rendered YAML contains credential material, so the chart page warns against treating it as a production default. The recommended reuse-existing-secret base used above contains no Secret object and names the Secret that must exist at delivery time.

# Compare the two choices without touching a cluster.
cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/bitnami-redis:25.5.3@sha256:a216ce212424e05b341ef5000f1798e6014b72b8bc3dce9f315285871037af2a \
    --base default --work-dir ./redis-static \
    --non-interactive --namespace redis
grep -R "kind: Secret" ./redis-static/out/manifests

grep -R "kind: Secret" ./redis/out/manifests
# no match: reuse-existing-secret keeps the credential outside the files

This is the sort of choice the catalog records for people and agents. It does not pretend that every chart has one universal answer. For another common case, take a chart and values file produced by AI and review the exact rendered objects before applying them.

4 · Already on Argo or Flux? Write OCI directly

If your cluster pulls from an OCI registry, give --output-oci a registry reference instead of a local path. The installer pushes the same 14 non-secret Redis objects you inspected. It records the source package and selected base. It then reads the artifact back and verifies its object-set digest. Registry write access is the only additional requirement.

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 \
    --non-interactive --namespace redis \
    --output-oci oci://<your-registry>/redis:v1

The live no-account NGINX proof runs this exact installer output path against a temporary registry. Flux reconciled the recorded output digest and the Deployment reached its desired replica count.

What we checked

The Redis steps above are backed by separate receipts. A render check does not stand in for a Kubernetes run, an OCI delivery, or an upgrade test.

Check it yourself

The first command checks the committed receipt. The second repeats the public no-account run against the current registry packages. Neither command touches Kubernetes.

npm run redis-public-walkthrough:verify
npm run redis-public-walkthrough:run

The Verification page lets you run the checks yourself, read the evidence we've recorded, or start a fresh live test.

New to ConfigHub? Follow the official ConfigHub tutorial. It covers one component, a release, a change, production, and promotion. This site provides the public catalog and its evidence.

Try the public Redis walkthrough first. When you are ready to use your own example, bring a chart and values file that you or an AI produced. The bring-your-own path renders it, reports exact object and field findings, keeps the changes you actually wanted, and builds a reviewed OCI.

Deployment · Redis chart page · Check my config · The demo org · Open verification