bitnami/redis

Three ways this page helps you test

The same three things hold for every package in the catalog, Helm charts and OCI packages alike. Why this makes configuration easier to test.

What To Use

reuse-existing-secret base variant: 13 rendered objects · 1 image · 0 lifecycle routes · 5/5 proof lanes passing. Every number is extracted from committed data.

Use the public catalog entry, then check the exact base and lane before making a production claim.

Where This Chart's Settings Come From

Helm values define each base render. ConfigHub changes begin after upload and are recorded against the rendered objects. Secrets, CRDs, hooks, and setup jobs are listed separately because they are install work, not hidden settings. Live cluster state is observed separately and does not silently become the desired configuration.

Upgrade rule: if a new Helm render and a ConfigHub revision both change the same field, review the overlap before promotion. The values profile shows the Helm side; Unit revision history shows the ConfigHub side.

Read the full values-versus-ConfigHub rule.

What A Base Variant Records

A base variant solves the first Helm problem: which chart inputs should we use, and what Kubernetes objects do they produce? Each base variant records the Helm chart version, values profile, namespace, release name, capability profile, source lock, generated output, and evidence lanes.

The reuse-existing-secret base-variant record joins those Helm facts to the literal objects, remaining target inputs, hooks and CRDs, apply policy, and OCI handoffs. It is the short record to open when you need the whole base rather than only its rendered YAML.

Open the full rendered YAML to read the actual manifest output. Then use the render intent, receipts, and chart-extras section to see the inputs, checks, and CRD/hook/setup decisions around it.

If your values file creates a new useful operating shape, it should become another base variant with its own recorded inputs and checks. If it only changes an already-rendered field after upload, it belongs in a derived ConfigHub variant that can be reviewed and kept through upgrades.

How render intents work · All generated render intents · All base variant records

How To Try This Chart

Start with reuse-existing-secret unless a card below explains that another base variant is a better first path. If a card says review or preparation is needed, treat that as a real limit rather than a ready install.

cub installer setup ...
rendered manifests written under <work-dir>
use the chart option cards below to check pass, watch, blocked, and prerequisites

Redis Proof Slice

Redis is a compact example of a decision that matters before install. The chart's normal default renders password material. The catalog recommends reuse-existing-secret, which records the Secret name and key but keeps the password out of the rendered files and OCI.

kubectl create namespace redis
kubectl -n redis create secret generic redis-existing-secret \
  --from-literal=redis-password="$(openssl rand -base64 32)"
helm install redis oci://registry-1.docker.io/bitnamicharts/redis \
  --version 25.5.3 --namespace redis \
  --set auth.existingSecret=redis-existing-secret \
  --set auth.existingSecretPasswordKey=redis-password \
  --set image.digest=sha256:6e7a020f1f6504698a7272c58783bdc2c23588c49febbae5aca1bb8dfa10af25

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-reviewed \
  --non-interactive --namespace redis \
  --output-oci ./redis-rendered.oci

cub installer upload --work-dir ./redis-reviewed \
  --space helm-redis-reviewed

See the 13/13 live Helm comparison · Open Get Started · Expected results and clusters

Base Variants And Options

Each card is one available way to use this chart in the catalog. Some cards are runnable base variants. Others are candidate paths, derived variants, or review notes that explain what still has to be prepared.

Check labels: R = render parity, C = ConfigHub proof, L = local cluster, Y = lifecycle actions, G = GitOps/OCI, P = live Helm-vs-ConfigHub parity, K = two-cluster kind parity, V = variant promotion.

5 matrix rows for bitnami/redis@25.5.3 · open the full matrix

Images This Chart Pulls

Every reference below comes from the reviewed rendered output. What you see is what the cluster pulls. These references are data: you can change a registry or pin a digest with a recorded edit, and prove the change landed in every environment.

First-Run Caveats

Some chart paths need a small preparation step before the cub path feels as smooth as Helm. We show those steps here so the first run does not surprise you.

Open the all-chart adoption caveats · Helm to cub migration · cub deployment path

Operator Playbooks And Fact Sheet

This is the quick route for a human or agent: which operating playbook applies, what the current user-facing answer is, and what the next proof or product action would add.

The source data lives in chart skills and chart evidence router.

Proof Lanes

Each lane proves a different outcome. Missing or non-pass rows are backlog or target-fit evidence; they do not change the render-parity result.

How much is proven, and what more testing would add: Fully proven: Render parity, ConfigHub proof, Local live, GitOps/OCI live, Live Helm-vs-ConfigHub. Not yet tested: Two-cluster kind - a fresh cluster run would prove these.

Quirks And Inputs

exact rendered objects with render parity and receipts; generated Secrets separated out of the published artifact; install-vs-upgrade render divergence captured per revision; cluster lookups lifted into declared target facts

Hooks, CRDs, And Setup Work

Some Helm charts need work before, during, or after apply: CRDs, hooks, setup jobs, webhook certificates, migrations, generated Secrets, or checks. For each chart, the catalog should make the choice clear: include it in the base variant, split it into a separate base variant, run a setup step, use a GitOps action where evidence exists, require an existing target resource, or block it when there is no safe default.

What each base needs before apply

These requirements come from the same base definition as the rendered objects. The render intent keeps the chart inputs, required Secrets or CRDs, lifecycle routes, and evidence together.

If no route is shown, that does not prove the upstream chart has no hooks. It means the public catalog has no chart-specific action to show yet; check the matrix or send a problem chart if hook behavior should be modeled. Direct apply, Argo CD, Flux, and upgrade implementations are tracked separately. One passing implementation does not prove the others.

Production Boundary

A green render or local live result is not a production support claim. Production support is target-scoped and uses the support-decision artifact when present.

Files To Inspect