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

External Secrets, before and after

A Helm chart you can't read becomes objects you can.

Before and after

Before: the Helm chart
          {{- with .Values.securityContext }}
          {{- if and (.enabled) (gt (keys . | len) 1) }}
          securityContext:
            {{- include "external-secrets.renderSecurityContext" (dict "securityContext" . "context" $) | nindent 12 }}
          {{- end }}
          {{- end }}
          image: {{ include "external-secrets.image" (dict "chartAppVersion" .Chart.AppVersion "image" .Values.image "context" .) | trim }}
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          args:
          {{- if .Values.leaderElect }}
          - --enable-leader-election=true
          {{- end }}
          {{- if .Values.leaderElectionID }}
          - --leader-election-id={{ .Values.leaderElectionID }}
          {{- end }}
          {{- if .Values.leaderElectionLeaseDuration }}

16 lines of templates/deployment.yaml, around its image line. The chart has many files like this.

After: in ConfigHub
ConfigHub showing the External Secrets Deployment, at its image line

The same image line in ConfigHub, as a plain value. Taken in the helm-catalog organization on 2026-10-25, showing the External Secrets Deployment, at its image line.

ConfigHub holds this as 45 Units, one for each of the 44 objects the installer writes and one installer record.

In ConfigHub: one base, and a variant for each environment
ConfigHub showing the External Secrets base with its dev and prod variants, and the label and three replicas prod sets on the controller

Prod's panel lists what prod changes from the base, here its label and three replicas of the controller. Taken in the helm-catalog organization on 2026-10-26, showing the External Secrets base with its dev and prod variants, and the label and three replicas prod sets on the controller.

  • The template's image line becomes one plain value you can read, and so does every other field.
  • Every object is written out, so you can review it before anything runs.

What Helm does that you never see, and what happens here instead

What Helm doesWhat happens here instead
Adds 25 new kinds of Kubernetes object, such as ExternalSecret, SecretStore, ClusterSecretStore.They are in ConfigHub with everything else, and they go in first, so the objects that use them are not rejected.
Show meConfigHub showing the External Secrets CRDs among the base's Units

The 25 new kinds

  • ACRAccessToken
  • BeyondtrustWorkloadCredentialsDynamicSecret
  • CloudsmithAccessToken
  • ClusterExternalSecret
  • ClusterGenerator
  • ClusterPushSecret
  • ClusterSecretStore
  • ECRAuthorizationToken
  • ExternalSecret
  • Fake
  • GCRAccessToken
  • GeneratorState
  • GithubAccessToken
  • GitlabDeployToken
  • Grafana
  • MFA
  • Password
  • PushSecret
  • QuayAccessToken
  • SecretStore
  • SSHKey
  • STSSessionToken
  • UUID
  • VaultDynamicSecret
  • Webhook
Ships the webhook's certificate Secret empty.ConfigHub holds it empty too. The cert-controller fills in external-secrets/external-secrets-webhook on the cluster after apply.

ConfigHub keeps configuration as plain objects, with a history of every change. Loading puts this chart's objects in a Space, a folder in your ConfigHub organization.

Load it into your ConfigHub

Sign in with the first line, then paste the rest. It fetches the External Secrets package, writes its files, and saves them as a Space called external-secrets-example in your organization. The rest makes a dev and a prod variant of it, and prod runs three replicas of the controller. It touches no cluster.

$ cub auth login

$ 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-example --non-interactive --namespace external-secrets && cub installer upload --work-dir ./external-secrets-example --space external-secrets-example && cub component create external-secrets-example && cub space update --patch external-secrets-example --component external-secrets-example

$ cub variant create dev external-secrets-example --change-desc "Clone the base as dev"

$ cub variant create prod external-secrets-example --change-desc "Clone the base as prod"

$ cub function set --space external-secrets-example-dev --change-desc "Label every object environment dev" set-label environment dev

$ cub function set --space external-secrets-example-prod --change-desc "Label every object environment prod" set-label environment prod

$ cub function set --space external-secrets-example-prod --unit deployment-external-secrets-external-secrets --change-desc "Run three replicas in prod" set-replicas 3

You need a ConfigHub account and cub with its installer plugin and kustomize.

Try it on your laptop

No account needed. This fetches the External Secrets package and writes every object into a folder you can open. To check your own chart and values instead, see Is my configuration right?

$ 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-example --non-interactive --namespace external-secrets && ls ./external-secrets-example/out/manifests

You need cub with its installer plugin and kustomize.

Show me the details (for experienced users)