To use NVIDIA DGX Spark remotely, you need to set up remote access and basic security. This article covers the main steps. I will skip first-boot setup because it is already covered in the manual.
One important note: DGX Spark runs Ubuntu on ARM64. When you install software, choose the correct architecture (aarch64 or arm64).
Enabling remote access
DGX Spark uses SSH for remote access. First, check that the ssh service is installed and running:
systemctl status sshIf you see Active: active (running), SSH is ready. All remote access depends on this service.
Connecting from a client
After SSH is enabled, any machine with an ssh client can connect. NVIDIA also provides a useful GUI tool called nvidia-sync:
https://build.nvidia.com/spark/connect-to-your-spark/sync
It lets you connect to and manage DGX Spark, open an SSH terminal, and use VS Code or Cursor for remote development. I recommend using it.
It is available for Windows, Linux, and macOS.
When nvidia-sync adds a device for the first time, it uses your username and password. Then it creates a new SSH key pair and adds the public key to ~/.ssh/authorized_keys on DGX Spark. Later connections use this SSH key instead of the password.
The username and password are only needed when adding the device. Also, nvidia-sync creates a new random key pair each time you add a device. If you delete a device and later add it again, password login must still work. So if you use nvidia-sync, do not disable SSH password authentication.
LAN connection
On a LAN, nvidia-sync can find running DGX Spark devices from the Devices page. You do not need to enter the IP address. Click the device, enter the username and password, and connect.
Cross-network connection
For access from another network, enable tailscale: https://tailscale.com/
First, be careful with IPv6. On home networks, IPv4 devices are usually behind router NAT. The public internet cannot connect to them directly. But if DGX Spark gets a global IPv6 address, it may be reachable from the internet. If your router or host firewall allows inbound IPv6 traffic, the SSH port can be exposed to the whole IPv6 internet.
Direct access over public IPv6 can work. But then you must manage the firewall, dynamic IPv6 address or DNS, allowed source IPs, and SSH security yourself. A safer way is to block public inbound access and use Tailscale. Tailscale creates an encrypted overlay network that only approved users and devices can access. You do not need public IPv4, port forwarding, or a fixed IPv6 address. You also avoid exposing DGX Spark’s SSH service to the public internet.
Tailscale is a WireGuard-based mesh VPN service. It handles device discovery, identity, NAT traversal, and end-to-end encryption. More importantly, NVIDIA Sync uses its built-in Tailscale integration for remote access across networks. It connects directly on the LAN when possible. When you leave the LAN, it switches to Tailscale automatically. You do not need to choose the mode yourself.
Server configuration
SSH into DGX Spark and check whether Tailscale is already installed:
tailscale versionIf the command is missing, follow the official installation instructions at https://build.nvidia.com/spark/tailscale/instructions :
# Install required tools
sudo apt install -y curl gnupg
# Add the Tailscale signing key
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg | \
sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg > /dev/null
# Add the Tailscale repository
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.tailscale-keyring.list | \
sudo tee /etc/apt/sources.list.d/tailscale.list
# Install Tailscale
sudo apt update && sudo apt install -y tailscaleAfter installation, start Tailscale and log in:
sudo tailscale upFollow the terminal prompt. Open the browser and log in to your Tailscale account. Then you should see DGX Spark online in the admin console. The server-side setup is done.
Client configuration
nvidia-sync already includes a Tailscale client. For NVIDIA Sync itself, you do not need to install the tailscale command. Open Settings, find Tailscale, click Enable Tailscale, and log in in the browser. Then you should see the Tailscale connection status for nvidia-sync in the admin console.
After this is enabled, nvidia-sync uses the Tailscale tunnel when your client and DGX Spark are not on the same LAN. You do not need to switch manually.
One limitation: the Tailscale feature inside nvidia-sync only works inside the app. It does not set up system DNS. If you want to use the Tailscale domain (*.ts.net) in a terminal or another tool such as VS Code, you still need to install the standalone Tailscale client on the client machine: https://tailscale.com/download.
Connecting with a Tailscale address
In the Tailscale admin console, open Machines and use any address under ADDRESSES. You can use the private IPv4 address (100.x.x.x), the IPv6 address starting with fd7a:115c:, or the x.x.ts.net domain. If you use the domain name (*.ts.net), the Tailscale client must be running. Otherwise the domain will not resolve.
The Tailscale client must stay running during the session. Keep nvidia-sync open and do not stop tailscale. If it disconnects, the remote session will stop.
Remote collaboration
Tailscale also supports collaboration. You can share the DGX Spark device with another user. That user can then connect to it through Tailscale.
In the Tailscale admin console, open Machines, select the DGX Spark device, and click Share. The other user will see the shared DGX Spark in their own console. They can then follow the Client configuration steps above to connect.
Understanding Tailscale in more depth
Tailscale is not just a “zero-config WireGuard client.” WireGuard creates lightweight, end-to-end encrypted tunnels. But WireGuard alone does not handle user identity, device discovery, key distribution, NAT traversal, or access policy. Tailscale automates these tasks. The official How Tailscale works article (https://tailscale.com/blog/how-tailscale-works) explains the full architecture.
How Tailscale works
Tailscale has two parts: a control plane and a data plane.
- The control plane is handled by Tailscale’s coordination servers. It authenticates users and devices, exchanges public keys and connection information, and sends access policies to devices. It only coordinates connections. It does not carry application traffic.
- The data plane is made of WireGuard tunnels between devices. Each device creates its private key locally. The private key never leaves the device. Traffic between two devices is end-to-end encrypted, so Tailscale cannot read it.
You can think of it a bit like TCP’s three-way handshake. The Coordination Server first helps both sides confirm identity and connection details. Then the client and DGX Spark create their own data channel. This is not the actual TCP handshake protocol. The Coordination Server is also not in the path of later application traffic.
sequenceDiagram
participant Client as Client / NVIDIA Sync
participant Control as Coordination Server
participant Spark as DGX Spark
Note over Client,Spark: Control plane: the Coordination Server must coordinate before connection setup
Client->>Control: Log in and register device public key and addresses
Spark->>Control: Log in and register device public key and addresses
Control-->>Client: Return Spark addresses, public key, and access policy
Control-->>Spark: Return client addresses, public key, and access policy
Note over Client,Spark: Data plane: after coordination, application traffic bypasses the Coordination Server
Client->>Spark: Establish peer-to-peer WireGuard encrypted connection
Client->>Spark: SSH, file transfer, and remote development traffic
When two devices start communicating, they use Tailscale’s coordination service and DERP relay servers to find each other. Then they try to create a direct UDP connection through NAT traversal. In most cases, traffic then flows directly between the client and DGX Spark. It does not pass through a central VPN gateway.
If a network blocks UDP, or if NAT traversal fails, Tailscale tries a Peer Relay in the same tailnet. If that also fails, it uses Tailscale’s global DERP servers. The Coordination Server still does not carry application traffic. Direct, Peer Relay, and DERP connections all carry WireGuard-encrypted data. Relay servers cannot decrypt it. The main difference between connection types (https://tailscale.com/docs/reference/connection-types) is latency and throughput, not encryption strength.
Use these commands to inspect the actual connection path:
tailscale ping <device name or Tailscale IP>
tailscale status
tailscale netcheckIn the output, direct means peer-to-peer direct connection. relay means DERP relay. peer-relay means a self-hosted Peer Relay. If remote development feels slow, first check whether the connection stays on relay.
The main differences between Tailscale and a traditional VPN are:
| Item | Traditional VPN | Tailscale |
|---|---|---|
| Network topology | Usually forwards traffic through a central VPN gateway | Prioritizes peer-to-peer mesh connections between devices |
| Identity and configuration | Often relies on passwords, certificates, and manual network configuration | Integrates with identity providers and automatically distributes device public keys and policies |
| NAT traversal and open ports | Usually requires a public endpoint, port forwarding, or a fixed gateway | Performs NAT traversal automatically and uses encrypted relays if traversal fails |
| Access control | Often grants access by subnet and IP address | Can authorize by user, group, device tag, port, and device posture |
| Traffic egress | Often sends client internet traffic through the VPN gateway by default | Handles only internal tailnet traffic by default; Exit Nodes can be configured separately |
So Tailscale is better described as an identity-based encrypted overlay network. It is not a traditional proxy-style VPN for hiding a public IP address.
Why NVIDIA Sync uses Tailscale
DGX Spark is usually on a home or office network. It often has no fixed public IP address. It may also be behind several layers of NAT or carrier-grade NAT. Publishing SSH to the internet is hard to configure and keeps a login port exposed. Tailscale solves device discovery, dynamic addresses, NAT traversal, and encrypted access. DGX Spark does not need any public inbound port.
The NVIDIA Sync official documentation (https://docs.nvidia.com/sync/latest/tailscale.html) says that NVIDIA Sync joins the tailnet as a node. So if you only use NVIDIA Sync, the client does not need a separate system-level Tailscale client. NVIDIA Sync also chooses the connection mode automatically: direct connection on the same LAN, Tailscale outside the LAN. The tunnel it manages, and VS Code or Cursor connections that use its SSH alias, switch with it.
Locally on the client, NVIDIA Sync roughly works like this:
VS Code / Cursor / NVIDIA Sync terminal
|
| SSH alias / tunnel managed by NVIDIA Sync
v
+-----------------------------------------+
| NVIDIA Sync |
| |
| Device discovery + SSH key management |
| Connection status checks |
| Built-in Tailscale node |
+-----------------------------------------+
|
Check whether DGX Spark is reachable
|
+-------+-------+
| |
v v
Reachable on LAN Different network or LAN unreachable
| |
v v
LAN direct Tailscale encrypted connection
| |
+-------+-------+
|
v
DGX Spark SSH
After installing the system-level Tailscale client separately,
other terminals and applications can also use the 100.x.x.x address
or *.ts.net domain directly, without being limited to NVIDIA Sync.So NVIDIA Sync is not just “a VPN integration.” Tailscale gives it the network coordination needed for mobile clients to connect to a fixed workstation. NVIDIA also does not need to build its own account system, NAT traversal, or global relay network.
How Tailscale provides enterprise-grade security
Tailscale does not mean “everyone inside the VPN trusts everyone else.” Its security model combines identity, device state, and least-privilege rules:
User identity Device identity and state
SSO / MFA Device approval / tags / posture
| |
+--------------+---------------+
|
v
+-----------------------------------+
| Tailscale control plane |
| Interprets Grants / ACL policy |
+-----------------------------------+
|
| Distributes allowed peers, public keys, and packet filters
v
+-----------------------------------+
| Policy enforcement on DGX Spark |
| tailscaled inbound packet filter |
+-----------------------------------+
|
Allow user -> tcp:22
Deny other unauthorized connections
|
v
OpenSSH service
Tailscale network policy only decides whether traffic can reach the service.
SSH keys, Ubuntu permissions, UFW, and system updates remain separate security layers.- End-to-end encryption: The data plane uses WireGuard. Device private keys stay on the device. Even through DERP, the relay only sees encrypted data.
- Identity authentication: Users log in with providers such as Google, Microsoft, GitHub, and Okta. Teams can reuse existing SSO, MFA, and account offboarding.
- Device approval: Administrators can enable Device Approval (https://tailscale.com/docs/features/access-control/device-management/device-approval). New devices must be approved before they can use the tailnet.
- Least-privilege policy: Tailscale recommends Grants (https://tailscale.com/docs/features/access-control/grants). Grants define who can access which ports on which devices. The control plane sends the policy, and each target device enforces it locally.
- Device identity and posture: Tags can mark DGX Spark, servers, and user devices. Device Posture can limit access by OS version, Tailscale version, MDM, EDR, or XDR state.
- Audit and logs: All plans include configuration audit logs and webhooks. Premium and Enterprise also provide network flow logs and log streaming for SIEM.
- Less trust in the control plane: For high-security use, Tailnet Lock (https://tailscale.com/docs/features/tailnet-lock) requires trusted nodes to sign new node keys. Even if the Tailscale control plane is compromised, an attacker cannot freely add a working node to the tailnet. Tailnet Lock is currently only in Personal and Enterprise plans. It cannot be used together with Device Approval, so choose based on your threat model.
One detail is easy to miss. ACL and Grants rules are “default deny,” but a new tailnet starts with a policy that allows all devices to access each other. For real zero trust and least privilege, remove the initial allow-all rule. Then add clear allow rules.
For example, after tagging DGX Spark as tag:dgx-spark, you can allow only one user to access SSH:
{
"tagOwners": {
"tag:dgx-spark": ["autogroup:admin"]
},
"grants": [
{
"src": ["your-account@example.com"],
"dst": ["tag:dgx-spark"],
"ip": ["tcp:22"]
}
]
}If you add DGX Spark through NVIDIA Sync’s Add a Device flow with an auth key, use a one-time key with a short lifetime. Also bind the server identity with tags. Do not paste reusable auth keys into scripts, chats, or repositories. Anyone with the key can add a new device to your tailnet.
Using Share for DGX Spark is safer than inviting external collaborators into the whole tailnet. Device sharing (https://tailscale.com/docs/features/sharing) is still beta. It only lets the recipient see the shared machine. The shared machine is isolated by default and cannot connect to other machines in the recipient’s tailnet. Treat share links like passwords. Prefer one-time links. Also use Grants to limit collaborators to DGX Spark’s SSH port.
Tailscale only protects traffic that goes through the overlay network. It does not fix weak passwords, vulnerabilities, or wrong permissions on DGX Spark. If SSH also listens on LAN or public interfaces, you still need host firewall rules, system updates, and SSH hardening.
Using Aperture to protect AI usage on DGX Spark
The Securing AI message on Tailscale’s homepage refers to Aperture by Tailscale (https://tailscale.com/use-cases/securing-ai). It is still in beta. Aperture is an AI gateway between tools such as Claude Code, Codex, and Gemini CLI and the model providers. Its role is similar to OpenRouter.
Aperture keeps model API keys in one place. Without it, those keys may be spread across developer laptops, DGX Spark, CI/CD systems, and agents. Users do not send upstream model API keys to Aperture. The gateway identifies the user or device through Tailscale, checks permissions, and then adds the correct provider credentials.
Developer / Agent
Claude Code / Codex / Gemini CLI / custom app
|
| Tailscale network identity
| No upstream model API key carried by the client
v
+----------------------------------------+
| Aperture AI Gateway |
| |
| Authentication and model authorization |
| Centralized provider API keys |
| Model routing / quotas / logs |
| Guardrails / MCP Gateway |
+----------------------------------------+
| | |
| | |
v v v
OpenAI Anthropic Models on DGX Spark:
Gemini Bedrock vLLM / Ollama /
llama.cpp, etc.
The client connects to a single Aperture address.
The gateway forwards the request to an external provider
or a private DGX Spark model based on the requested model name.This “single authentication system” is really Tailscale network identity plus Aperture authorization policy:
- Users only log in to Tailscale. Tools such as Claude Code, Codex, and Gemini CLI call models through the Aperture address. They do not need separate API keys for OpenAI, Anthropic, Google, and other providers.
- Administrators store one API key for each provider in Aperture. They control model access by Tailscale user, group, or device tag.
- Aperture denies model access by default. Even if a user can reach the gateway, they cannot call a model without the right Grant.
- When a user is removed, a device is revoked, or a policy changes, access changes immediately. You do not need to rotate or delete API keys on every device.
This does not mean you can combine Claude Max, ChatGPT Plus, Gemini Advanced, or similar subscriptions. Aperture needs API keys from model provider developer platforms. It cannot use consumer or team subscription login benefits.
How Aperture protects AI usage
As the single entry point for AI requests, Aperture provides these security and governance features:
- Less API key sprawl: Upstream keys are stored only in Aperture. They do not need to be on developer machines, DGX Spark agent configs, scripts, or repositories.
- Identity-aware audit: Every request is tied to a Tailscale user or device. Logs can include model, provider, time, token count, and cost. Requests from Claude Code or Codex can also be grouped into a full session.
- Model access control: A user or team can be limited to specific models. Quotas can limit request count and budget by user, agent, model, or team.
- Request guardrails: Before a request leaves the network, pre-request hooks can inspect, change, or reject it. For example, they can remove PII, remove dangerous tool declarations, or block prompts that violate policy.
- One MCP entry point: Aperture can group several remote MCP servers under one
/v1/mcpendpoint. It can use Tailscale identity to control which MCP tools and resources a user can discover. - Private models stay private: OpenAI-compatible services on DGX Spark, such as vLLM, Ollama, and llama.cpp, only need to be exposed to the tailnet. Aperture can provide them to the team as self-hosted providers.
Current limitations:
- Aperture stores full requests and responses for audit. These may include source code and secrets. Set retention based on your compliance needs. If needed, set full-capture retention to zero and export required logs to S3 or a SIEM.
- Guardrails currently run only before requests are sent to the model. They do not filter model responses after the fact.
- Aperture’s MCP Server Proxy is still alpha. Current Grants limit which tools a user can discover. But the official docs say tool-level authorization is not checked again when a tool is called.
- Local tools run on the machine where the coding agent runs. Aperture can observe tool use and limit tool declarations sent to the model. But it does not replace the sandbox, approvals, or filesystem permissions in clients such as Claude Code or Codex.
Recommended architecture with DGX Spark
You can use DGX Spark in two ways at the same time: as a remote development machine and as a private model server.
Developer laptop
Claude Code / Codex / Gemini CLI
|
| Connect to Aperture only
v
+--------------------------+
| Aperture |
| Identity / policy / logs |
+--------------------------+
| |
| +=========> External hosted models
| OpenAI / Anthropic / Gemini
|
+== Tailscale private network ==> DGX Spark
|
+-- OpenAI-compatible model service
| vLLM / Ollama / llama.cpp
|
+-- Private MCP Server
+-- SSH remote development environment
DGX Spark's model and MCP services do not need public ports.
Administrators can expose different models and tools to different users.The private model service on DGX Spark must provide an OpenAI-compatible Chat Completions API. Aperture must be able to reach it through a tailnet address. For example, Aperture can point a provider to DGX Spark:
{
"providers": {
"dgx-spark": {
"baseurl": "http://dgx-spark.example.ts.net:8000",
"models": ["private-coding-model"]
}
}
}Claude Code, Codex, Gemini CLI, and other clients that support a custom Base URL only need to use Aperture as the API address:
Claude Code: ANTHROPIC_BASE_URL=http://<aperture-hostname>
Codex: base_url = "http://<aperture-hostname>/v1"
Gemini CLI: API Base URL = http://<aperture-hostname>/v1Even if these clients use http:// to connect to Aperture, the traffic is still encrypted by WireGuard. Clients do not need real model API keys. If a tool requires an API key value, use a placeholder. Aperture ignores it and adds the centrally managed upstream credentials.
There is one more identity issue. Aperture identifies requests by the Tailscale node that sends the network request. If a developer runs the coding agent on their own laptop, Aperture can record that user. If several people SSH into the same DGX Spark and run agents there, requests are usually identified as the DGX Spark device owner or tag identity. They are not identified as the individual SSH users.
So if your team needs per-user audit logs, run the coding agent on each developer’s local machine and operate DGX Spark through NVIDIA Sync/SSH. Another option is to give each user, CI runner, or agent container its own Tailscale or ts-unplug identity. Do not let all automation share one DGX Spark node identity.
As of now, Aperture is still in beta. During the beta, any Tailscale account can use it for free. The Personal plan supports up to 6 users. Official pricing for larger teams is not published yet. Check the Aperture official documentation (https://tailscale.com/docs/aperture) and future pricing updates.
How Tailscale is priced
The prices below come from the Tailscale official pricing page (https://tailscale.com/pricing). Tailscale introduced seat-based billing in April 2026. Prices and plan limits may still change.
| Plan | Current price | Main use case and differences |
|---|---|---|
| Personal | Free | Non-commercial personal use only. Up to 6 users, unlimited user devices, 50 tagged resources, 3 ACL groups, and most core features |
| Standard | USD 8 per seat per month | For teams. Unlimited users, plus SCIM, more roles, MDM configuration, third-party device posture integrations, and related features |
| Premium | USD 18 per seat per month | Adds network flow logs, log streaming, just-in-time access, advanced Tailscale SSH, regional routing, and priority support |
| Enterprise | Custom pricing | Adds custom capacity, contracts and SLA, professional services, dedicated support, invoice payment, and related enterprise options |
A “seat” means a user in the tailnet, not a device. Normal user devices are unlimited on all plans. Servers, Exit Nodes, and similar resources should usually be tagged resources. The Personal plan includes 50 tagged resources. Extra tagged resources currently cost USD 1 each per month. Short-lived CI/CD runners and Kubernetes pods use an ephemeral resource minute pool.
For personal use at home, the free Personal tailnet is usually enough for one DGX Spark. NVIDIA Sync, your laptop, and DGX Spark are not billed separately by device count. Costs mainly appear when you use it commercially, have more than 6 users, need many tagged or ephemeral resources, or need enterprise features such as SCIM, device posture integrations, network flow logs, log streaming, and SLA.
Network security
DGX Spark runs Ubuntu, so normal Ubuntu security practices apply. Here are a few common ones.
Tailscale creates an encrypted boundary for access across networks. Other tailnets cannot find or connect to your machine by default unless you share it. But a new tailnet’s default policy allows devices in the same tailnet to access each other. Also, Tailscale only protects the overlay network. It does not block direct LAN or public IPv6 access to DGX Spark. You still need the access rules and system hardening below.
Change the default SSH port
Edit /etc/ssh/sshd_config. Remove the # before Port, set the port number you want, and restart SSH.
sudo systemctl restart sshIf you change the SSH port, also update your firewall rules.
Enable the firewall
I recommend enabling the firewall. A global IPv6 address is not protected by LAN NAT. If the router and host firewall allow inbound traffic, external devices can reach DGX Spark directly. Use the following rules as a starting point and adjust them as needed:
# Allow unrestricted LAN access. This assumes your LAN is 192.168.1.0/24.
sudo ufw allow from 192.168.1.0/24
# Allow SSH access through the tailscale0 interface, assuming you did not change the SSH port.
sudo ufw allow in on tailscale0 to any port 22
# Enable the ufw firewall. Note that ufw defaults to denying all inbound traffic and allowing all outbound traffic.
sudo ufw enableCheck the ufw firewall status:
sudo ufw status verboseThis is a basic firewall setup. It allows LAN access, allows SSH through Tailscale, and blocks other external access, including IPv6 access. tailscale0 is the VPN network interface created by Tailscale. With this setup, DGX Spark can still be reached through nvidia-sync from the LAN and from remote networks.
Summary
This article covered remote access and security for DGX Spark:
- Remote access depends on SSH. Make sure
sshis running. - LAN access is easiest with
nvidia-sync. It uses mDNS to find DGX Spark on the LAN. - Cross-network access should not expose public IPv6 SSH directly. Use Tailscale to build an encrypted overlay network for approved identities only. NVIDIA Sync uses built-in Tailscale for this.
- Tailscale security should not stop at the default allow-all policy. Use Device Approval or Tailnet Lock when needed, and use Grants to limit users to the ports they need.
- Aperture AI Gateway can use Tailscale identity for tools such as Claude Code, Codex, and Gemini CLI. It can centralize model API keys and apply the same access, audit, and budget rules to external and private models.
- Tailscale pricing mainly depends on commercial users, enterprise features, and resources beyond plan limits. For one DGX Spark in personal non-commercial use, the free Personal plan is usually enough.
- For network security, DGX Spark is basically an Ubuntu machine. Changing the SSH port and enabling ufw are basic hardening steps.