--- title: "Disconnected GPU Deployment: Local Images Do Not Supply Every Dependency" description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20." canonical: "https://www.leviathansystems.co/articles/disconnected-gpu-deployment-artifacts-and-licenses" last-updated: "2026-10-20" --- # Disconnected GPU Deployment: Local Images Do Not Supply Every Dependency Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20. A restricted-network software offer should explain how its required images, any driver-installation OS packages and any applicable licensed-product service are supplied. Mirroring application images addresses one part of that purchase. Compare what the supplier makes available locally, what the customer's appointed teams retain and who supplies the dependencies needed for later maintenance or a replacement node. ## Separate image availability from package availability NVIDIA's GPU Operator air-gapped guide, consulted on October 20, 2026, distinguishes image retrieval from the conventional driver container's OS-package downloads. It describes a local image registry and a local package repository as separate supply arrangements. The registry supplies container images. The package repository supplies distribution packages requested during the applicable driver installation. Making an application image available locally does not answer where that installation will obtain its packages. Even a locally available driver-container image can leave a subsequent package request unresolved. For a buying comparison, ask which software route the supplier has actually priced and which dependencies that route introduces. Application images alone are a narrower delivery than the required platform and application image set. A package source may already be supplied by the customer's platform team, or it may be work that another provider needs to include. The customer's restriction level and permitted transfer process are inputs to this comparison. Its appointed platform and application teams determine the required supply and verification. An offer should describe its fit to those choices without silently assuming that the site will change them. References: [N1](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/install-gpu-operator-air-gapped.html) ## Check whether precompiled drivers change the requirement There is an important exception to the package-repository requirement. NVIDIA documents precompiled driver containers that avoid downloading kernel headers, compiler tooling and OS packages for that driver installation. The consulted precompiled-driver page limits support by operating system, kernel and driver versions; it also excludes NVIDIA vGPU and GPUDirect Storage. A supplier proposing this route should therefore identify the applicable supported combination and required features. The word precompiled is insufficient to establish that the buyer's environment qualifies. Equally, an offer should not add a driver-package mirror solely by copying a requirement from the conventional route when the selected supported route removes that need. This changes what the buyer is purchasing. One proposal may include an ongoing package source for its conventional driver route. Another may rely on supplying an applicable precompiled driver image. Ask what each provider will supply again when the environment changes. The exception concerns that driver-installation dependency; application dependencies and any separately applicable licensed-product arrangement still need their own assessment. References: [N2](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/precompiled-drivers.html) ## Identify a license-service dependency only where it applies NVIDIA's License System User Guide v4.0.0, updated October 19, 2026, describes a Delegated License Service, or DLS, hosted on premises and accessible from a private network. Its DLS description separately identifies license supply from the NVIDIA Licensing Portal to that disconnected service. For a selected licensed product using this arrangement, there are two relationships to account for: the client uses the local service, and that service receives its applicable license supply. The presence of application images or distribution packages establishes neither relationship. Ask the appointed product and licensing owners whether this requirement applies and who will provide the arrangement. This does not establish a paid-license requirement for every GPU, CUDA application or GPU Operator installation, nor make DLS the required choice for every restricted network. The relevant product, release and selected licensing model determine the question. For an applicable DLS proposal, compare who supplies and maintains the service with who is responsible for its license supply. Assigning both to the customer's existing team may fit the intended purchase. Leaving them unmentioned while promising a complete licensed application environment leaves the buyer unable to assess that promise. References: [N3](https://docs.nvidia.com/license-system/latest/nvidia-license-system-user-guide/index.html#about-delegated-license-service-dls-instances) ## Compare two application images delivered for three nodes Consider a fictional deployment of three GPU nodes. Offer A supplies two locally available application images. Its chosen driver route still requires an OS-package source, and the example separately stipulates a licensed NVIDIA application whose arrangement uses DLS. These are invented purchasing assumptions, not a product recommendation or an observed deployment. A calls its delivery an offline software package but does not identify a package source or the applicable license-service arrangement. The two images may be exactly the application images requested. That fact cannot establish the rest of the proposed environment. Two available images are not two complete node environments; the example specifies no one-image-per-node relationship. Nor do three nodes establish three license units. This example supplies no licensing metric or entitlement quantity. The buyer must obtain the actual requirement from the responsible product and licensing owners rather than turn a hardware count into a software-rights conclusion. Revised Offer B retains the same three nodes and two application images. It adds supply of the agreed platform images and the OS packages required by its identified conventional driver route. It expressly assigns hosting and operation of the customer's local registry and package repository to the customer's platform team. That team identifies the services it will provide. B also identifies the separately appointed licensing team as responsible for the stipulated DLS arrangement and its license supply. The application team retains integration and the agreed workload verification. B's supplier prices initial artifact supply; a continuing supply option is stated separately. The useful improvement is the division of work. The buyer can see which dependencies B supplies and which customer services the proposal relies on. B cannot promise successful integration from its file list, and this comparison contains no test result. If the appointed customer teams cannot supply their assigned services, the buyer still needs another arrangement. A could become an adequate narrower offer if those teams already supply every applicable dependency outside its two images and confirm that division. B is worth more only to the extent its additional supply or continuing work meets a requirement the buyer would otherwise have to cover. ## Price the next replacement node and software change A delivery can cover the initial artifacts while leaving the next request unpriced. Compare the offers using a replacement-node scenario: the customer needs to prepare a replacement for one of the three nodes after the original delivery team has left. Which organization supplies the required software material, and which organization makes it available through the retained local services? For B's conventional route, ask whether its supply option covers the required driver packages as well as images. For a proposed precompiled route, ask who reassesses the applicable image when the replacement has a different approved OS or kernel. A copy retained from the initial delivery should not be treated as an answer for an unspecified changed platform. Then consider an application change. If the application owner selects a new release, who determines the revised dependencies and supplies the agreed material? Where licensed-product requirements apply, who assesses the effect on the selected service arrangement? The initial delivery price should make clear whether that later assessment and supply are included, separately priced or retained by the customer. These scenarios expose a commercial difference that a larger archive does not necessarily solve. A supplier may offer one delivery, continuing artifact supply, or a wider operating service. The buyer should compare the service period and assigned work it needs. Receiving files does not engage a supplier to maintain the customer's repositories, license service or cluster. Keep supply evidence and integration evidence distinct. Identifying the required material and its source makes the proposal assessable. The appointed software team still needs the agreed evidence for the intended environment and application use. A proposal can resolve a missing supply responsibility while leaving that later verification open. References: [N2](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/precompiled-drivers.html) ## Connect the software recipient to the physical deployment When the project also requires physical installation, identify the equipment and connection records the appointed platform team needs to receive. Aligning that handoff with the software team's equipment references helps the two scopes meet without treating physical completion as application acceptance. Leviathan's Complete Physical Deployment service covers a defined package of receiving, rack integration, agreed hardware QA, onsite installation and cabling. Use the service and project-inquiry links below to discuss that physical package and its recipient. Bring a nonconfidential equipment and site outline, the requested physical work and the receiving team's handoff requirements. Software supply, repository operation, license-service administration and application integration remain with their separately appointed providers in this comparison. ## Primary sources - [N1 — NVIDIA GPU Operator: Install in Air-Gapped Environments](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/install-gpu-operator-air-gapped.html). Checked 2026-10-20. Distinguishes image supply and conventional driver-package supply in the documented restricted-network arrangements. - [N2 — NVIDIA GPU Operator: Precompiled Driver Containers](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/precompiled-drivers.html). Checked 2026-10-20. Qualifies the driver-package download exception by supported operating system, kernel, driver and feature coverage. - [N3 — NVIDIA License System User Guide: Delegated License Service](https://docs.nvidia.com/license-system/latest/nvidia-license-system-user-guide/index.html#about-delegated-license-service-dls-instances). Checked 2026-10-20. Private DLS hosting and separate Licensing Portal supply for applicable licensed products; v4.0.0 guide updated October 19, 2026. ## Related Leviathan resources - [Compare GPU Operator and device-plugin responsibilities](/articles/nvidia-gpu-operator-versus-device-plugin-scope) - [Separate preinstalled software from site commissioning](/articles/gpu-server-preinstalled-software-vs-site-commissioning) - [Plan the later cluster management handoff](/articles/gpu-cluster-management-handoff) - [Assess driver, Toolkit and container compatibility](/articles/cuda-driver-toolkit-container-compatibility-buying) - [Scope complete physical infrastructure deployment](/services/turnkey-gpu-deployment) - [Discuss the physical project and software-team handoff](/contact?service=turnkey-gpu-deployment&from=%2Farticles%2Fdisconnected-gpu-deployment-artifacts-and-licenses) ## Scope the physical package and its receiving team Share the equipment, site, requested physical work and the appointed platform team's handoff requirements to discuss the physical deployment scope and availability. [Discuss the scope](/contact?service=turnkey-gpu-deployment&from=/articles/disconnected-gpu-deployment-artifacts-and-licenses)