DGX Spark Setup in Canada: First Boot to a Private Chat UI

Documentation reviewed August 25, 2026. NVIDIA’s current DGX Spark release notes list DGX OS 7.5.0, driver 580.159.03, CUDA Toolkit 13.0.2, and the current firmware/component versions. Recheck those notes before setup or an update. A shipped unit or OEM variant can have a different starting image, and NVIDIA states that partner update schedules can differ.

This is the hardware, DGX OS first-boot, security, recovery, and handoff guide. It does not reproduce the application procedure on Ollama on DGX Spark and does not promise that a model will fit or meet a speed target. Use the VRAM vs unified-memory capacity worksheet for memory planning and CUDA vs ROCm vs Vulkan for backend compatibility.

If DGX Spark is not yet the approved architecture, return to the local AI hardware guide. The alternative commercial routes are the AMD Strix Halo 128 GB plan at $7,349 CAD and a quoted custom GPU inference rig; they have different first-boot and software procedures.

Prerequisites before opening the box

• An accountable owner: name the person responsible for accounts, updates, backups, incident response, application approval, and final acceptance.
• An access decision: choose NVIDIA’s local display setup or network-appliance setup. Have a wired keyboard, mouse, and display available as a recovery path even if network setup is planned.
• A prepared network: decide the management segment, addressing method, DNS name, outbound-update policy, time synchronization, and which administrator workstation may connect.
• A stable initial download path: NVIDIA’s first-boot guide calls for a reliable internet connection to obtain required updates. Captive portals and unreliable hotspots are poor setup paths.
• A site and power review: place the device where ventilation is not obstructed and use the power adapter supplied for the unit. Validate the outlet and site requirements for the actual installation; this guide makes no circuit-load promise.
• A credential plan: prepare the administrator username, a unique password process, SSH-key ownership, recovery contacts, and the password-manager record. Do not rely on a copied default credential.
• A backup destination: identify where configuration records, application data, model manifests, and recovery information will live outside the Spark.

NVIDIA’s hardware overview specifies the supplied adapter, environmental guidance, ports, 10 GbE, ConnectX-7, Wi-Fi, and the 128 GB unified system-memory architecture. It does not establish that an arbitrary office circuit, cable, switch, enclosure, or remote-access design is suitable. The customer’s facilities and IT owners retain that decision.

Step 1: Choose local-display or network-appliance setup

NVIDIA supports two first-time access modes. Local setup uses a connected display, keyboard, and mouse. Network-appliance setup uses another computer and the temporary setup interface described on the unit’s Quick Start Guide. The choice controls only the initial setup; NVIDIA says the system can later be accessed locally, over the network, or through a mixture of both.

Use local setup when the network blocks discovery, client isolation or mDNS is uncertain, corporate Wi-Fi requires a portal, or a direct visual recovery path is preferred. Use network setup when the Spark will operate headlessly and the administrator has a trusted computer on a simple local network. Read NVIDIA’s current Initial Setup – First Boot guide before applying power because the access details and troubleshooting guidance belong to the shipped documentation.

Record the chosen mode, administrator workstation, network segment, and fallback. Do not photograph or paste the Quick Start Guide’s temporary setup credentials into a ticket or public channel. They are unit-specific bootstrap information, not a permanent team password.

Step 2: Connect peripherals and networking before power

Attach the planned network cable, display, keyboard, and mouse before connecting the power adapter. NVIDIA states that DGX Spark starts when power is applied and specifically recommends attaching peripherals first. If wired networking is planned, connect it before installation to reduce setup changes. For local setup, a simple wired keyboard is the safest first-boot and recovery input path.

Prefer HDMI as the display fallback if a USB-C/DisplayPort display is not detected; NVIDIA calls out that troubleshooting path in the first-boot guide. Label the Spark, power adapter, network port, and responsible owner. Keep unapproved removable storage disconnected. If the device will be installed in a controlled room after staging, document both the staging and final network rather than assuming the move is transparent.

Use only NVIDIA’s supplied power adapter for the system. Have the responsible facilities owner assess the outlet, branch circuit, power bar or UPS, and site policy. The adapter specification and compact form factor do not establish universal circuit suitability.

Step 3: Run the first-time utility and create the administrator

Apply power and follow the on-screen or network first-time utility. NVIDIA’s documented flow covers language and time zone, keyboard layout for local setup, terms, account creation, optional information-sharing settings, network selection, image download, installation, and completion. Create the first account with a unique credential controlled by the system owner. Do not reuse a staging password or publish a “DGX default password”; NVIDIA’s process asks the operator to create the account.

Choose the correct Canadian time zone and verify system time after the setup completes. Time affects logs, certificate validation, package metadata, and incident reconstruction. Review optional analytics and crash-reporting choices against the organization’s data policy rather than accepting them without an owner.

During network-appliance setup, the temporary hotspot is expected to stop after the Spark joins the selected network. The administrator computer must then reach the Spark on that network. If it cannot, NVIDIA identifies client isolation, failure to join the same network, and mDNS limitations as possible causes. Move to the connected display/keyboard path instead of weakening a corporate network to rescue discovery.

Step 4: Complete updates without interrupting the installation

Allow the first-time image download, installation, and automatic reboots to finish. NVIDIA warns not to shut down or restart during this process. Use a stable power and network path, save unrelated work, and treat the setup as a maintenance window. An unavailable remote interface during the reboot phase does not by itself mean the installation failed.

After the system returns, open DGX Dashboard and compare the installed baseline with the current release notes. NVIDIA’s OS and Component Update Guide recommends DGX Dashboard as the primary update path for Founders Edition because it coordinates NVIDIA-optimized system, driver, and firmware components. The same guide notes that OEM variants can use different procedures. Identify the actual manufacturer before applying a Founders Edition recovery or update instruction.

Do not replace the appliance baseline simply because a newer general Ubuntu package, CUDA Toolkit, driver, or firmware exists elsewhere. Record DGX OS, kernel, NVIDIA driver, CUDA Toolkit, UEFI, firmware, device serial/asset ID, update time, and update method. This version inventory is the rollback and support starting point.

Step 5: Establish managed local and remote administration

Verify local sign-in first, then add only the remote path the owner will maintain. NVIDIA documents local use, SSH, remote desktop, DGX Dashboard, and NVIDIA Sync. NVIDIA Sync manages SSH connections, port forwarding, and tunnels from supported administrator systems. It is an access tool, not permission to expose SSH or dashboard ports to the public internet.

Enroll administrator SSH keys, test them from the approved management workstation, and document how keys are rotated or revoked. Confirm the intended account has `sudo` only if its duties require it. Create separate non-administrator user or service identities for ordinary application use. Do not share the first account across a team.

The DGX Dashboard documentation explains local dashboard access and remote use through NVIDIA Sync or an SSH tunnel. Keep the dashboard bound to its intended local interface and reach it through the supported tunnel. Record the device hostname and management address, but avoid building authorization around an address that DHCP may later change.

Step 6: Apply the network and security boundary

Place the Spark on the approved network segment and allow inbound administration only from named management sources. Keep application ports separate from administration. Do not expose JupyterLab, DGX Dashboard, SSH, an inference API, or a chat UI directly to the internet during setup. If remote access is required, use the organization’s approved VPN, bastion, identity, and logging pattern.

Review active listeners, enabled services, local accounts, `sudo` membership, SSH configuration, host firewall policy, DNS, time source, and update egress. Disable interfaces that are not required. NVIDIA’s UEFI guide documents a setting that disables Wireless LAN and Bluetooth together when policy requires a hardware-level wireless boundary. UEFI changes need physical keyboard access and must be recorded because they affect recovery.

Define what is logged and where logs go. Prompts or retrieved documents can be sensitive; indiscriminate application logging can create a second dataset requiring protection. Local inference can reduce an external API transfer, but it does not guarantee Quebec Law 25, PIPEDA, contractual, or sector compliance. Use the Quebec Law 25 local-LLM guide as orientation and obtain advice for the actual deployment.

Step 7: Select one supported application playbook

Prove the base platform before installing several overlapping inference stacks. Confirm storage, network, accounts, dashboard, driver visibility, container support, and updates, then choose one bounded application path. NVIDIA identifies build.nvidia.com/spark as the current location for DGX Spark playbooks and practical examples. Record the playbook URL and review date because instructions and container tags change.

For a GGUF service, NVIDIA publishes a Spark-specific llama.cpp CUDA playbook. NVIDIA also publishes a vLLM playbook. Ollama and Open WebUI are covered separately in D-Central’s Ollama on DGX Spark guide and first-boot Ollama/Open WebUI guide. This setup page deliberately does not copy their commands.

Approve the model licence and provenance, hash downloaded artefacts, pin containers or source revisions, define storage locations, and restrict the service interface before importing sensitive data. “Open-weight” does not identify one licence or grant permission for every use. Do not use a public model download as the acceptance test for confidential Canadian data.

Step 8: Run acceptance tests and complete the handoff

Restart the Spark and verify the complete managed path: operator sign-in, network identity, time, dashboard, storage, driver/runtime discovery, selected application, authentication, approved client access, logging, backup, and controlled shutdown. Test the maximum accepted context and concurrency using non-sensitive representative data. Record failures and limits rather than replacing them with a generic benchmark result.

Confirm that no temporary staging account, downloaded secret, setup network, broadly bound test server, or unnecessary `sudo` access remains. Test key revocation and the recovery contact. Export configuration and application data to the approved backup destination, then demonstrate restoration of a small representative item. A backup that has never been read is not handoff evidence.

The customer operator and D-Central technician, when setup is included, should review the same handoff record. D-Central’s role is limited to the agreed sourcing and configuration scope. NVIDIA owns DGX Spark hardware, DGX OS, CUDA, the first-boot utility, and playbooks; model and application projects retain their own authorship and support boundaries.

Rollback and system recovery

Use three rollback layers. First, preserve application configuration, model manifests, container digests, and data outside the system so an application change can be reversed. Second, maintain the previous known-good service image or package set and an update log. Third, know the vendor’s full recovery procedure before a failure.

NVIDIA’s System Recovery guide says Founders Edition recovery uses NVIDIA recovery media and a bootable USB workflow; it also warns that the recovery process erases the internal SSD. OEM variants require recovery images and procedures from their manufacturer. Do not use the Founders Edition image merely because the processor is GB10.

Before any destructive recovery, preserve logs and recoverable data, verify backups, identify the exact variant, obtain the correct current media, and record the failure symptoms. Recovery requires physical access, a compatible USB device, display, and wired keyboard under NVIDIA’s documented Founders Edition process. Reimaging restores a platform; it does not restore customer applications, secrets, models, or data unless those were backed up separately.

Air-gap and restricted-network boundary

NVIDIA’s normal first-time path expects reliable internet access for the software image and updates. Therefore a true air-gapped Spark deployment is not “skip Wi-Fi and continue.” It is a designed import, update, verification, and recovery process. Build and validate the baseline in an approved staging zone or use the vendor’s current enterprise/custom installation methods, then transfer only approved artefacts through controlled media.

An offline plan must cover DGX OS and firmware media, application packages or containers, models and licences, checksums or signatures, malware scanning, dependency manifests, time, credentials, logs, backup export, vulnerability response, and the route back to a supported update state. NVIDIA’s cloud-init/custom installation guide describes administrator workflows for local media and package sources. That is an enterprise engineering path, not a consumer first-boot shortcut.

Read Run AI Without the Internet for the broader operating model. For a controlled departmental or regulated deployment, scope the network, identity, data and recovery design through on-premises AI deployment in Canada.

Secure handoff checklist

Handoff item	Evidence	Named owner
Asset and platform baseline	Variant, serial/asset ID, DGX OS, kernel, driver, CUDA, firmware and update date	Hardware/system owner
Accounts and access	User list, `sudo` list, SSH-key fingerprints, management sources, revocation test	Identity/system owner
Network boundary	Hostname, segment, address reservation, firewall policy, exposed listeners, remote-access route	Network owner
Application baseline	Playbook, source/container digest, model hashes, licence record, launch and restart procedure	Application owner
Data controls	Approved sources, storage paths, retention, logs, backup destination and restore test	Data owner
Maintenance and recovery	Update window, rollback baseline, correct vendor recovery procedure and support contact	Operations owner

For buyers still comparing complete platforms, use Which Local AI Computer Should You Buy in Canada? or the focused Spark-vs-Strix comparison. This procedure begins after DGX Spark is the approved architecture.

Frequently asked questions

Does DGX Spark need a monitor for first boot?

No. NVIDIA documents both a local display path and a network-appliance path. A wired display, keyboard and mouse should still be available for troubleshooting, UEFI access, or recovery when network discovery or setup fails.

What is the default DGX Spark password?

Do not use a copied password from a blog. NVIDIA’s first-time utility asks the operator to create the initial account and password. The temporary network-setup information is printed with the specific unit and should be treated as bootstrap material, not a shared permanent credential.

Should I install the newest CUDA Toolkit manually?

Not merely because a newer general toolkit exists. Start from the coordinated DGX OS baseline, check current Spark release notes and application requirements, stage any change, and preserve rollback. NVIDIA recommends DGX Dashboard for Founders Edition system updates.

Can I expose DGX Dashboard or JupyterLab over the internet?

Do not publish them directly during setup. NVIDIA documents dashboard access locally or through NVIDIA Sync/SSH tunnelling. Use the organization’s approved VPN, bastion, identity, firewall and logging pattern for remote administration.

Can DGX Spark be fully air-gapped?

It can operate within a restricted design, but NVIDIA’s normal first boot expects update access. A true air gap requires approved media, package and model manifests, integrity verification, offline update and recovery procedures, log export, and an accountable lifecycle owner.

Does D-Central build the DGX Spark hardware?

No. NVIDIA designs and supplies DGX Spark and DGX OS. D-Central’s $9,449 CAD plan covers the offered sourcing and agreed first-boot/configuration scope in Quebec. The exact deliverables and handoff boundary should be recorded before work begins.

Does local setup make the system compliant with Canadian privacy law?

No. Local processing can reduce external data transfers, but compliance depends on authority, purpose, access, retention, safeguards, vendors, incident response and documented governance. Treat the Spark as one technical control and obtain advice for the actual organization and data.

Commercial route: view the NVIDIA DGX Spark plan at $9,449 CAD or read the Canadian DGX Spark overview. D-Central does not claim benchmark results, current stock, delivery timing, universal electrical fit, or automatic compliance on this setup page.