Image Mirroring
All required self-hosted NVCF artifacts (see self-hosted-artifact-manifest) must be available to be pulled by pods in your Kubernetes cluster. The deployment bundles are nvcf-self-managed-stack for the control plane, nvcf-compute-plane-stack for the compute plane, and nvcf-observability-stack for standalone shared observability. This page provides examples on how to pull artifacts from NGC and push them to your desired registry.
Mirroring images is not the same as configuring image pull secrets. This page covers how to copy NVCF artifacts into your registry. If your registry is private, Kubernetes also needs credentials to pull those images at runtime. For instructions on configuring image pull secrets for the NVCF control plane pods, see control-plane-image-pull-secrets in the installation guide.
Mirroring Workflow
Use this page to mirror NVCF artifacts into the registry your cluster can access. The examples below show the commands for pulling from NGC and pushing to a private registry such as ECR, Harbor, or another OCI-compatible registry.
For ECR mirroring, make sure your AWS credentials have permission to create repositories and push images. Verify access with aws sts get-caller-identity.
Prerequisites
NVCF artifacts are available from the public nvidia/nvcf namespace in NGC.
You can mirror these artifacts using a Personal API key from any NGC
organization. Keep nvidia/nvcf as the source namespace in the pull commands,
regardless of the organization used to create your key.
-
Navigate to NGC API Keys and select your organization.
-
Create a Personal API key with the required scopes to pull entities.
-
Set the NGC API key as an environment variable for use in subsequent commands:
LLS-Specific Artifacts
If you plan to deploy Low Latency Streaming (LLS), you must mirror the following additional artifacts beyond the core NVCF control plane:
Container Images:
streaming-proxy- Streaming Proxy container for streaming
Helm Charts:
gdn-streaming- GDN Streaming Proxy Helm chart
Optional (for streaming workloads):
- Streaming application images (e.g.,
usd-composer)
See self-hosted-lls-installation for LLS deployment instructions.
Pulling Artifacts from NGC
Important: The examples below show how to pull individual artifacts. You must pull each image, chart, and resource listed in the self-hosted-artifact-manifest individually. These examples demonstrate the process for one artifact of each type - you will need to repeat these steps for every artifact required for your deployment.
Complete the following for each artifact:
- Pull each container image from NGC
- Pull each Helm chart from NGC
- Pull each required resource bundle from NGC
- Push each artifact to your target registry (ECR, Harbor, etc.)
See the self-hosted-artifact-manifest for the complete list of all required artifacts.
Pulling Images
Platform Architecture Mismatch
When pulling images, Docker pulls the architecture matching your local machine by default. If you’re running on an Apple Silicon Mac (arm64) but deploying to an amd64 cluster (most EKS/GKE clusters), you must specify the target platform:
Failing to specify the correct platform will result in exec format error when pods attempt to start. See image-mirroring-troubleshooting for more details.
-
Login using the Personal API key you have generated in the previous step:
-
Pull the image (specify platform matching your target cluster):
Pulling Helm Charts
Public NVCF charts in the nvidia/nvcf namespace are NGC Helm
charts. They are not public OCI artifacts. Pull them from
https://helm.ngc.nvidia.com/nvidia/nvcf.
The example below uses the selected NVCA Operator chart. For another chart, set its name, version and pull reference from the artifact manifest. The commands save one archive for the registry-specific push steps below. Repeat for each chart that you need to mirror.
The temporary Helm configuration keeps these credentials separate from your existing repository configuration. The downloaded archive remains in the current directory.
Other Repository-based Helm Charts (Non-OCI)
The GPU Operator and the Omniverse OVDC, OVCC, storage-service, and discovery-service charts are also available from traditional Helm repositories rather than OCI registries. Use the chart versions and repositories selected for your release. The public repository below applies to published artifacts; for prerelease artifacts, use the repository and credentials supplied with that release.
OVDC uses chart ovderivedcache; OVCC uses chart ovcontentcache. See the
OVDC deployment guide
and OVCC deployment guide.
Use an NGC_API_KEY with access to the nvidia/omniverse chart repository.
The examples use OVDC chart/image 6.0.1 and OVCC chart 4.0.4 with image
usd-content-cache:3.0.2. Chart and image versions are independent. Retain
image.tag: "3.0.2" in the OVCC Helm values; chart 4.0.4 defaults to image 3.0.1.
Use a scoped, short-lived key. These Bash examples keep Helm credentials in temporary configuration and remove it when the subshell exits, including on failure. Existing Helm repository entries and registry credentials are preserved.
Public NVCF charts, the GPU Operator and related components (gpu-operator-validator, k8s-device-plugin), plus the Omniverse OVDC/OVCC/storage charts, are available from public NVIDIA Helm repositories for published versions. Check the selected release’s availability before mirroring. You can either:
- Pull directly from the public repository at runtime (simplest approach)
- Mirror to your private registry for air-gapped environments (see below)
Converting Non-OCI Charts for ECR
To push repository-based Helm charts to Amazon ECR (which requires OCI format), you must convert them:
The example stores the chart in nvcf-self-hosted/charts/ovderivedcache,
separate from the image at nvcf-self-hosted/ovderivedcache, so their tags
cannot collide. Configure the chart and image repositories separately.
Obtain stack packages
Use Consume an NVCF release for the selected stack packages or an umbrella archive. That guide owns the download commands. Continue here when charts or images need a mirror.
Run that guide in a separate terminal. It enables fail-fast mode and changes
the working directory. Push charts from this terminal so CHART_NAME,
CHART_ARCHIVE and the downloaded archive remain available.
Downloading nvcf-cli
The nvcf-cli is a command-line interface for managing NVIDIA Cloud Functions in self-hosted deployments.
Install and configure the NGC CLI
with your Personal API key before downloading it.
Use the CLI version shown in the artifact manifest for this stack release.
Download and extract:
The extracted directory contains:
nvcf-cli- The CLI binary.nvcf-cli.yaml.template- Configuration templateexamples/- Sample configuration files for different environmentsUSAGE-GUIDE.md- Detailed usage documentation
See self-hosted-cli for detailed configuration instructions
If you don’t have access to this repository, contact your NVIDIA representative.
Pushing to Your Registry
Ensure all artifacts listed in the self-hosted-artifact-manifest are mirrored to your registry before beginning the installation process.
Example: Pushing to Amazon ECR
This example assumes you’re configured and authenticated using the AWS CLI.
Identify Your AWS Account ID
The examples below use <aws-account-id> as a placeholder. To get your AWS account ID, run:
ECR Repository Naming Convention
The Helm templates expect images at: {{ registry }}/{{ repository }}/image-name:tag
For example, with environment configuration:
The resulting image path would be: <aws-account-id>.dkr.ecr.us-east-1.amazonaws.com/nvcf-self-hosted/nats-box:0.19.7-nonroot
In ECR, you must create repositories with the full path including the prefix, e.g., nvcf-self-hosted/notary-service, nvcf-self-hosted/nats-box, etc.
Initial Setup
Push an Image to ECR
Push a Helm Chart to ECR
Use the archive and CHART_NAME from Pulling Helm Charts.
Replace <aws-account-id> with your AWS account ID (run aws sts get-caller-identity --query Account --output text). The REPO_PREFIX value must match your global.image.repository setting in your environment config. Adjust the region as needed.
Example: Pushing to Volcano Engine Container Registry
This example shows how to push images and Helm charts to Volcano Engine Container Registry (CR) using the web console, Docker commands and Helm commands.
Volcano Engine CR Repository Naming Convention
The Helm templates expect images at: {{ registry }}/{{ repository }}/image-name:tag
For example, with environment configuration:
The resulting image path would be: cr-example-cn-beijing.cr.volces.com/nvcf-self-hosted/nats-box:0.19.7-nonroot
Docker Authentication
Replace cr-example-cn-beijing.cr.volces.com with your Volcano Engine CR endpoint, your-username with your username, and your-password with your password.
Navigate to your Volcano Engine Container Registry instance web console to get the username and password. If you haven’t set the password, you can set it by clicking “Set Repository Instance Password”.
Push an Image to Volcano Engine CR
Push a Helm Chart to Volcano Engine CR
Use the archive from Pulling Helm Charts.
Troubleshooting
exec format error
Symptom: Pods fail to start with Init:CrashLoopBackOff or CrashLoopBackOff status. Checking the logs shows:
or
Cause: This error occurs when container images were pulled/pushed with an architecture that doesn’t match your cluster’s node architecture. This commonly happens when:
- Mirroring from an Apple Silicon Mac (arm64) to an amd64 EKS/GKE cluster
- Mirroring from an Intel/AMD machine (amd64) to an arm64 cluster (e.g., AWS Graviton)
Solution:
-
Delete the incorrectly mirrored images from your registry (e.g., ECR):
-
Clean local Docker cache to ensure fresh pulls:
-
Re-mirror images with the correct platform:
When pulling images, explicitly specify the target platform:
Then re-tag and push to your registry.
-
Force Kubernetes to re-pull images by either:
- Setting
imagePullPolicy: Alwaystemporarily in your Helm values - Deleting and redeploying the affected StatefulSets/Deployments
- Setting