See what the Bitnami PostgreSQL Helm chart becomes

1. See what you have today

You have the Bitnami PostgreSQL chart 18.7.0 and its own defaults, which is how most people start. Helm renders it like this, and the Workshop's check reads the result.

before: plain helm template

$ helm template postgresql postgresql --repo https://charts.bitnami.com/bitnami --version 18.7.0 --namespace postgresql --kube-version 1.30.0 > before.yaml
$ cub config check before.yaml
Config: before
Inspecting local Kubernetes objects (static, no infrastructure)

Installs
  7 objects: 1 NetworkPolicy, 1 PodDisruptionBudget, 1 Secret, 2 Service, 1 ServiceAccount, 1 StatefulSet
  namespaces that must already exist: postgresql

Lifecycle work
  [PASS] CRDs: 0
  [PASS] Helm hooks: 0
  [PASS] setup Jobs: 0
  [PASS] admission webhooks needing a certificate: 0
  [NOTE] images tagged latest or not tagged: 1 (registry-1.docker.io/bitnami/postgresql:latest). The same name can pull different bytes later

Schema
  [PASS] schema validation: 7 object(s) valid against the default and ecosystem catalogs (flux-schema/0.16.0)

  Free look before you install. Compose it into a cub stack, or run it as a cub app.

Render it a second time and compare the two.

before: the same chart, rendered twice

$ helm template postgresql postgresql --repo https://charts.bitnami.com/bitnami --version 18.7.0 --namespace postgresql --kube-version 1.30.0 > before-again.yaml
$ cub config diff before.yaml before-again.yaml --summary
Configuration diff: 0 added, 0 removed, 1 changed, 6 unchanged
Kind summary (inventory only):

One field changed between the two renders: data.postgres-password on Secret/postgresql. Apply the second render and the Secret no longer holds the password the database was first set up with.

2. See what the Workshop gives you

The Catalog keeps the objects of its existing-secret base for this chart, rendered with these values, and a plan for everything that is not an object to apply.

after: the existing-secret base

$ cub config check after.yaml
Config: after
Inspecting local Kubernetes objects (static, no infrastructure)

Installs
  6 objects: 1 NetworkPolicy, 1 PodDisruptionBudget, 2 Service, 1 ServiceAccount, 1 StatefulSet
  namespaces that must already exist: postgresql

Lifecycle work
  [PASS] CRDs: 0
  [PASS] Helm hooks: 0
  [PASS] setup Jobs: 0
  [PASS] admission webhooks needing a certificate: 0
  [PASS] images tagged latest or not tagged: 0

Schema
  [PASS] schema validation: 6 object(s) valid against the default and ecosystem catalogs (flux-schema/0.16.0)

  Free look before you install. Compose it into a cub stack, or run it as a cub app.

The plan has 1 step.

Step	What it is	What it says
`postgresql/postgresql-auth`	must exist on the target	PostgreSQL administrator password

3. See what changed

	Before, helm template	After, the existing-secret base
Objects	7	6
Helm hook objects in the file	0	0
CRDs	0	0
A Secret with a generated password	yes, new on every render	no
Images on a moving tag	yes, :latest	no, pinned by digest
Objects that are the same on both sides	5	5
Plan steps	none	1

These are the fields that differ in the objects both sides hold. The chart's default image is the moving tag registry-1.docker.io/bitnami/postgresql:latest, and the base pins it by digest, so it pulls the same bytes every time. The base's pods read the Secret you create.

Object	Field	Before	After
StatefulSet postgresql	`spec.template.spec.containers[0].image`	`registry-1.docker.io/bitnami/postgresql:latest`	`registry-1.docker.io/bitnami/postgresql@sha256:2d3c068e58...`
StatefulSet postgresql	`spec.template.spec.volumes[1].secret.secretName`	`postgresql`	`postgresql-auth`

4. Try it yourself, with no account

Install cub and the Workshop plugin first.

# before: render the chart as Helm does
$ helm template postgresql postgresql --repo https://charts.bitnami.com/bitnami --version 18.7.0 --namespace postgresql --kube-version 1.30.0 > before.yaml

$ cub config check before.yaml

# after: fetch the objects the Catalog keeps for this base
$ curl -fsSL -o after.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/bitnami/postgresql/18.7.0/revisions/existing-secret/r001/rendered/release-objects.yaml

$ cub config check after.yaml

The entry page shows the plan and every other base of this chart.

See it live in ConfigHub

Everything above runs on your own machine with no account. To see the same example in ConfigHub, load it into your own organization with the commands below.

With your own account

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.

# render the base from the signed package
$ cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/bitnami-postgresql:18.7.0@sha256:cf2cfeae128c4ede5cfa9ac65bdf241b557d59a1badacdd107e044caadb0d353 --base existing-secret --work-dir ./bitnami-postgresql-18-7-0-existing-secret --non-interactive --namespace postgresql

# sign in to your organization
$ cub auth login

# load the objects as a Space of Units, under names you choose
$ cub installer upload --work-dir ./bitnami-postgresql-18-7-0-existing-secret --space <your-space> --component <your-component>

# list what was loaded
$ cub unit list --space <your-space>

What it looks like in ConfigHub

ConfigHub showing the PostgreSQL StatefulSet, at its image line — The helm-catalog organization on 2026-10-25, showing the PostgreSQL StatefulSet, at its image line. It was loaded as this panel describes.

5. Technical notes and disclaimers

Both checks ran on 2026-10-26 with cub v0.9.0, Workshop plugin 0.6.61 and helm v4.1.4+g05fa379. The recorded files and their receipt hold every input and output on this page.
Both sides render for Kubernetes 1.30.0, as the Catalog does, so only the handling differs.
No step of the plan has been run on a cluster for this page. The plan says what a delivery workflow must do, and nothing runs it automatically.