DGX Dashboard on DGX Spark: port 11000, login, remote access from a laptop and headless setup

DGX Dashboard port, address and login

DGX Dashboard runs on the DGX Spark itself, on port 11000, and opens in a browser at http://localhost:11000. You sign in with the Linux username and password created in the setup wizard; we found no NVIDIA document that gives a default login. From a laptop, NVIDIA Sync opens the dashboard through an SSH tunnel it sets up for you, and without Sync an SSH tunnel that forwards port 11000 does the same.

NVIDIA’s DGX Dashboard playbook (last updated 31 July 2026) describes it as “a web application that runs locally on your hardware platform” with “a graphical interface for system updates, resource monitoring, and an integrated JupyterLab environment”. Its login step asks for “your hardware platform system username” and “your system password”. The user guide’s first boot chapter (updated 10 September 2026) has you “Create your username and password for system access”, and its dashboard chapter adds that updates and changing the device name need sudo access: “The account created during initial setup will have access.” The credentials NVIDIA prints for each Spark are the name and password of the setup hotspot. Our DGX Spark getting started guide walks through the wizard itself; this article covers the dashboard, remote access and running a Spark without a display.

What DGX Dashboard does, and where to find it

After login, the playbook describes “the main dashboard with panels for JupyterLab management, system monitoring, and settings”. The table maps common tasks to the controls NVIDIA names.

NVIDIA DGX Dashboard playbook on build.nvidia.com (updated 31 July 2026) and DGX Spark user guide, DGX Dashboard chapter (updated 10 September 2026), read on 16 October 2026.

On the Spark’s own desktop, the user guide has you click “Show Apps” in the bottom left corner of the Ubuntu desktop and pick the DGX Dashboard shortcut, which opens the default browser. Updates show up as a banner or on the Settings page. NVIDIA warns that “System updates upgrade packages and firmware (when available) and trigger a reboot”, and that afterwards “the only rollback is to restore from a system backup or recovery media”. NVIDIA calls the dashboard “the primary and recommended way to perform system updates”. The update guide’s manual route is sudo apt update and sudo apt dist-upgrade for packages, sudo fwupdmgr refresh and sudo fwupdmgr upgrade for firmware, then sudo reboot.

How to connect a DGX Spark to a laptop

All documented routes from a laptop go over SSH, either managed by NVIDIA Sync or typed by hand.

NVIDIA Sync user guide (chapters updated 2 September 2026), NVIDIA’s connect playbook “Use NVIDIA Sync to Connect Remotely to Your AI Compute” (updated 24 September 2026), DGX Dashboard playbook (updated 31 July 2026) and DGX Spark user guide (updated 10 September 2026), read on 16 October 2026.

NVIDIA Sync runs on the laptop, which the connect playbook requires to be Windows 11, macOS or Ubuntu 24.04 or higher. For the first connection, “Your Spark must be on the same network as your laptop”. You pick the Spark from the devices Sync discovers, or add it by name, hostname or IP address, SSH port (22 by default), username and password. The playbook states: “Your password is used temporarily for set up and is not logged or stored.” Sync then manages key-based access and can add your account to the Docker group on the Spark. Its applications include a terminal, DGX Dashboard and Resource Monitor, plus code editors such as Cursor and NVIDIA AI Workbench, and a custom application binds a port of your choice between the Spark and the laptop.

A Spark broadcasts its name over mDNS, for example spark-abcd.local. Where the network blocks mDNS, NVIDIA’s troubleshooting table says to use the IP address instead. The manual route is one command: ssh -L 11000:localhost:11000 followed by <username>@<hostname>.local, or by <username>@<IP address>, after which the dashboard opens at http://localhost:11000 on the laptop. On macOS, NVIDIA’s DGX Spark FAQ notes that third-party terminal applications need local network access switched on in the system settings before they can reach the Spark.

For access away from the office, Sync’s Tailscale integration needs a Tailscale account, and the playbook notes that Tailscale sign-up runs through a third-party identity provider. The Tailscale client is installed on the Spark, and the laptop needs no separate Tailscale app.

We supply DGX Spark Founders Edition systems, with deployment by our engineering partner Vixen.UNO if you want it. Describe how your developers will reach the Sparks, and we reply within one business day with a configuration and a quote.

DGX Spark headless setup over the hotspot

A Spark can be set up and used without a display, keyboard or mouse. NVIDIA’s Quick Start Guide calls this route “Configuring as a network connected compute device”. Its card lists three values for each Spark: “Hotspot SSID: spark-<unique name>”, “Hotspot password: <unique password>” and “System Setup Page: http://spark-<unique name>.local”. The user guide says the SSID and password are “printed on a sticker attached to the Quick Start Guide”. Keep that card with the asset record, since the hotspot password is unique to each Spark.

You join the hotspot from a laptop, open the setup page, and the wizard, which runs in the laptop’s browser, asks among other steps for the Wi-Fi network the Spark should join. If the laptop is on the hotspot but cannot open the setup page, NVIDIA’s FAQ says to set the Wi-Fi network profile to private and switch on network discovery and file and printer sharing on Windows, and to allow the browser local network access on macOS. The FAQ adds that “The DGX Spark will only broadcast the SSID before the initial setup is complete”, so a Spark that is already set up shows no hotspot.

NVIDIA documents a further failure point after the Spark has joined your network. If the hotspot has gone and the laptop cannot reach the Spark, the first boot chapter says “the Spark did join the network but your laptop can’t communicate with it”, and names device isolation, a different network or mDNS not working as causes; if the setup fails, “you must connect a display/keyboard/mouse to continue”. For a Spark that moves to another site, the FAQ’s procedure is an Ethernet cable to the router, SSH or NVIDIA Sync by hostname or, if that does not resolve, by the IP address the router shows, and nmcli to configure the new Wi-Fi network.

From headless setup to a first JupyterLab notebook

This sequence starts with a Spark in its box and ends with a notebook running on it, opened from a laptop.

1. Connect Ethernet if you use it, then the power adapter last, since the Spark starts as soon as it has power.
2. On the laptop, join the hotspot named on the Quick Start Guide and open the System Setup Page it lists.
3. Complete the wizard, create your username and password, and do not switch the Spark off while it installs and reboots.
4. Put the laptop on the same network as the Spark, install NVIDIA Sync and add the Spark by its hostname or IP address.
5. In Sync, click Connect and then DGX Dashboard; the dashboard opens at http://localhost:11000.
6. Sign in with your Linux username and password, and click Start in the JupyterLab panel.
7. Wait until the status passes Starting and Preparing and shows Running; click Open In Browser if no tab opens.
8. In JupyterLab, choose File, New, Notebook and the Python 3 (ipykernel) kernel, and run a first cell.

NVIDIA estimates its DGX Dashboard playbook, which includes an image generation test in such a notebook, at 30 minutes, longer on the first JupyterLab launch and the first model download. Without Sync, step 5 becomes an SSH tunnel with a second -L <port>:localhost:<port> for the port listed for your account in jupyterlab_ports.yaml.

JupyterLab on DGX Spark for several users

JupyterLab is per account. NVIDIA’s user guide states that “Each user account on the device is assigned a port”, listed in the file jupyterlab_ports.yaml under /opt/nvidia/dgx-dashboard-service, and that “To access JupyterLab remotely, you must tunnel it just like the dashboard itself”. NVIDIA Sync manages that tunnel. On first start, the dashboard creates the working directory /home/<USERNAME>/jupyterlab, sets up a virtual environment in it and records the installed packages in a requirements.txt file there. To change the working directory, you stop JupyterLab, change the path and start it again, which creates a new, separate environment.

For a team of four developers on one Spark, that means four Linux accounts, four JupyterLab ports and four separate environments, while all four notebooks share the same 128 GB of memory and the same GPU. Our article on sharing one DGX Spark in a team covers the serving engine and front end for that case. With four Sparks, each developer can have a Spark of their own, and NVIDIA Sync lists all four on the laptop. If two of them are later linked for larger models, Sync’s Cluster Assistant sets up the cluster and checks the link, as our article on linking two DGX Spark systems describes.

Securing remote access to DGX Spark on a company network

NVIDIA’s documented paths reach the dashboard and JupyterLab at localhost through an SSH tunnel. None of them publishes port 11000 or a JupyterLab port to the network, and a company setup should keep it that way. We found no NVIDIA statement on which interfaces the dashboard and JupyterLab listen on, so check on the Spark with sudo ss -tlnp and block both ports at the host firewall or the network if they show up on any address other than 127.0.0.1 or ::1. A notebook server runs any code its user types, so it needs the same protection as SSH itself.

NVIDIA’s Enterprise Lifecycle Integration chapter puts “Network segmentation, firewall rules, and access pathways” and “Identity strategy, authentication, RBAC, and secrets management” in the column “Enterprise IT Owns (Typical)”. For a rollout of two or four Sparks, that leaves these decisions with you:

1. Give every user a Linux account of their own and keep sudo for the people who run updates.
2. Use the key-based SSH access that NVIDIA Sync sets up, and switch off SSH password login once every user has a key. Sync asks for that password when a laptop adds the Spark, so later laptops need their key installed another way, for example as an imported SSH alias.
3. Place the Sparks in a developer segment reachable only from your internal network or VPN, never from the internet, and switch off a Spark’s Wi-Fi when it is connected by Ethernet.
4. Decide whether Tailscale, a third-party service with its own account, is allowed, or whether staff connect through your VPN.
5. Record each Spark’s hostname and hotspot card, and run updates through the dashboard in agreed maintenance windows, after a system backup.

Our guide to securing a GPU server covers the inference APIs, notebooks and container runtime on top of this. As that guide notes, one of NVIDIA’s DGX Spark playbooks opens an Ollama server to the network for remote access, so put an authenticating gateway in front before other teams use such a server.

If you want the accounts, SSH keys and remote access set up for you, our engineering partner Vixen.UNO deploys the Sparks under the same contract. Tell us how many people need access and from where.

What we supply

We supply the NVIDIA DGX Spark Founders Edition (128 GB, 4 TB) across the EU on one contract and invoice, with manufacturer warranty, for example two Sparks for two developers or four for a team. If you want engineering as well, our engineering partner Vixen.UNO designs, deploys and supports them under the same contract, and setting up the serving software with access control is part of our Private AI/ML service. The DGX Spark page lists the system as we supply it, and our DGX Spark specifications give every figure NVIDIA publishes.

FAQ