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 kustomize version fails, use the official kustomize installation instructions; Go is not required to install cub installer. For a later release, run cub plugin upgrade 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.

No ConfigHub account is needed for the catalog paths on this page.

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.

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 \
    --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. With ConfigHub, it can also retain a reviewed edit made directly to a Kubernetes object.

# 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 \
    --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

# Change the rendered replica StatefulSet from 3 replicas to 2.
$ edit ./redis/out/manifests/statefulset-redis-redis-replicas.yaml
$ cub installer plan --work-dir ./redis
$ cub installer upload --work-dir ./redis --yes

# Pull 27.0.0. setup reads upload.yaml; upload performs the merge.
$ cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/bitnami-redis:27.0.0 \
    --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 \
    --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 \
    --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 so one passing lane is not made to prove everything.

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