Skip to content
Browse the site

Deep Dives

AI: Claude and Codex patterns

ConfigHub: Deploy and manage

Configs
Stacks
Apps
Plugins
Guides
Docs

Before and after

See what the External Secrets Helm chart becomes

The 44 objects are the same on both sides. What the Workshop adds is the plan: 2 steps that the objects alone do not say.

What you need. helm, curl and cub with the Workshop plugin. No account and no cluster.

1. See what you have today

You have the External Secrets chart 2.8.0 with the values of the Catalog's default base, which are the chart's defaults. Helm renders it like this, and the Workshop's check reads the result.

before: plain helm template
$ helm template external-secrets external-secrets --repo https://charts.external-secrets.io --version 2.8.0 --namespace external-secrets --kube-version 1.30.0 > before.yaml
$ cub config check before.yaml
Config: before
Inspecting local Kubernetes objects (static, no infrastructure)

Installs
  44 objects: 5 ClusterRole, 2 ClusterRoleBinding, 25 CustomResourceDefinition, 3 Deployment, 1 Role, 1 RoleBinding, 1 Secret, 1 Service, 3 ServiceAccount, 2 ValidatingWebhookConfiguration
  namespaces that must already exist: external-secrets

Lifecycle work
  [NOTE] CRDs: 25 (apply and establish before any custom resource)
  [PASS] Helm hooks: 0
  [PASS] setup Jobs: 0
  [NOTE] admission webhooks needing a certificate: 2
  [PASS] images tagged latest or not tagged: 0

Schema
  [PASS] schema validation: 44 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.

2. See what the Workshop gives you

The Catalog keeps the objects of its default base for this chart, and a plan for everything that is not an object to apply.

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

Installs
  44 objects: 5 ClusterRole, 2 ClusterRoleBinding, 25 CustomResourceDefinition, 3 Deployment, 1 Role, 1 RoleBinding, 1 Secret, 1 Service, 3 ServiceAccount, 2 ValidatingWebhookConfiguration
  namespaces that must already exist: external-secrets

Lifecycle work
  [NOTE] CRDs: 25 (apply and establish before any custom resource)
  [PASS] Helm hooks: 0
  [PASS] setup Jobs: 0
  [NOTE] admission webhooks needing a certificate: 2
  [PASS] images tagged latest or not tagged: 0

Schema
  [PASS] schema validation: 44 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 2 steps.

StepWhat it isWhat it says
external-secrets/external-secrets-webhookmust exist on the targetRendered webhook Secret separated by installer and populated by the cert-controller after apply
crd-orderinga step of the applyWithout an ordering declaration, per-file Units apply in no guaranteed order, so a custom resource can reach the cluster before the definition that gives it meaning. Apply the 25 CustomResourceDefinition objects first. Wait until every named definition reports the Established condition. Then apply the other 19 objects.

3. See what changed

Before, helm templateAfter, the default base
Objects4444
Helm hook objects in the file00
CRDs2525
Objects that are the same on both sides4444
Plan stepsnone2

4. Try it yourself, with no account

Install cub and the Workshop plugin first.

# before: render the chart as Helm does
$ helm template external-secrets external-secrets --repo https://charts.external-secrets.io --version 2.8.0 --namespace external-secrets --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/external-secrets/external-secrets/2.8.0/revisions/default/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/external-secrets-external-secrets:2.8.0@sha256:3d807ceebf3de0146dddfa1de3b024139f5fac3869877a2a57ddd1d9550f228c --base default --work-dir ./external-secrets-external-secrets-2-8-0-default --non-interactive --namespace external-secrets

# 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 ./external-secrets-external-secrets-2-8-0-default --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 External Secrets Deployment, at its image line
The helm-catalog organization on 2026-10-25, showing the External Secrets Deployment, 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.