[Community project] A dependency-free monitoring dashboard built for the DGX Spark

Accelerated Computing DGX Spark / GB10 User Forum DGX Spark / GB10 Projects
1

Hi all đź‘‹

I picked up a DGX Spark and wanted a quick “what is my Spark doing right now” view — GPU, the Grace ARM CPU, memory, network, disk, and my containers — without standing up a full Prometheus + Grafana stack. I couldn’t find something lightweight and Spark-aware, so I built one and open-sourced it.

Repo: GitHub - singhangadin/DGX-Spark-Dashboard: A very lightweight alternative for DGX spark dashboard · GitHub

DGX Spark Dashboard showing live host, GPU, network, and disk telemetry
DGX Spark Dashboard showing live host, GPU, network, and disk telemetry2000Ă—1652 177 KB

What it is

  • One Docker Compose service. No database, no cloud, no agent daemon, no frontend framework, no CDN — just FastAPI + vanilla HTML/CSS/JS.
  • Monitors: NVIDIA GPU (utilization, temp, power, VRAM where the driver exposes it), host CPU including Grace ARM frequency/temperature, RAM & swap, per-interface network rates, per-disk I/O, and Docker containers.
  • Demand-driven: it runs no background collector and reads metrics only when a browser asks. Idle overhead is effectively zero, and any category can be disabled at the source in Settings.
  • Light / dark / system themes, chart or text views, mobile-friendly.

Footprint (measured on the Spark, GB10)

  • ~190 MB image, ~42 MiB RAM, ~0.2% of one core when idle.
  • For reference, I measured the standard DCGM Exporter + Prometheus + Grafana stack on the same Spark at ~600 MiB RAM across 3 always-on containers and ~2.5 GB of images — roughly 14Ă— the memory and 13Ă— the disk. That stack does more (history, alerting, the full DCGM field set); this one is a live-only glance at a single box.

Security model (it touches host data, so this matters)

  • Read-only host /proc mounts, a read-only Docker socket, and host networking for real interface counters.
  • Runs non-root, cap_drop: ALL, no-new-privileges, read-only root filesystem.
  • Binds only the interfaces you name — e.g. loopback plus your WireGuard/Tailscale IP — not 0.0.0.0. There is no authentication, so it’s meant for a trusted network.
  • GPU access works via the NVIDIA Container Toolkit runtime or CDI (auto-detected); CDI works on GB10.

Install (one command)

Prebuilt, versioned ARM64 image from GHCR; the installer pulls a checksum-verified deployment bundle (it does not clone or compile on the Spark):

curl -fsSL https://raw.githubusercontent.com/singhangadin/DGX-Spark-Dashboard/main/install.sh | sh

Then open http://localhost:8787. Installer source: DGX-Spark-Dashboard/install.sh at main · singhangadin/DGX-Spark-Dashboard · GitHub

Notes

  • Apache 2.0 licensed.
  • This is an independent community project — not affiliated with or endorsed by NVIDIA.
  • It’s early and I’m actively smoothing rough edges, so issues, feedback, and PRs are very welcome. If you run it on your Spark, I’d love to hear what’s missing or what reads wrong for GB10.

Thanks for taking a look! 🙏

2

No networking stats in there?

4

4th card, Host network

5

Ah, but that is just the 10G port, how about the CX-7 ports, got them in there as well or is this intended for a single nodes?

6

For now this is intended for a single node, as I don’t have double nodes to test/run it on. Maybe someone from the community would be able to help here.

7

@angads25 NVIDIA already provides a DGX-Dashboard. You naming your project DGX-Spark-Dashboard might be confusing to the end user!

Also, using nvidia-smi to get the GPU info is not a good option. This being a monitoring tool, constantly reading from nvidia-smi is a performance killer.

Please consider this constructive criticism and not otherwise. I appreciate your project.

8

Thanks for the feedback, the tool now no longer relies on nvidia-smi but rather uses NVML for the data in newer version.