A Helm chart you can't read becomes objects you can.
Before and after
Before: the Helm chart
containers:
- name: metrics-server
{{- with .Values.securityContext }}
securityContext:
{{- toYaml . | nindent 12 }}{{- end }}
image: {{ include "metrics-server.image" . }}
imagePullPolicy: {{ .Values.image.pullPolicy }}
args:
- {{ printf "--secure-port=%d" (int .Values.containerPort) }}{{- range .Values.defaultArgs }}
- {{ . }}{{- end }}{{- if .Values.metrics.enabled }}
- --authorization-always-allow-paths=/metrics
{{- end }}
16 lines of templates/deployment.yaml, around its image line. The chart has many files like this.
After: in ConfigHub
The same image line in ConfigHub, as a plain value. Taken in the helm-catalog organization on 2026-10-25, showing the metrics-server Deployment, at its image line.
ConfigHub holds this as 11 Units, one for each of the 10 objects the installer writes and one installer record.
In ConfigHub: one base, and a variant for each environment
Prod's panel lists what prod changes from the base, here its label and three replicas of its Deployment. Taken in the helm-catalog organization on 2026-10-26, showing the metrics-server base with its dev and prod variants, and the label and three replicas prod sets on its Deployment.
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 does
What happens here instead
Nothing out of sight. The chart makes 9 objects and runs no hooks.
All 9 are in ConfigHub as they are.
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 metrics-server package, writes its files, and saves them as a Space called metrics-server-example in your organization. The rest makes a dev and a prod variant of it, and prod runs three replicas of its Deployment. It touches no cluster.
$ cub auth login
$ cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/metrics-server-metrics-server:3.14.0@sha256:806f198aca52dc7db180a04354dd7895873cad5c1811a45532d7e27077e3a0a3 --base default --work-dir ./metrics-server-example --non-interactive --namespace kube-system && cub installer upload --work-dir ./metrics-server-example --space metrics-server-example && cub component create metrics-server-example && cub space update --patch metrics-server-example --component metrics-server-example
$ cub variant create dev metrics-server-example --change-desc "Clone the base as dev"
$ cub variant create prod metrics-server-example --change-desc "Clone the base as prod"
$ cub function set --space metrics-server-example-dev --change-desc "Label every object environment dev" set-label environment dev
$ cub function set --space metrics-server-example-prod --change-desc "Label every object environment prod" set-label environment prod
$ cub function set --space metrics-server-example-prod --unit deployment-kube-system-metrics-server --change-desc "Run three replicas in prod" set-replicas 3
No account needed. This fetches the metrics-server package and writes every object into a folder you can open. To check your own chart and values instead, see Is my configuration right?
