DGX Spark/Guides/AI Workbench and JupyterLab
Guide · November 2026

NVIDIA AI Workbench and JupyterLab on a DGX Spark: what works on arm64 in November 2026

By Samuel Seidel · Published November 7, 2026 · Sources checked November 7, 2026

NVIDIA AI Workbench is a free desktop app for Windows, macOS and Ubuntu that builds Git-managed project containers on a "location", your laptop or a remote Linux box such as a DGX Spark, and opens JupyterLab, VS Code or Cursor inside them. It runs on a Spark: release 2026.06.5 (5 August 2026) ships an aarch64 CLI, and NVIDIA's Workbench base images on NGC have arm64 builds, the newest PyTorch one with PyTorch 2.11 and CUDA 13.1 (registry labels read 7 November 2026). NVIDIA has, though, dropped it from the Spark playbooks: none of the 29 on build.nvidia.com/spark uses it, and some older example projects do not build on ARM. If you only want notebooks, the DGX Dashboard's built-in JupyterLab or plain JupyterLab 4.6.6 is less work. On a rented GPUwerk Spark, JupyterLab inside the container works; Workbench's container management does not, because there is no Docker socket.

OptionWhat you getNeedsOwned SparkRented Spark
AI WorkbenchPer-project containers from .project/spec.yaml, Git tracking, JupyterLab and IDE launchDocker or Podman on the host, non-root sudo user, SSH keyYesNo
DGX Dashboard JupyterLabOne venv per working directory, recommended packages, per-user portDGX OS with the dashboard serviceYes, built inNo
Plain JupyterLabWhatever you pip install in a venvPython 3YesYes

Requirements from NVIDIA's AI Workbench remote-location reference and the DGX Spark user guide (updated 4 November 2026); rental limits from the tenant environment page. Read 7 November 2026.

What is NVIDIA AI Workbench in 2026?

A client app plus a service that turns a Git repository into a reproducible container environment. Per NVIDIA's introduction, a project is a repo whose .project/spec.yaml (similar to devcontainer.json) defines the container; a location is any machine with Workbench installed; and the nvwb CLI has feature parity with the Desktop App. Workbench handles drivers, the container toolkit, builds and SSH tunnels, and records package installs back into the project files. Running coding agents in a sandboxed project container is now the first use case NVIDIA lists. The 2026 releases added a Build Assistant that diagnoses failed container builds (2026.03.3, 9 April) and an onStart.bash script that runs at each container start (2026.06.5, 5 August), per the release notes. Release 2026.06.5 is Desktop App 0.170.22-7, CLI 0.76.4-5 and Service 0.100.3-5.

The support matrix never names the Spark or arm64. It supports remote installs on Ubuntu 22.04, 24.04 and 26.04, and says Workbench "has no inherent dependencies on GPUs, drivers, or CUDA versions": the CUDA in the container just has to suit the host driver. DGX OS 7 is Ubuntu 24.04 with driver 580.178.04 and CUDA 13.0.3 in NVIDIA's current release notes. The one Spark-specific line I found is in release 2025.09.5: "Now handling GPU utilization on Spark systems."

How do I install Workbench on a Spark and use it from a laptop?

Either let NVIDIA Sync do it, or install the CLI on the Spark over SSH and add it as a remote location in the Desktop App. With Sync, clicking AI Workbench for a connected device checks for Workbench on the Spark, installs it if missing, adds the location and opens it, per NVIDIA's Sync integration page, which calls the integration "still a work in progress" and notes that the location gets named sync-<ip> and defaults to Docker. Sync's own setup is in the NVIDIA Sync and remote access guide.

The manual install, from the remote install page, run as a non-root user with sudo; it needs 500 MB for the app and 40 GB for project containers:

mkdir -p $HOME/.nvwb/bin && \
curl -L https://workbench.download.nvidia.com/stable/workbench-cli/$(curl -L -s https://workbench.download.nvidia.com/stable/workbench-cli/LATEST)/nvwb-cli-$(uname)-$(uname -m) --output $HOME/.nvwb/bin/nvwb-cli && \
chmod +x $HOME/.nvwb/bin/nvwb-cli && \
sudo -E $HOME/.nvwb/bin/nvwb-cli install

On 7 November 2026 the LATEST file pointed to 0.76.4-5, and the nvwb-cli-Linux-aarch64 binary it resolves to on a Spark existed (55.8 MB, dated 9 September 2026). The installer offers to install GPU drivers; on DGX OS a driver is already present, and Workbench says it "does not replace or change an existing driver". Then add the Spark in the Desktop App as a remote location with key-based SSH; password SSH is not supported. Opening it creates two tunnels, the Workbench service on local port 10001 and the reverse proxy for JupyterLab and other web apps on 10000, per the remote locations reference.

Which base images have arm64 builds?

All of NVIDIA's current Workbench base images do; pick by CUDA version. I read each tag's manifest list and image labels from the NGC registry:

Image and tagContents (image label)CUDAUbuntuarm64 size, compressedBuilt
ai-workbench/pytorch:1.0.10PyTorch 2.11, JupyterLab 4.5.7 or later13.124.0410.58 GB2026-05-14
ai-workbench/python-cuda130:1.0.1Python, JupyterLab 4.3.613.022.042.69 GB2026-01-12
ai-workbench/python-cuda129:1.0.2Python, JupyterLab 4.3.612.922.043.21 GB2026-01-12
ai-workbench/python-cuda122:1.0.9Python, JupyterLab 4.3.612.222.042.15 GB2026-01-12
ai-workbench/python-basic:1.0.9Python, JupyterLab 4.3.6, no CUDAnone22.040.90 GB2026-01-12
ai-workbench/pytorch:1.0.6"A Pytorch 2.6 Base with CUDA 12.6.3"12.6.324.049.24 GB2025-02-05

From nvcr.io/nvidia/ai-workbench/* manifests and the com.nvidia.workbench.* labels of each arm64 image, read 7 November 2026; sizes are the sum of compressed layers and unpack larger. Every tag listed also has an amd64 build. NVIDIA's base environments page still lists only CUDA 11.7, 12.0 and 12.2 Python images, so the registry is more current than the docs.

The CUDA column matters. In November 2025 an owner on pytorch:1.0.6 got a warning that the "NVIDIA GB10 with CUDA capability sm_121 is not compatible with the current PyTorch installation", which listed only sm_80, sm_86 and sm_90 (thread 350476). Start new projects from pytorch:1.0.10 or python-cuda130 and run one CUDA cell before building on it; the PyTorch on DGX Spark guide covers which wheels support the GB10.

Bringing your own image means adding Workbench's labels. In the same thread, an owner who tried nvcr.io/nvidia/pytorch:25.10-py3 got "required base environment label is not set: 'com.nvidia.workbench.schema-version'". The base environments page lists the five required labels: name, description, schema-version v2, image-version and cuda-version.

What breaks on a Spark?

Old examples, profiling, and shared use; the core create-build-run loop works. From NVIDIA's developer forum:

Which Spark playbooks use AI Workbench?

None, as of 7 November 2026. The build.nvidia.com/spark index listed 29 playbooks that day, from Open WebUI and vLLM to NemoClaw agents and NCCL, and the page does not mention Workbench at all. The October 2025 RAG Application in AI Workbench playbook survives only in the GitHub repo; its build.nvidia.com address returns a 308 redirect to the Hybrid RAG example, the one NVIDIA staff said does not build on ARM. That README also needed a Tavily key for web search, which a forum user ruled out because it sends user queries to a third-party service. If you want a worked RAG stack on a Spark, the Open WebUI setup and the embeddings and vector search guide are closer to what NVIDIA now ships.

How do I use the DGX Dashboard's JupyterLab?

Open the dashboard, click Start in the JupyterLab panel, and wait for Running. Per NVIDIA's dashboard playbook (updated 31 July 2026), the first start creates /home/<user>/jupyterlab, builds a virtual environment and writes the package list to requirements.txt; a new working directory gets a new environment. The November 2025 release moved it to CUDA 13.0.2 and a current PyTorch. Each Linux user has a JupyterLab port listed in /opt/nvidia/dgx-dashboard-service/jupyterlab_ports.yaml, and remote use means tunnelling that port plus 11000 for the dashboard, or letting Sync do it; the commands are in the remote access guide linked above. NVIDIA's sample notebook in that playbook starts by filtering warnings matching "cuda capability", which suggests the sm_121 warning still shows up in places.

Is plain JupyterLab the better choice?

For one person and one environment, yes: fewer moving parts, and it runs the same on an owned Spark and a rental. JupyterLab 4.6.6 went to PyPI on 6 November 2026. Use a venv on DGX OS (system pip refuses, as above), bind to localhost, and tunnel:

python -m venv ~/venvs/jl
source ~/venvs/jl/bin/activate
pip install jupyterlab
jupyter lab --ip 127.0.0.1 --port 8890 --no-browser

The venv and pip install jupyterlab lines are from the Python and JupyterLab docs; the flags are the ones NVIDIA's own Workbench image label uses (--allow-root --port 8888 --ip 0.0.0.0 --no-browser), with the address changed to 127.0.0.1 so nothing listens on the network and the port moved off 8888. Pick Workbench instead when several projects need different CUDA or library versions side by side, or when you want the environment versioned in Git for someone else to rebuild.

What works on a rented Spark?

JupyterLab yes, Workbench no. Per the tenant environment page, a rental is a Docker container on a dedicated Spark with the GPU passed through: you are root, pip and conda work, but there is no Docker socket, no privileged mode and no systemd. Workbench needs a container runtime it controls on the host and a non-root sudo user, so its project containers cannot start there, and the dashboard's JupyterLab is a host service you do not have. Install JupyterLab the same way, keep the venv and notebooks under /workspace, add --allow-root because you are root (Jupyter Server's allow_root setting defaults to False, which is why NVIDIA's label carries the flag), run it in tmux or from the startup hook, and connect with ssh -N -L 8890:127.0.0.1:8890 spark as in the SSH key guide. Port 8888 is taken by the model server on model-preset instances, hence 8890.

My recommendation: on an owned Spark, use the dashboard's JupyterLab for quick experiments and Workbench only if its per-project containers solve a real versioning problem for you, starting from pytorch:1.0.10. Expect to adapt any example project yourself. On a rental, plain JupyterLab in /workspace is the whole answer.

FAQ

Does NVIDIA AI Workbench work on a DGX Spark?

Yes. AI Workbench's CLI ships an aarch64 Linux build (version 0.76.4-5 in release 2026.06.5), and NVIDIA's Workbench base images on NGC carry arm64 builds; the PyTorch 1.0.10 image has PyTorch 2.11 and CUDA 13.1. Older example projects and some custom containers do not build on ARM, and two users sharing one Spark location was unsupported when NVIDIA last answered in December 2025.

Is there a DGX Spark playbook for AI Workbench?

Not any more. On 7 November 2026 the build.nvidia.com/spark index listed 29 playbooks and none of them used AI Workbench. The old RAG Application in AI Workbench address now redirects to NVIDIA's Hybrid RAG example on GitHub, which NVIDIA staff said in January 2026 does not build on ARM because of its Hugging Face TGI base image.

How do I use JupyterLab on a DGX Spark?

The quickest way is the DGX Dashboard: click Start in its JupyterLab panel and it creates a virtual environment in a jupyterlab folder in your home directory with a requirements.txt of recommended packages. Remotely, tunnel the dashboard's port 11000 and your per-user JupyterLab port, or let NVIDIA Sync do it. Plain JupyterLab 4.6.6 from pip in a venv also works.

Can I run AI Workbench on a rented GPUwerk Spark?

Not its container management. A GPUwerk rental is itself a Docker container with no Docker socket and no privileged mode, and AI Workbench needs a container runtime on the host plus a non-root user with sudo. JupyterLab installed with pip inside the rental works; bind it to 127.0.0.1 and reach it through an SSH tunnel.

Which AI Workbench base image should I use on a DGX Spark?

Start from nvcr.io/nvidia/ai-workbench/pytorch:1.0.10, built 14 May 2026 with PyTorch 2.11, CUDA 13.1 and Ubuntu 24.04 per its image labels. The older 1.0.6 image, with CUDA 12.6.3, printed a warning that the GB10's sm_121 was not supported, an owner reported in November 2025. Python with CUDA 13.0 is the lighter option at 2.69 GB.

Sources

Every figure above is attributed to its source in the sentence or table where it appears. Pages were read on 7 November 2026 unless a date says otherwise.

First top-up: pay $20, get $30 in credit

Try the notebook before the hardware.

A rented Spark runs JupyterLab in your own container on the same GB10, so you can check that your notebooks and packages work on arm64 before you buy one.

A dedicated DGX Spark in the EU, $0.79/hour, billed per minute. $30 of credit is about 37 hours of compute.

Create account What runs inside a rental