nvidia/gpu-operator v25.10.1 retained package

What it is. nvidia/gpu-operator v25.10.1, as 24 Kubernetes objects in its default preset. The Catalog holds 6 presets of this version.

Install it. curl -fsSL -o try-objects.sh https://confighub.github.io/helm-expt/site/sh/nvidia-gpu-operator-v25-10-1/default/try-objects.sh && bash try-objects.sh

OCI bundle. oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/bundles/catalog-nvidia-gpu-operator-v25-10-1-default:r001@sha256:03032d8e9d7b6446c7556273a760deafbae69dd6bb2d825649f16e48cab38f11

Needs first. Nothing. The script applies any CRDs first.

Step by step. Deploy the GPU Operator from the Catalog.

How it works. How the model works, and Helm in the Catalog.

What this page gives you

This is a human-readable detail page for one retained package version. It keeps the package, base names, exact OCI identity, and publication receipt reachable without pretending this retained-only version has the richer readiness evidence attached to the bold version in the component row.

Where its settings and observations live

Each packaged configuration records Helm-derived files and installer metadata. Later ConfigHub changes belong in governed variants. Target prerequisites and live observations remain separate facts; this publication receipt does not turn them into passes.

Four Separate Questions

Inspecting a source, producing objects, checking a destination, and checking a live result are different jobs. A Catalog match is useful for comparison but is not required. A missing destination or deployment is shown as not run or blocked, not as a failed configuration.

Question	Current answer	What it needs	Status
What do I have?	Inspect the helm source, choices, locks, and any existing output before selecting a destination.	Destination access: no Selected configuration deployed: no	Available to inspect evidence recorded
What will it produce?	Run the recorded Helm render step to produce the exact Kubernetes objects for this configuration.	Destination access: no Selected configuration deployed: no	Checked: passed evidence recorded
Can this destination accept it?	The destination has not been checked for this exact configuration. A recorded source or render result is not a destination pass.	Destination access: yes Selected configuration deployed: no	Not run no run recorded
Did it work?	No post-deployment result is recorded for this exact configuration. Publication, upload, or rendering is not proof that it ran correctly.	Destination access: yes Selected configuration deployed: yes	Not run no run recorded

Open the complete assessment, source, lifecycle, and evidence record.

Try This Chart

Inspect the exact package first, then choose one of the packaged configurations. The version remains readable in the reference, and the manifest digest prevents the registry from returning different package bytes. The setup command renders files locally; it does not apply them to Kubernetes.

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.

cub installer inspect oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/nvidia-gpu-operator:v25.10.1@sha256:35774151264bf1b5998330ca4290ae306e89470c7eb05a4e4c8fc18401c9e155 --json
cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/nvidia-gpu-operator:v25.10.1@sha256:35774151264bf1b5998330ca4290ae306e89470c7eb05a4e4c8fc18401c9e155 --base default --work-dir ./nvidia-gpu-operator-v25-10-1-default --non-interactive

Run shared local configuration checks after the package has written its Kubernetes YAML:

cub plugin install confighub/homebrew-tap@cub-scan-v0.7.3 --name scan
cub check --format json --output cub-check.json <work-dir>/out/manifests

The check is advisory and does not apply anything.

Version tag: oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/nvidia-gpu-operator:v25.10.1

Exact package: oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/nvidia-gpu-operator:v25.10.1@sha256:35774151264bf1b5998330ca4290ae306e89470c7eb05a4e4c8fc18401c9e155

The manifest digest comes from the committed publication receipt. cub installer refuses the pull if that exact manifest is not available.

Verify the package publisher

Run this command with cosign. It checks the expected publisher, the exact manifest digest, and the package annotations.

cosign verify --certificate-identity helm-expt-package-signer@nth-fort-499605-q5.iam.gserviceaccount.com --certificate-oidc-issuer https://accounts.google.com --annotations confighub.com/package-path=packages/nvidia/gpu-operator/v25.10.1 --annotations confighub.com/package-sha256=744153b8bc1899fa4b41e893b8b21c5eca1f16781d9f1052d2dace418bc9f0e0 europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/nvidia-gpu-operator:v25.10.1@sha256:35774151264bf1b5998330ca4290ae306e89470c7eb05a4e4c8fc18401c9e155

A valid signature identifies who signed these package bytes. It does not show that the configuration is suitable for your cluster; use this page's checks and setup instructions for that decision.

Signature receipt · Sigstore bundle · How signature verification works

Use this entry in ConfigHub

Every Catalog entry page carries these five steps in this order. Each step says what the Catalog has run for this entry, and a step with a missing precondition gives no command.

Steps 1 and 2 need no account. Install the cub CLI before any cub command. Step 2 uses cub config diff, which cub plugin install confighub/cub-workshop@v0.6.61 adds. This page covers 6 entries, so open the one you want. A live walk on 2026-10-08 ran steps 3 to 5 for bitnami-nginx-24-0-2-http-clusterip and nvidia-gpu-operator-v26-3-3-default. These commands carry the changes that walk needed. It is a dated log and no receipt, so no state on this page rests on it.

Helm chart, base default, version v25.10.1

What is fixed, and what you supply

Fixed when this entry was built. These went into the build, so the objects already carry them. To change one, build the entry again from its source.

chart is nvidia/gpu-operator
version is v25.10.1
base is default
valuesProfile is recipes/nvidia/gpu-operator/v25.10.1/effective-values.yaml
namespace is gpu-operator
releaseName is gpu-operator
capabilityProfile is {"apiVersions":[],"kubeVersion":"1.31.0"}

Yours to supply or check. The destination must have these before the objects are applied. The words in italics say what the Catalog knows about each.

gpu-operator CRD included in this base; it must be established before Kubernetes accepts the rendered ClusterPolicy object Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.

This entry's plan, and how to test it

These are the steps that plain objects cannot carry. ConfigHub stores them and does not carry them out. The words in italics say what the Catalog knows about each.

When you deliver. Apply the 5 CustomResourceDefinition objects first. Wait until every named definition reports the Established condition. The listing gives the rest. Who: whatever applies the objects. Written down. Not run by the Catalog.
Around an upgrade. Before an upgrade, move the CRDs to the new version. Helm does not upgrade CRDs from a chart's crds directory, so the chart ships this Job. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Around a delete. After deleting, prune node-feature-discovery labels from the nodes. The Job runs nfd-master -prune, which removes node-feature-discovery labels, annotations and taints from every node, with its own ServiceAccount, ClusterRole and ClusterRoleBinding. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.

Test the plain objects yourself. This script tests the retained objects themselves with kubectl, and it needs no cub and no account. Read it first and use a throwaway cluster. The Catalog has no recorded run of this script.

Read what a plan is, and why some entries have one.

1. Get the exact objects Run for this entry

The Catalog rendered this entry and retains its 24 objects in one file.

An upload can create more Units than the objects counted here. The installer renders a Namespace, and the upload adds an installer-record Unit.

# fetch the retained objects for this entry
$ curl -fsSL -o nvidia-gpu-operator-v25-10-1-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v25.10.1/revisions/default/r001/rendered/release-objects.yaml

# check the bytes against the listing
$ shasum -a 256 nvidia-gpu-operator-v25-10-1-default.yaml
4a711392870e1063a56eaaf4ca40219d82f4acda7cae5c2ead234a9fa1384891  nvidia-gpu-operator-v25-10-1-default.yaml

# render this base from the signed package; step 3 uploads this directory
$ cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/nvidia-gpu-operator:v25.10.1@sha256:35774151264bf1b5998330ca4290ae306e89470c7eb05a4e4c8fc18401c9e155 --base default --work-dir ./nvidia-gpu-operator-v25-10-1-default --non-interactive --namespace gpu-operator

2. Compare with another version or base Not run for this entry

The listing records no comparison for this entry. The commands run on the retained files, with no account. This version has 5 other bases in the Catalog, driver-580.126.20, driver-595.91.07, external-nfd, preinstalled-driver and preinstalled-driver-and-toolkit. The Catalog holds 3 other versions, v26.3.2, v26.3.3 and v26.7.1.

# fetch the driver-580.126.20 base of the same version
$ curl -fsSL -o nvidia-gpu-operator-v25-10-1-driver-580-126-20.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v25.10.1/revisions/driver-580.126.20/r001/rendered/release-objects.yaml

# list what differs between the two bases
$ cub config diff nvidia-gpu-operator-v25-10-1-default.yaml nvidia-gpu-operator-v25-10-1-driver-580-126-20.yaml --summary

# fetch the default base at version v26.3.2
$ curl -fsSL -o nvidia-gpu-operator-v26-3-2-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.3.2/revisions/default/r001/rendered/release-objects.yaml

# list what changes from v25.10.1 to v26.3.2
$ cub config diff nvidia-gpu-operator-v25-10-1-default.yaml nvidia-gpu-operator-v26-3-2-default.yaml --summary

3. Upload it as a variant Not run for this entry

The Catalog has not uploaded this entry. The commands use its signed installer package. Read the log of the live walk on 2026-10-08.

Replace each value in angle brackets with a name of your own. The entry id may already exist as a Space in your organization, and the package name as a Component.

In the live walk, a Space named for the nginx entry's id and a Component named bitnami-nginx already existed, so the walk chose its own names. The --component flag sets the Component label the upload writes on the Space, which is the package name when you omit it.

The cub installer plugin reads your organization from CUB_CONTEXT and ignores --context. If you use a context other than your default, export CUB_CONTEXT first, or the plugin works in your default organization.

# sign in; steps 3 to 5 write to your ConfigHub organization
$ cub auth login

# upload step 1's directory as a Space of Units, under names you choose
$ cub installer upload --work-dir ./nvidia-gpu-operator-v25-10-1-default --space <your-space> --component <your-component>

# list the Units the upload created
$ cub unit list --space <your-space>

4. Deploy it Not run for this entry

No delivery run is recorded for this entry. Argo CD has not run, Flux has not run, and kubectl has not run. The commands name the Target workshop/target, which cub cluster up --name workshop creates on a local kind cluster with Argo CD. Use your own Target for a real destination. The base carries 5 CRDs it needs, so the destination does not supply them. Read the log of the live walk on 2026-10-08.

Use the Space name you chose in step 3. The delete command is needed because the cloned installer-record Unit carries the Target and Argo CD v3.5.4 cannot read it, a defect seen on cub v0.8.7 and server v0.8.9.

Without that line the walk deployed nothing and Argo CD showed Unknown, while every cub command exited 0. The walk ran the four commands in this order and did not try them without the first publish.

ConfigHub shows nothing when Argo CD fails to read a Release. Run kubectl -n argocd get applications.argoproj.io and read the Sync column, because Healthy alone is not a pass. Argo CD took between 18 seconds and about 5 minutes to read a Release on a cluster made without argobot.

The walk made its cluster with cub cluster up --no-argobot. That command creates two Spaces, a Worker, a Target and a Trigger, opens ports 30010 to 30019 on the machine, and installs Argo CD from an unpinned upstream manifest.

Removing the ConfigHub side does not remove the workload. In the walk, deleting the Application Unit and the Spaces left the Application and its pods running, because the root Application does not prune.

# clone the base onto a Target as a dev variant
$ cub variant create dev <your-space> --target workshop/target --space-pattern "template:<your-space>-dev"

# publish the Release that the cluster's Argo CD pulls
$ cub release publish <your-space>-dev

# delete the installer record, which Argo CD cannot read
$ cub unit delete --space <your-space>-dev installer-record

# publish again without it
$ cub release publish <your-space>-dev

5. Promote a change Not run for this entry

No promotion is recorded for this entry. Promotion carries a change in the base to the dev variant. The base changes when you edit a Unit or upload a newer version into the same Space. Read the log of the live walk on 2026-10-08.

The promotion changes the dev Space and publishes nothing. It also adds the installer-record Unit back with the Target. The change reaches the cluster only after the delete and the publish.

The preview lists the whole installer record as added. In the walk, the preview of a one-label change to gpu-operator ran to 405 lines, and about 400 of them were that record.

# preview what the dev variant would take from the base
$ cub variant promote <your-space>-dev --dry-run -o mutations

# promote once you have read the preview
$ cub variant promote <your-space>-dev --change-desc "Pull the reviewed base forward"

# delete the installer record that the promotion adds back
$ cub unit delete --space <your-space>-dev installer-record

# publish the Release that carries the change
$ cub release publish <your-space>-dev

Helm chart, base driver-580.126.20, version v25.10.1

What is fixed, and what you supply

Fixed when this entry was built. These went into the build, so the objects already carry them. To change one, build the entry again from its source.

chart is nvidia/gpu-operator
version is v25.10.1
base is driver-580.126.20
valuesProfile is recipes/nvidia/gpu-operator/v25.10.1/effective-values-driver-580.126.20.yaml
namespace is gpu-operator
releaseName is gpu-operator
capabilityProfile is {"apiVersions":[],"kubeVersion":"1.31.0"}

Yours to supply or check. The destination must have these before the objects are applied. The words in italics say what the Catalog knows about each.

gpu-operator CRD included in this base; it must be established before Kubernetes accepts the rendered ClusterPolicy object Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.

This entry's plan, and how to test it

These are the steps that plain objects cannot carry. ConfigHub stores them and does not carry them out. The words in italics say what the Catalog knows about each.

When you deliver. Apply the 5 CustomResourceDefinition objects first. Wait until every named definition reports the Established condition. The listing gives the rest. Who: whatever applies the objects. Written down. Not run by the Catalog.
Around an upgrade. Before an upgrade, move the CRDs to the new version. Helm does not upgrade CRDs from a chart's crds directory, so the chart ships this Job. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Around a delete. After deleting, prune node-feature-discovery labels from the nodes. The Job runs nfd-master -prune, which removes node-feature-discovery labels, annotations and taints from every node, with its own ServiceAccount, ClusterRole and ClusterRoleBinding. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.

Read what a plan is, and why some entries have one.

1. Get the exact objects Run for this entry

The Catalog rendered this entry and retains its 24 objects in one file.

An upload can create more Units than the objects counted here. The installer renders a Namespace, and the upload adds an installer-record Unit.

# fetch the retained objects for this entry
$ curl -fsSL -o nvidia-gpu-operator-v25-10-1-driver-580-126-20.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v25.10.1/revisions/driver-580.126.20/r001/rendered/release-objects.yaml

# check the bytes against the listing
$ shasum -a 256 nvidia-gpu-operator-v25-10-1-driver-580-126-20.yaml
ac011644664f8eadcbceeb44327d0525429d2710bfc9aef90ebe6d721d6090ee  nvidia-gpu-operator-v25-10-1-driver-580-126-20.yaml

# render this base from the signed package; step 3 uploads this directory
$ cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/nvidia-gpu-operator:v25.10.1@sha256:35774151264bf1b5998330ca4290ae306e89470c7eb05a4e4c8fc18401c9e155 --base driver-580.126.20 --work-dir ./nvidia-gpu-operator-v25-10-1-driver-580-126-20 --non-interactive --namespace gpu-operator

2. Compare with another version or base Not run for this entry

The listing records no comparison for this entry. The commands run on the retained files, with no account. This version has 5 other bases in the Catalog, default, driver-595.91.07, external-nfd, preinstalled-driver and preinstalled-driver-and-toolkit. The Catalog holds 3 other versions, v26.3.2, v26.3.3 and v26.7.1.

# fetch the default base of the same version
$ curl -fsSL -o nvidia-gpu-operator-v25-10-1-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v25.10.1/revisions/default/r001/rendered/release-objects.yaml

# list what differs between the two bases
$ cub config diff nvidia-gpu-operator-v25-10-1-driver-580-126-20.yaml nvidia-gpu-operator-v25-10-1-default.yaml --summary

# fetch the driver-580.126.20 base at version v26.7.1
$ curl -fsSL -o nvidia-gpu-operator-v26-7-1-driver-580-126-20.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.7.1/revisions/driver-580.126.20/r001/rendered/release-objects.yaml

# list what changes from v25.10.1 to v26.7.1
$ cub config diff nvidia-gpu-operator-v25-10-1-driver-580-126-20.yaml nvidia-gpu-operator-v26-7-1-driver-580-126-20.yaml --summary

3. Upload it as a variant Not run for this entry

The Catalog has not uploaded this entry. The commands use its signed installer package. Read the log of the live walk on 2026-10-08.

Replace each value in angle brackets with a name of your own. The entry id may already exist as a Space in your organization, and the package name as a Component.

# sign in; steps 3 to 5 write to your ConfigHub organization
$ cub auth login

# upload step 1's directory as a Space of Units, under names you choose
$ cub installer upload --work-dir ./nvidia-gpu-operator-v25-10-1-driver-580-126-20 --space <your-space> --component <your-component>

# list the Units the upload created
$ cub unit list --space <your-space>

4. Deploy it Not run for this entry

Without that line the walk deployed nothing and Argo CD showed Unknown, while every cub command exited 0. The walk ran the four commands in this order and did not try them without the first publish.

# clone the base onto a Target as a dev variant
$ cub variant create dev <your-space> --target workshop/target --space-pattern "template:<your-space>-dev"

# publish the Release that the cluster's Argo CD pulls
$ cub release publish <your-space>-dev

# delete the installer record, which Argo CD cannot read
$ cub unit delete --space <your-space>-dev installer-record

# publish again without it
$ cub release publish <your-space>-dev

5. Promote a change Not run for this entry

The promotion changes the dev Space and publishes nothing. It also adds the installer-record Unit back with the Target. The change reaches the cluster only after the delete and the publish.

The preview lists the whole installer record as added. In the walk, the preview of a one-label change to gpu-operator ran to 405 lines, and about 400 of them were that record.

# preview what the dev variant would take from the base
$ cub variant promote <your-space>-dev --dry-run -o mutations

# promote once you have read the preview
$ cub variant promote <your-space>-dev --change-desc "Pull the reviewed base forward"

# delete the installer record that the promotion adds back
$ cub unit delete --space <your-space>-dev installer-record

# publish the Release that carries the change
$ cub release publish <your-space>-dev

Helm chart, base driver-595.91.07, version v25.10.1

What is fixed, and what you supply

Fixed when this entry was built. These went into the build, so the objects already carry them. To change one, build the entry again from its source.

chart is nvidia/gpu-operator
version is v25.10.1
base is driver-595.91.07
valuesProfile is recipes/nvidia/gpu-operator/v25.10.1/effective-values-driver-595.91.07.yaml
namespace is gpu-operator
releaseName is gpu-operator
capabilityProfile is {"apiVersions":[],"kubeVersion":"1.31.0"}

Yours to supply or check. The destination must have these before the objects are applied. The words in italics say what the Catalog knows about each.

gpu-operator CRD included in this base; it must be established before Kubernetes accepts the rendered ClusterPolicy object Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.

This entry's plan, and how to test it

These are the steps that plain objects cannot carry. ConfigHub stores them and does not carry them out. The words in italics say what the Catalog knows about each.

When you deliver. Apply the 5 CustomResourceDefinition objects first. Wait until every named definition reports the Established condition. The listing gives the rest. Who: whatever applies the objects. Written down. Not run by the Catalog.
Around an upgrade. Before an upgrade, move the CRDs to the new version. Helm does not upgrade CRDs from a chart's crds directory, so the chart ships this Job. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Around a delete. After deleting, prune node-feature-discovery labels from the nodes. The Job runs nfd-master -prune, which removes node-feature-discovery labels, annotations and taints from every node, with its own ServiceAccount, ClusterRole and ClusterRoleBinding. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.

Read what a plan is, and why some entries have one.

1. Get the exact objects Run for this entry

The Catalog rendered this entry and retains its 24 objects in one file.

An upload can create more Units than the objects counted here. The installer renders a Namespace, and the upload adds an installer-record Unit.

# fetch the retained objects for this entry
$ curl -fsSL -o nvidia-gpu-operator-v25-10-1-driver-595-91-07.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v25.10.1/revisions/driver-595.91.07/r001/rendered/release-objects.yaml

# check the bytes against the listing
$ shasum -a 256 nvidia-gpu-operator-v25-10-1-driver-595-91-07.yaml
32714faffb818eaeda0f014bf562eab4942f8a1c8ce93d5a2c6613f087978cac  nvidia-gpu-operator-v25-10-1-driver-595-91-07.yaml

# render this base from the signed package; step 3 uploads this directory
$ cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/nvidia-gpu-operator:v25.10.1@sha256:35774151264bf1b5998330ca4290ae306e89470c7eb05a4e4c8fc18401c9e155 --base driver-595.91.07 --work-dir ./nvidia-gpu-operator-v25-10-1-driver-595-91-07 --non-interactive --namespace gpu-operator

2. Compare with another version or base Not run for this entry

The listing records no comparison for this entry. The commands run on the retained files, with no account. This version has 5 other bases in the Catalog, default, driver-580.126.20, external-nfd, preinstalled-driver and preinstalled-driver-and-toolkit. The Catalog holds 3 other versions, v26.3.2, v26.3.3 and v26.7.1.

# fetch the default base of the same version
$ curl -fsSL -o nvidia-gpu-operator-v25-10-1-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v25.10.1/revisions/default/r001/rendered/release-objects.yaml

# list what differs between the two bases
$ cub config diff nvidia-gpu-operator-v25-10-1-driver-595-91-07.yaml nvidia-gpu-operator-v25-10-1-default.yaml --summary

# fetch the driver-595.91.07 base at version v26.3.2
$ curl -fsSL -o nvidia-gpu-operator-v26-3-2-driver-595-91-07.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.3.2/revisions/driver-595.91.07/r001/rendered/release-objects.yaml

# list what changes from v25.10.1 to v26.3.2
$ cub config diff nvidia-gpu-operator-v25-10-1-driver-595-91-07.yaml nvidia-gpu-operator-v26-3-2-driver-595-91-07.yaml --summary

3. Upload it as a variant Not run for this entry

The Catalog has not uploaded this entry. The commands use its signed installer package. Read the log of the live walk on 2026-10-08.

Replace each value in angle brackets with a name of your own. The entry id may already exist as a Space in your organization, and the package name as a Component.

# sign in; steps 3 to 5 write to your ConfigHub organization
$ cub auth login

# upload step 1's directory as a Space of Units, under names you choose
$ cub installer upload --work-dir ./nvidia-gpu-operator-v25-10-1-driver-595-91-07 --space <your-space> --component <your-component>

# list the Units the upload created
$ cub unit list --space <your-space>

4. Deploy it Not run for this entry

Without that line the walk deployed nothing and Argo CD showed Unknown, while every cub command exited 0. The walk ran the four commands in this order and did not try them without the first publish.

# clone the base onto a Target as a dev variant
$ cub variant create dev <your-space> --target workshop/target --space-pattern "template:<your-space>-dev"

# publish the Release that the cluster's Argo CD pulls
$ cub release publish <your-space>-dev

# delete the installer record, which Argo CD cannot read
$ cub unit delete --space <your-space>-dev installer-record

# publish again without it
$ cub release publish <your-space>-dev

5. Promote a change Not run for this entry

The promotion changes the dev Space and publishes nothing. It also adds the installer-record Unit back with the Target. The change reaches the cluster only after the delete and the publish.

The preview lists the whole installer record as added. In the walk, the preview of a one-label change to gpu-operator ran to 405 lines, and about 400 of them were that record.

# preview what the dev variant would take from the base
$ cub variant promote <your-space>-dev --dry-run -o mutations

# promote once you have read the preview
$ cub variant promote <your-space>-dev --change-desc "Pull the reviewed base forward"

# delete the installer record that the promotion adds back
$ cub unit delete --space <your-space>-dev installer-record

# publish the Release that carries the change
$ cub release publish <your-space>-dev

Helm chart, base external-nfd, version v25.10.1

What is fixed, and what you supply

Fixed when this entry was built. These went into the build, so the objects already carry them. To change one, build the entry again from its source.

chart is nvidia/gpu-operator
version is v25.10.1
base is external-nfd
valuesProfile is recipes/nvidia/gpu-operator/v25.10.1/effective-values-external-nfd.yaml
namespace is gpu-operator
releaseName is gpu-operator
capabilityProfile is {"apiVersions":[],"kubeVersion":"1.31.0"}

Yours to supply or check. The destination must have these before the objects are applied. The words in italics say what the Catalog knows about each.

gpu-operator CRD included in this base; it must be established before Kubernetes accepts the rendered ClusterPolicy object Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.

This entry's plan, and how to test it

These are the steps that plain objects cannot carry. ConfigHub stores them and does not carry them out. The words in italics say what the Catalog knows about each.

When you deliver. Apply the 2 CustomResourceDefinition objects first. Wait until every named definition reports the Established condition. The listing gives the rest. Who: whatever applies the objects. Written down. Not run by the Catalog.
Around an upgrade. Before an upgrade, move the CRDs to the new version. Helm does not upgrade CRDs from a chart's crds directory, so the chart ships this Job. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.

Read what a plan is, and why some entries have one.

1. Get the exact objects Run for this entry

The Catalog rendered this entry and retains its 9 objects in one file.

An upload can create more Units than the objects counted here. The installer renders a Namespace, and the upload adds an installer-record Unit.

# fetch the retained objects for this entry
$ curl -fsSL -o nvidia-gpu-operator-v25-10-1-external-nfd.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v25.10.1/revisions/external-nfd/r001/rendered/release-objects.yaml

# check the bytes against the listing
$ shasum -a 256 nvidia-gpu-operator-v25-10-1-external-nfd.yaml
8667cb754f68c927b3d9dee8e7c4e1cb7d5141e6947f788f3e44853883df665a  nvidia-gpu-operator-v25-10-1-external-nfd.yaml

# render this base from the signed package; step 3 uploads this directory
$ cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/nvidia-gpu-operator:v25.10.1@sha256:35774151264bf1b5998330ca4290ae306e89470c7eb05a4e4c8fc18401c9e155 --base external-nfd --work-dir ./nvidia-gpu-operator-v25-10-1-external-nfd --non-interactive --namespace gpu-operator

2. Compare with another version or base Not run for this entry

The listing records no comparison for this entry. The commands run on the retained files, with no account. This version has 5 other bases in the Catalog, default, driver-580.126.20, driver-595.91.07, preinstalled-driver and preinstalled-driver-and-toolkit. The Catalog holds 3 other versions, v26.3.2, v26.3.3 and v26.7.1.

# fetch the default base of the same version
$ curl -fsSL -o nvidia-gpu-operator-v25-10-1-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v25.10.1/revisions/default/r001/rendered/release-objects.yaml

# list what differs between the two bases
$ cub config diff nvidia-gpu-operator-v25-10-1-external-nfd.yaml nvidia-gpu-operator-v25-10-1-default.yaml --summary

# fetch the external-nfd base at version v26.3.2
$ curl -fsSL -o nvidia-gpu-operator-v26-3-2-external-nfd.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.3.2/revisions/external-nfd/r001/rendered/release-objects.yaml

# list what changes from v25.10.1 to v26.3.2
$ cub config diff nvidia-gpu-operator-v25-10-1-external-nfd.yaml nvidia-gpu-operator-v26-3-2-external-nfd.yaml --summary

3. Upload it as a variant Not run for this entry

The Catalog has not uploaded this entry. The commands use its signed installer package. Read the log of the live walk on 2026-10-08.

Replace each value in angle brackets with a name of your own. The entry id may already exist as a Space in your organization, and the package name as a Component.

# sign in; steps 3 to 5 write to your ConfigHub organization
$ cub auth login

# upload step 1's directory as a Space of Units, under names you choose
$ cub installer upload --work-dir ./nvidia-gpu-operator-v25-10-1-external-nfd --space <your-space> --component <your-component>

# list the Units the upload created
$ cub unit list --space <your-space>

4. Deploy it Not run for this entry

No delivery run is recorded for this entry. Argo CD has not run, Flux has not run, and kubectl has not run. The commands name the Target workshop/target, which cub cluster up --name workshop creates on a local kind cluster with Argo CD. Use your own Target for a real destination. The base carries 2 CRDs it needs, so the destination does not supply them. Read the log of the live walk on 2026-10-08.

Without that line the walk deployed nothing and Argo CD showed Unknown, while every cub command exited 0. The walk ran the four commands in this order and did not try them without the first publish.

# clone the base onto a Target as a dev variant
$ cub variant create dev <your-space> --target workshop/target --space-pattern "template:<your-space>-dev"

# publish the Release that the cluster's Argo CD pulls
$ cub release publish <your-space>-dev

# delete the installer record, which Argo CD cannot read
$ cub unit delete --space <your-space>-dev installer-record

# publish again without it
$ cub release publish <your-space>-dev

5. Promote a change Not run for this entry

The promotion changes the dev Space and publishes nothing. It also adds the installer-record Unit back with the Target. The change reaches the cluster only after the delete and the publish.

The preview lists the whole installer record as added. In the walk, the preview of a one-label change to gpu-operator ran to 405 lines, and about 400 of them were that record.

# preview what the dev variant would take from the base
$ cub variant promote <your-space>-dev --dry-run -o mutations

# promote once you have read the preview
$ cub variant promote <your-space>-dev --change-desc "Pull the reviewed base forward"

# delete the installer record that the promotion adds back
$ cub unit delete --space <your-space>-dev installer-record

# publish the Release that carries the change
$ cub release publish <your-space>-dev

Helm chart, base preinstalled-driver, version v25.10.1

What is fixed, and what you supply

Fixed when this entry was built. These went into the build, so the objects already carry them. To change one, build the entry again from its source.

chart is nvidia/gpu-operator
version is v25.10.1
base is preinstalled-driver
valuesProfile is recipes/nvidia/gpu-operator/v25.10.1/effective-values-preinstalled-driver.yaml
namespace is gpu-operator
releaseName is gpu-operator
capabilityProfile is {"apiVersions":[],"kubeVersion":"1.31.0"}

Yours to supply or check. The destination must have these before the objects are applied. The words in italics say what the Catalog knows about each.

gpu-operator CRD included in this base; it must be established before Kubernetes accepts the rendered ClusterPolicy object Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.

This entry's plan, and how to test it

These are the steps that plain objects cannot carry. ConfigHub stores them and does not carry them out. The words in italics say what the Catalog knows about each.

When you deliver. Apply the 5 CustomResourceDefinition objects first. Wait until every named definition reports the Established condition. The listing gives the rest. Who: whatever applies the objects. Written down. Not run by the Catalog.
Around an upgrade. Before an upgrade, move the CRDs to the new version. Helm does not upgrade CRDs from a chart's crds directory, so the chart ships this Job. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Around a delete. After deleting, prune node-feature-discovery labels from the nodes. The Job runs nfd-master -prune, which removes node-feature-discovery labels, annotations and taints from every node, with its own ServiceAccount, ClusterRole and ClusterRoleBinding. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.

Read what a plan is, and why some entries have one.

1. Get the exact objects Run for this entry

The Catalog rendered this entry and retains its 24 objects in one file.

An upload can create more Units than the objects counted here. The installer renders a Namespace, and the upload adds an installer-record Unit.

# fetch the retained objects for this entry
$ curl -fsSL -o nvidia-gpu-operator-v25-10-1-preinstalled-driver.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v25.10.1/revisions/preinstalled-driver/r001/rendered/release-objects.yaml

# check the bytes against the listing
$ shasum -a 256 nvidia-gpu-operator-v25-10-1-preinstalled-driver.yaml
4b03d8e2d14fb9cec1bc58aad65d50f18997e2f7cb6db661d279822ce7c8d9ea  nvidia-gpu-operator-v25-10-1-preinstalled-driver.yaml

# render this base from the signed package; step 3 uploads this directory
$ cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/nvidia-gpu-operator:v25.10.1@sha256:35774151264bf1b5998330ca4290ae306e89470c7eb05a4e4c8fc18401c9e155 --base preinstalled-driver --work-dir ./nvidia-gpu-operator-v25-10-1-preinstalled-driver --non-interactive --namespace gpu-operator

2. Compare with another version or base Not run for this entry

The listing records no comparison for this entry. The commands run on the retained files, with no account. This version has 5 other bases in the Catalog, default, driver-580.126.20, driver-595.91.07, external-nfd and preinstalled-driver-and-toolkit. The Catalog holds 3 other versions, v26.3.2, v26.3.3 and v26.7.1.

# fetch the default base of the same version
$ curl -fsSL -o nvidia-gpu-operator-v25-10-1-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v25.10.1/revisions/default/r001/rendered/release-objects.yaml

# list what differs between the two bases
$ cub config diff nvidia-gpu-operator-v25-10-1-preinstalled-driver.yaml nvidia-gpu-operator-v25-10-1-default.yaml --summary

# fetch the preinstalled-driver base at version v26.3.2
$ curl -fsSL -o nvidia-gpu-operator-v26-3-2-preinstalled-driver.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.3.2/revisions/preinstalled-driver/r001/rendered/release-objects.yaml

# list what changes from v25.10.1 to v26.3.2
$ cub config diff nvidia-gpu-operator-v25-10-1-preinstalled-driver.yaml nvidia-gpu-operator-v26-3-2-preinstalled-driver.yaml --summary

3. Upload it as a variant Not run for this entry

The Catalog has not uploaded this entry. The commands use its signed installer package. Read the log of the live walk on 2026-10-08.

Replace each value in angle brackets with a name of your own. The entry id may already exist as a Space in your organization, and the package name as a Component.

# sign in; steps 3 to 5 write to your ConfigHub organization
$ cub auth login

# upload step 1's directory as a Space of Units, under names you choose
$ cub installer upload --work-dir ./nvidia-gpu-operator-v25-10-1-preinstalled-driver --space <your-space> --component <your-component>

# list the Units the upload created
$ cub unit list --space <your-space>

4. Deploy it Not run for this entry

Without that line the walk deployed nothing and Argo CD showed Unknown, while every cub command exited 0. The walk ran the four commands in this order and did not try them without the first publish.

# clone the base onto a Target as a dev variant
$ cub variant create dev <your-space> --target workshop/target --space-pattern "template:<your-space>-dev"

# publish the Release that the cluster's Argo CD pulls
$ cub release publish <your-space>-dev

# delete the installer record, which Argo CD cannot read
$ cub unit delete --space <your-space>-dev installer-record

# publish again without it
$ cub release publish <your-space>-dev

5. Promote a change Not run for this entry

The promotion changes the dev Space and publishes nothing. It also adds the installer-record Unit back with the Target. The change reaches the cluster only after the delete and the publish.

The preview lists the whole installer record as added. In the walk, the preview of a one-label change to gpu-operator ran to 405 lines, and about 400 of them were that record.

# preview what the dev variant would take from the base
$ cub variant promote <your-space>-dev --dry-run -o mutations

# promote once you have read the preview
$ cub variant promote <your-space>-dev --change-desc "Pull the reviewed base forward"

# delete the installer record that the promotion adds back
$ cub unit delete --space <your-space>-dev installer-record

# publish the Release that carries the change
$ cub release publish <your-space>-dev

Helm chart, base preinstalled-driver-and-toolkit, version v25.10.1

What is fixed, and what you supply

Fixed when this entry was built. These went into the build, so the objects already carry them. To change one, build the entry again from its source.

chart is nvidia/gpu-operator
version is v25.10.1
base is preinstalled-driver-and-toolkit
valuesProfile is recipes/nvidia/gpu-operator/v25.10.1/effective-values-preinstalled-driver-and-toolkit.yaml
namespace is gpu-operator
releaseName is gpu-operator
capabilityProfile is {"apiVersions":[],"kubeVersion":"1.31.0"}

Yours to supply or check. The destination must have these before the objects are applied. The words in italics say what the Catalog knows about each.

gpu-operator CRD included in this base; it must be established before Kubernetes accepts the rendered ClusterPolicy object Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.

This entry's plan, and how to test it

These are the steps that plain objects cannot carry. ConfigHub stores them and does not carry them out. The words in italics say what the Catalog knows about each.

When you deliver. Apply the 5 CustomResourceDefinition objects first. Wait until every named definition reports the Established condition. The listing gives the rest. Who: whatever applies the objects. Written down. Not run by the Catalog.
Around an upgrade. Before an upgrade, move the CRDs to the new version. Helm does not upgrade CRDs from a chart's crds directory, so the chart ships this Job. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Around a delete. After deleting, prune node-feature-discovery labels from the nodes. The Job runs nfd-master -prune, which removes node-feature-discovery labels, annotations and taints from every node, with its own ServiceAccount, ClusterRole and ClusterRoleBinding. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.

Read what a plan is, and why some entries have one.

1. Get the exact objects Run for this entry

The Catalog rendered this entry and retains its 24 objects in one file.

An upload can create more Units than the objects counted here. The installer renders a Namespace, and the upload adds an installer-record Unit.

# fetch the retained objects for this entry
$ curl -fsSL -o nvidia-gpu-operator-v25-10-1-preinstalled-driver-and-toolkit.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v25.10.1/revisions/preinstalled-driver-and-toolkit/r001/rendered/release-objects.yaml

# check the bytes against the listing
$ shasum -a 256 nvidia-gpu-operator-v25-10-1-preinstalled-driver-and-toolkit.yaml
ec5537100284d75523d002dcd5d4754382bb372b4087d3564ad2c966103eaac8  nvidia-gpu-operator-v25-10-1-preinstalled-driver-and-toolkit.yaml

# render this base from the signed package; step 3 uploads this directory
$ cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/nvidia-gpu-operator:v25.10.1@sha256:35774151264bf1b5998330ca4290ae306e89470c7eb05a4e4c8fc18401c9e155 --base preinstalled-driver-and-toolkit --work-dir ./nvidia-gpu-operator-v25-10-1-preinstalled-driver-and-toolkit --non-interactive --namespace gpu-operator

2. Compare with another version or base Not run for this entry

The listing records no comparison for this entry. The commands run on the retained files, with no account. This version has 5 other bases in the Catalog, default, driver-580.126.20, driver-595.91.07, external-nfd and preinstalled-driver. The Catalog holds 3 other versions, v26.3.2, v26.3.3 and v26.7.1.

# fetch the default base of the same version
$ curl -fsSL -o nvidia-gpu-operator-v25-10-1-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v25.10.1/revisions/default/r001/rendered/release-objects.yaml

# list what differs between the two bases
$ cub config diff nvidia-gpu-operator-v25-10-1-preinstalled-driver-and-toolkit.yaml nvidia-gpu-operator-v25-10-1-default.yaml --summary

# fetch the preinstalled-driver-and-toolkit base at version v26.3.2
$ curl -fsSL -o nvidia-gpu-operator-v26-3-2-preinstalled-driver-and-toolkit.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.3.2/revisions/preinstalled-driver-and-toolkit/r001/rendered/release-objects.yaml

# list what changes from v25.10.1 to v26.3.2
$ cub config diff nvidia-gpu-operator-v25-10-1-preinstalled-driver-and-toolkit.yaml nvidia-gpu-operator-v26-3-2-preinstalled-driver-and-toolkit.yaml --summary

3. Upload it as a variant Not run for this entry

The Catalog has not uploaded this entry. The commands use its signed installer package. Read the log of the live walk on 2026-10-08.

Replace each value in angle brackets with a name of your own. The entry id may already exist as a Space in your organization, and the package name as a Component.

# sign in; steps 3 to 5 write to your ConfigHub organization
$ cub auth login

# upload step 1's directory as a Space of Units, under names you choose
$ cub installer upload --work-dir ./nvidia-gpu-operator-v25-10-1-preinstalled-driver-and-toolkit --space <your-space> --component <your-component>

# list the Units the upload created
$ cub unit list --space <your-space>

4. Deploy it Not run for this entry

Without that line the walk deployed nothing and Argo CD showed Unknown, while every cub command exited 0. The walk ran the four commands in this order and did not try them without the first publish.

# clone the base onto a Target as a dev variant
$ cub variant create dev <your-space> --target workshop/target --space-pattern "template:<your-space>-dev"

# publish the Release that the cluster's Argo CD pulls
$ cub release publish <your-space>-dev

# delete the installer record, which Argo CD cannot read
$ cub unit delete --space <your-space>-dev installer-record

# publish again without it
$ cub release publish <your-space>-dev

5. Promote a change Not run for this entry

The promotion changes the dev Space and publishes nothing. It also adds the installer-record Unit back with the Target. The change reaches the cluster only after the delete and the publish.

The preview lists the whole installer record as added. In the walk, the preview of a one-label change to gpu-operator ran to 405 lines, and about 400 of them were that record.

# preview what the dev variant would take from the base
$ cub variant promote <your-space>-dev --dry-run -o mutations

# promote once you have read the preview
$ cub variant promote <your-space>-dev --change-desc "Pull the reviewed base forward"

# delete the installer record that the promotion adds back
$ cub unit delete --space <your-space>-dev installer-record

# publish the Release that carries the change
$ cub release publish <your-space>-dev

For agentsThese steps are the nextSteps array of nvidia-gpu-operator-v25-10-1-default.json, nvidia-gpu-operator-v25-10-1-driver-580-126-20.json, nvidia-gpu-operator-v25-10-1-driver-595-91-07.json, nvidia-gpu-operator-v25-10-1-external-nfd.json, nvidia-gpu-operator-v25-10-1-preinstalled-driver.json, nvidia-gpu-operator-v25-10-1-preinstalled-driver-and-toolkit.json. Each state was read from flattened.retainedObjects, flattened.inventory, source.ociRef, oci.bundles, oci.runtimes, lifecycle.promotion, lifecycle.coverage and variants.known in the same listing. A command marked needsAccount there contacts ConfigHub. A step's notes hold its cautions, carries lists the CRDs the base brings, and liveWalk links the dated log that ran its commands.

Available Configurations

default - package default
driver-580.126.20
driver-595.91.07
preinstalled-driver
preinstalled-driver-and-toolkit
external-nfd

The section below says what these configurations expect you to provide.

Local Configuration Checks

We ran cub check v0.7.3 against the exact rendered objects for every configuration below. The result is advisory: read each finding and decide whether it matters for your target.

Scanner and ruleset identity

Pattern bundle: v0.7.3
Bundle manifest: sha256:0405f6ffe21e567adf5d6a732d181c7f228194920456d046b4338baeb14de1a8
Risk catalog: sha256:7ff79a126ad99bba2505fec8b2b7711c03f50eb362141128ec1c83e27a5036ba

Configuration	Advisory result	Exact input	Checked	Evidence
`default`	16 advisory findings 6 critical, 7 warning, 3 info ClusterPolicy with empty rules causes panic Container does not set runAsNonRoot Container does not disable allowPrivilegeEscalation	24 objects `sha256:ed8868c74e14ccd2e6c6794060264743d8497c64303b759bc188ff494f6218e3`	2026-10-08	Full `cub check` result Exact YAML Separate Catalog review
`driver-580.126.20`	16 advisory findings 6 critical, 7 warning, 3 info ClusterPolicy with empty rules causes panic Container does not set runAsNonRoot Container does not disable allowPrivilegeEscalation	24 objects `sha256:51d372732238b8755b7d22c6a2041463bd493a598aa73fd3e87b1014093890ba`	2026-10-08	Full `cub check` result Exact YAML Separate Catalog review
`driver-595.91.07`	16 advisory findings 6 critical, 7 warning, 3 info ClusterPolicy with empty rules causes panic Container does not set runAsNonRoot Container does not disable allowPrivilegeEscalation	24 objects `sha256:cab45b38392cb32f4bd8166149d8e8c3417813a23e40c760d07511f632329ae0`	2026-10-08	Full `cub check` result Exact YAML Separate Catalog review
`external-nfd`	9 advisory findings 4 critical, 4 warning, 1 info ClusterPolicy with empty rules causes panic Container does not set runAsNonRoot Container does not disable allowPrivilegeEscalation	9 objects `sha256:40faf3df79d445b9c03368fdb47be134f0c9653045a46e5c4627ded3541024e1`	2026-10-08	Full `cub check` result Exact YAML Separate Catalog review
`preinstalled-driver`	16 advisory findings 6 critical, 7 warning, 3 info ClusterPolicy with empty rules causes panic Container does not set runAsNonRoot Container does not disable allowPrivilegeEscalation	24 objects `sha256:7d39d65b952f71fb62cb7e531717e48e49b2abbdd7e52d366c081f3e79eeb85a`	2026-10-08	Full `cub check` result Exact YAML Separate Catalog review
`preinstalled-driver-and-toolkit`	16 advisory findings 6 critical, 7 warning, 3 info ClusterPolicy with empty rules causes panic Container does not set runAsNonRoot Container does not disable allowPrivilegeEscalation	24 objects `sha256:284109ee18bedeb0017e672b457a9d1aa87a3a9dfbeb64f1c8f07b31861b701e`	2026-10-08	Full `cub check` result Exact YAML Separate Catalog review

What this does not check: hook execution, CRD readiness, target Secrets and cloud services, admission behavior, workload health, or rollback. The linked Catalog review covers chart-specific source and operating questions. ConfigHub validation and approval are separate managed controls.

Read all shared check results and the mapping to Catalog rules.

What This Chart Contains

Shipping a chart as plain rendered YAML is faster and simpler, and it silently drops anything Helm was going to do afterwards. This section reports what a scan of the packaged chart found, across 41 files.

Construct	Found	Why it matters when a chart ships as plain YAML
Helm hooks	9	Hook Jobs never fire, or fire under a different hook dialect.
Keep policy	1	A reconciler prunes what Helm promised to keep.
Custom resource definitions	6	Per-file delivery can race the definitions the resources depend on.
Condition-gated subcharts	1	What renders depends on which conditions the values switch on.

A flattening-safety verdict has decided this version: default:flatten-with-routes; driver-580.126.20:flatten-with-routes; driver-595.91.07:flatten-with-routes; external-nfd:flatten-with-routes; preinstalled-driver-and-toolkit:flatten-with-routes; preinstalled-driver:flatten-with-routes. The verdict records one disposition per construct and names any companion artifact a flattened bundle must ship. What the flattening verdict means.

A construct being present does not make a chart unflattenable. Most are switched on or off by values, and a verdict records which ones the base you choose actually reaches. Read the catalog-wide evidence for how common each one is.

Images This Chart Pulls

Every reference below is read from the committed package bases, so what you see is what the packaged manifests name.

Packaged base	Image references
default	`container-toolkit` `cuda` `dcgm` `dcgm-exporter` `default: nvcr.io/nvidia/driver` `description: CC Manager image name` `description: GDRCopy driver image name` `description: GFD image name` `description: Image represents NVIDIA Driver Manager image` `description: Image represents NVIDIA Driver Manager image name` `description: Image represents image name` `description: Kata Manager image name` `description: NVIDIA Container Toolkit image name` `description: NVIDIA DCGM Exporter image name` `description: NVIDIA DCGM image name` `description: NVIDIA Device Plugin image name` `description: NVIDIA Driver image name` `description: NVIDIA GDRCopy driver image name` `description: NVIDIA GPUDirect Storage Driver image name` `description: NVIDIA MIG Manager image name` `description: NVIDIA Sandbox Device Plugin image name` `description: NVIDIA vGPU Device Manager image name` `description: NVIDIA vGPU Manager image name` `description: Node Status Exporter image name` `description: VFIO Manager image name` `description: Validator image name` `driver` `gdrdrv` `gpu-operator` `k8s-cc-manager` `k8s-device-plugin` `k8s-driver-manager` `k8s-kata-manager` `k8s-mig-manager` `kubevirt-gpu-device-plugin` `nvcr.io/nvidia/gpu-operator:v25.10.1` `nvidia-fs` `registry.k8s.io/nfd/node-feature-discovery:v0.18.2` `vgpu-device-manager` `vgpu-manager`
driver-580.126.20	`container-toolkit` `cuda` `dcgm` `dcgm-exporter` `default: nvcr.io/nvidia/driver` `description: CC Manager image name` `description: GDRCopy driver image name` `description: GFD image name` `description: Image represents NVIDIA Driver Manager image` `description: Image represents NVIDIA Driver Manager image name` `description: Image represents image name` `description: Kata Manager image name` `description: NVIDIA Container Toolkit image name` `description: NVIDIA DCGM Exporter image name` `description: NVIDIA DCGM image name` `description: NVIDIA Device Plugin image name` `description: NVIDIA Driver image name` `description: NVIDIA GDRCopy driver image name` `description: NVIDIA GPUDirect Storage Driver image name` `description: NVIDIA MIG Manager image name` `description: NVIDIA Sandbox Device Plugin image name` `description: NVIDIA vGPU Device Manager image name` `description: NVIDIA vGPU Manager image name` `description: Node Status Exporter image name` `description: VFIO Manager image name` `description: Validator image name` `driver` `gdrdrv` `gpu-operator` `k8s-cc-manager` `k8s-device-plugin` `k8s-driver-manager` `k8s-kata-manager` `k8s-mig-manager` `kubevirt-gpu-device-plugin` `nvcr.io/nvidia/gpu-operator:v25.10.1` `nvidia-fs` `registry.k8s.io/nfd/node-feature-discovery:v0.18.2` `vgpu-device-manager` `vgpu-manager`
driver-595.91.07	`container-toolkit` `cuda` `dcgm` `dcgm-exporter` `default: nvcr.io/nvidia/driver` `description: CC Manager image name` `description: GDRCopy driver image name` `description: GFD image name` `description: Image represents NVIDIA Driver Manager image` `description: Image represents NVIDIA Driver Manager image name` `description: Image represents image name` `description: Kata Manager image name` `description: NVIDIA Container Toolkit image name` `description: NVIDIA DCGM Exporter image name` `description: NVIDIA DCGM image name` `description: NVIDIA Device Plugin image name` `description: NVIDIA Driver image name` `description: NVIDIA GDRCopy driver image name` `description: NVIDIA GPUDirect Storage Driver image name` `description: NVIDIA MIG Manager image name` `description: NVIDIA Sandbox Device Plugin image name` `description: NVIDIA vGPU Device Manager image name` `description: NVIDIA vGPU Manager image name` `description: Node Status Exporter image name` `description: VFIO Manager image name` `description: Validator image name` `driver` `gdrdrv` `gpu-operator` `k8s-cc-manager` `k8s-device-plugin` `k8s-driver-manager` `k8s-kata-manager` `k8s-mig-manager` `kubevirt-gpu-device-plugin` `nvcr.io/nvidia/gpu-operator:v25.10.1` `nvidia-fs` `registry.k8s.io/nfd/node-feature-discovery:v0.18.2` `vgpu-device-manager` `vgpu-manager`
preinstalled-driver	`container-toolkit` `cuda` `dcgm` `dcgm-exporter` `default: nvcr.io/nvidia/driver` `description: CC Manager image name` `description: GDRCopy driver image name` `description: GFD image name` `description: Image represents NVIDIA Driver Manager image` `description: Image represents NVIDIA Driver Manager image name` `description: Image represents image name` `description: Kata Manager image name` `description: NVIDIA Container Toolkit image name` `description: NVIDIA DCGM Exporter image name` `description: NVIDIA DCGM image name` `description: NVIDIA Device Plugin image name` `description: NVIDIA Driver image name` `description: NVIDIA GDRCopy driver image name` `description: NVIDIA GPUDirect Storage Driver image name` `description: NVIDIA MIG Manager image name` `description: NVIDIA Sandbox Device Plugin image name` `description: NVIDIA vGPU Device Manager image name` `description: NVIDIA vGPU Manager image name` `description: Node Status Exporter image name` `description: VFIO Manager image name` `description: Validator image name` `driver` `gdrdrv` `gpu-operator` `k8s-cc-manager` `k8s-device-plugin` `k8s-driver-manager` `k8s-kata-manager` `k8s-mig-manager` `kubevirt-gpu-device-plugin` `nvcr.io/nvidia/gpu-operator:v25.10.1` `nvidia-fs` `registry.k8s.io/nfd/node-feature-discovery:v0.18.2` `vgpu-device-manager` `vgpu-manager`
preinstalled-driver-and-toolkit	`container-toolkit` `cuda` `dcgm` `dcgm-exporter` `default: nvcr.io/nvidia/driver` `description: CC Manager image name` `description: GDRCopy driver image name` `description: GFD image name` `description: Image represents NVIDIA Driver Manager image` `description: Image represents NVIDIA Driver Manager image name` `description: Image represents image name` `description: Kata Manager image name` `description: NVIDIA Container Toolkit image name` `description: NVIDIA DCGM Exporter image name` `description: NVIDIA DCGM image name` `description: NVIDIA Device Plugin image name` `description: NVIDIA Driver image name` `description: NVIDIA GDRCopy driver image name` `description: NVIDIA GPUDirect Storage Driver image name` `description: NVIDIA MIG Manager image name` `description: NVIDIA Sandbox Device Plugin image name` `description: NVIDIA vGPU Device Manager image name` `description: NVIDIA vGPU Manager image name` `description: Node Status Exporter image name` `description: VFIO Manager image name` `description: Validator image name` `driver` `gdrdrv` `gpu-operator` `k8s-cc-manager` `k8s-device-plugin` `k8s-driver-manager` `k8s-kata-manager` `k8s-mig-manager` `kubevirt-gpu-device-plugin` `nvcr.io/nvidia/gpu-operator:v25.10.1` `nvidia-fs` `registry.k8s.io/nfd/node-feature-discovery:v0.18.2` `vgpu-device-manager` `vgpu-manager`
external-nfd	`container-toolkit` `cuda` `dcgm` `dcgm-exporter` `default: nvcr.io/nvidia/driver` `description: CC Manager image name` `description: GDRCopy driver image name` `description: GFD image name` `description: Image represents NVIDIA Driver Manager image` `description: Image represents NVIDIA Driver Manager image name` `description: Image represents image name` `description: Kata Manager image name` `description: NVIDIA Container Toolkit image name` `description: NVIDIA DCGM Exporter image name` `description: NVIDIA DCGM image name` `description: NVIDIA Device Plugin image name` `description: NVIDIA Driver image name` `description: NVIDIA GDRCopy driver image name` `description: NVIDIA GPUDirect Storage Driver image name` `description: NVIDIA MIG Manager image name` `description: NVIDIA Sandbox Device Plugin image name` `description: NVIDIA vGPU Device Manager image name` `description: NVIDIA vGPU Manager image name` `description: Node Status Exporter image name` `description: VFIO Manager image name` `description: Validator image name` `driver` `gdrdrv` `gpu-operator` `k8s-cc-manager` `k8s-device-plugin` `k8s-driver-manager` `k8s-kata-manager` `k8s-mig-manager` `kubevirt-gpu-device-plugin` `nvcr.io/nvidia/gpu-operator:v25.10.1` `nvidia-fs` `vgpu-device-manager` `vgpu-manager`

What Has Been Tested

Choose the question you care about. Not checked means this catalog has no version-specific result; it is not a pass.

Question	Status	Evidence
Can I pull these exact package bytes again?	Checked	Package receipt
What does this chart contain?	Not checked	No linked result
Does the recorded render match Helm?	Not checked	No linked result
Did the supplied values change the render?	Not checked	No linked result
Were hooks, CRDs, or setup steps checked?	Not checked	No linked result
Did this version run on a local Kubernetes cluster?	Not checked	No linked result
Did an OCI delivery through GitOps run?	Not checked	No linked result
Did Helm and ConfigHub reach the same live result?	Not checked	No linked result
Was the result compared on separate clusters?	Not checked	No linked result
Was a ConfigHub promotion tested?	Not checked	No linked result
Did this version string point at changed upstream bytes?	Not checked	No linked result

The committed publication receipt binds this package path and OCI ref to layer sha256:744153b8bc1899fa4b41e893b8b21c5eca1f16781d9f1052d2dace418bc9f0e0 and manifest sha256:35774151264bf1b5998330ca4290ae306e89470c7eb05a4e4c8fc18401c9e155, and records an inspect-result digest.

You can check a pull yourself: the inspect command under Try This Chart prints the package's manifest and layer digests, and they must equal the receipted values above. If they differ, do not use the pulled package.

No version-specific runtime result is claimed here. The component row's readiness, caveats, and live evidence describe only its bold version. For that separate evidence, open the v26.7.1 evidence page.

What You Must Provide

The installer metadata records 27 external-requirement references across these configurations. Inspect the package before choosing a base.

Choose a namespace and target deliberately, supply any listed Secret, CRD, storage, API, or cloud prerequisite, and inspect the rendered YAML before delivery.

Before Production

Run target-specific policy, lifecycle, upgrade, and workload checks. A successful package publication and inspect result does not establish production support or live convergence.

Source And Evidence Files

Record	Open
Retained package source	packages/nvidia/gpu-operator/v25.10.1
Machine-readable listing (default)	site/listings/nvidia-gpu-operator-v25-10-1-default.json
Machine-readable listing (driver-580.126.20)	site/listings/nvidia-gpu-operator-v25-10-1-driver-580-126-20.json
Machine-readable listing (driver-595.91.07)	site/listings/nvidia-gpu-operator-v25-10-1-driver-595-91-07.json
Machine-readable listing (preinstalled-driver)	site/listings/nvidia-gpu-operator-v25-10-1-preinstalled-driver.json
Machine-readable listing (preinstalled-driver-and-toolkit)	site/listings/nvidia-gpu-operator-v25-10-1-preinstalled-driver-and-toolkit.json
Machine-readable listing (external-nfd)	site/listings/nvidia-gpu-operator-v25-10-1-external-nfd.json
Installer metadata	packages/nvidia/gpu-operator/v25.10.1/installer.yaml
Publication receipt	runs/installer-oci/nvidia-gpu-operator/v25.10.1/installer-package-publication-receipt.yaml
Publisher signature	runs/installer-oci-signatures/nvidia-gpu-operator/v25.10.1/signature-receipt.yaml
Sigstore bundle	runs/installer-oci-signatures/nvidia-gpu-operator/v25.10.1/signature.sigstore.json
Version tag	`oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/nvidia-gpu-operator:v25.10.1`
Exact OCI ref	`oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/nvidia-gpu-operator:v25.10.1@sha256:35774151264bf1b5998330ca4290ae306e89470c7eb05a4e4c8fc18401c9e155`
Layer digest	`sha256:744153b8bc1899fa4b41e893b8b21c5eca1f16781d9f1052d2dace418bc9f0e0`
Manifest digest	`sha256:35774151264bf1b5998330ca4290ae306e89470c7eb05a4e4c8fc18401c9e155`

Technical notes and disclaimers

The plain-objects script applies the objects and ends. It does not wait for the workloads to start. The script does not run the steps the plan names for an upgrade or a delete. A cluster with no GPUs shows that the objects apply. It does not show the workload using a GPU.