See what the GPU Operator Helm chart becomes

1. See what you have today

You have the chart and its default values. Helm renders them like this, and the Workshop's check reads the result.

before: plain helm template

$ helm template gpu-operator gpu-operator --repo https://helm.ngc.nvidia.com/nvidia --version v26.3.3 --namespace gpu-operator > before.yaml
$ cub config check before.yaml
Config: before
Inspecting local Kubernetes objects (static, no infrastructure)

Installs
  27 objects: 1 ClusterPolicy, 5 ClusterRole, 5 ClusterRoleBinding, 2 ConfigMap, 1 DaemonSet, 3 Deployment, 2 Job, 2 Role, 2 RoleBinding, 4 ServiceAccount
  namespaces that must already exist: gpu-operator

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

Schema
  [PASS] schema validation: 27 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 8 hook objects sit in the same file as everything else. Apply the file and they run at install time. The post-delete Job would remove node-feature-discovery labels from every node straight away.

Kind	Name	Helm hook
ServiceAccount	`gpu-operator-node-feature-discovery-prune`	post-delete
ServiceAccount	`gpu-operator-upgrade-crd-hook-sa`	pre-upgrade
ClusterRole	`gpu-operator-node-feature-discovery-prune`	post-delete
ClusterRole	`gpu-operator-upgrade-crd-hook-role`	pre-upgrade
ClusterRoleBinding	`gpu-operator-node-feature-discovery-prune`	post-delete
ClusterRoleBinding	`gpu-operator-upgrade-crd-hook-binding`	pre-upgrade
Job	`gpu-operator-node-feature-discovery-prune`	post-delete
Job	`gpu-operator-upgrade-crd`	pre-upgrade

The file holds no CRDs. Helm installs the chart's 5 CRDs on the first install only, and never upgrades them.

2. See what the Workshop gives you

The Catalog flattened the same chart into an OCI bundle, pinned by its digest. It holds the objects, and a plan for everything that is not an object to apply.

after: the Catalog's bundle

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

Installs
  24 objects: 1 ClusterPolicy, 3 ClusterRole, 3 ClusterRoleBinding, 2 ConfigMap, 5 CustomResourceDefinition, 1 DaemonSet, 3 Deployment, 2 Role, 2 RoleBinding, 2 ServiceAccount
  namespaces that must already exist: gpu-operator

Lifecycle work
  [NOTE] CRDs: 5 (apply and establish before any custom resource)
  [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: 24 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 4 steps.

Step	What it does
Apply 1	the 5 CRDs, then wait until each is Established
Apply 2	the other 19 objects
pre-upgrade	Before an upgrade, move the CRDs to the new version. The plan names the hook objects in the signed package and never applies them with the base.
post-delete	After deleting, prune node-feature-discovery labels from the nodes. The plan names the hook objects in the signed package and never applies them with the base.

3. See what changed

	Before, helm template	After, the bundle
Objects	27	24
Helm hook objects in the file	8	0, named in the plan
CRDs	0, installed once by helm install	5, applied first
Other objects	19	19

The 19 other objects are the same on both sides, so the difference is the work Helm does out of sight.

4. Try it yourself, with no account

Install cub and the Workshop plugin first.

# before: render the chart as Helm does
$ helm template gpu-operator gpu-operator --repo https://helm.ngc.nvidia.com/nvidia --version v26.3.3 --namespace gpu-operator > before.yaml

$ cub config check before.yaml

# after: fetch the objects the bundle holds
$ curl -fsSL -o after.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.3.3/revisions/default/r001/rendered/release-objects.yaml

$ cub config check after.yaml

The bundle itself is oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/bundles/catalog-nvidia-gpu-operator-v26-3-3-default:r001@sha256:408cfa607e699388f62c1859f3f0daeecc99b8110f8cee076f06855be2d8ea1e, and its entry page shows the plan.

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/nvidia-gpu-operator:v26.3.3@sha256:abd8475d6bfeabe88acc2d6a319a04054a9e84046d69926dcee4717674329a8f --base default --work-dir ./nvidia-gpu-operator-v26-3-3-default --non-interactive --namespace gpu-operator

# 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 ./nvidia-gpu-operator-v26-3-3-default --space <your-space> --component <your-component>

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

These are the commands on the entry page. The screenshot below shows one run of them. The Catalog's own record for this entry still holds no upload.

What it looks like in ConfigHub

ConfigHub showing the GPU Operator Deployment, at its image line — The helm-catalog organization on 2026-10-25, showing the GPU Operator 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.
No step of the plan has been run on a cluster. The plan says what a delivery workflow must do, and nothing runs it automatically.
This is the chart's default base. Other bases of the same version are on the entry page.