Self-hosted server monitoring, honestly reviewed. Minimal setup, zero subscription.

TL;DR

What it is: Open-source (MIT) server monitoring dashboard — a single Docker container that shows CPU, RAM, storage, network, and GPU stats through a glass-effect UI [README].
Who it’s for: Homelab operators, solo founders, and developers running VPS or private servers who want a clean at-a-glance health view without stitching together Grafana, Prometheus, and a tutorial.
Cost savings: Datadog charges ~$15/host/month. Site24x7 starts ~$9/month. Dashdot runs on whatever VPS you already have, at $0 for the software [website].
Key strength: The cleanest UI in the self-hosted monitoring category — glassmorphic design with smooth real-time animation that actually looks good enough to leave on a wall display [README][website].
Key weakness: Intentionally narrow scope — it’s a status panel, not an observability platform. No alerting, no historical graphs beyond the current session, no multi-node support, and GPU monitoring requires --privileged mode and only works for NVIDIA cards via Docker [README][website].

What is dash.

dash. (also written dashdot) is a self-hosted server dashboard that tells you, at a glance, whether your machine is healthy. It runs as a single Docker container, mounts your host filesystem read-only, and serves a web UI showing live metrics: CPU utilization and model, memory consumption, disk usage across mounted drives, network up/down throughput, and GPU stats for NVIDIA cards [README].

The project is built by a single developer (MauriceNino) and sits at 3,393 GitHub stars with an active Discord community [README][GitHub]. It’s MIT licensed, meaning you can deploy it, fork it, or embed it with no restrictions. The tech stack is React, Node.js, and Express — nothing exotic [website].

The stated design intent is glassmorphism: translucent panels over dynamic backgrounds, smooth value animations, dark and light modes. The GitHub README shows side-by-side screenshots. This is not a monitoring tool that prioritizes information density over aesthetics. It is specifically designed to look good [README].

The niche it occupies is narrow and intentional. From the README: “a modern server dashboard… intended to be used for smaller VPS and private servers.” If you need multi-server federation, long-term metric retention, anomaly detection, or alerting, dashdot won’t do it. If you need to know whether your one box is alive and under what load, dashdot does it better-looking than anything else in the category.

Why people choose it

The GitHub community and Discord point to a consistent pattern of why people land on dashdot specifically. A few recurring reasons:

Visual quality beats everything in the category. Self-hosted server monitoring tools have historically been either powerful-but-ugly (Grafana before you spend a weekend theming it, Netdata’s dense chart wall, Cockpit’s functional-but-corporate look) or simple-but-forgettable. Dashdot made aesthetics a first-class feature. The glassmorphic design, described on the website as “Monitoring has never looked this good,” resonates with homelab users who double-screen on wall-mounted displays or share their setup on r/selfhosted [website][README].

Single-container simplicity. The install path is one docker run command. No separate Prometheus to configure, no Grafana datasource to wire up, no alertmanager rules to write. For someone who wants a dashboard on my server and not a monitoring infrastructure, this is the right scope [README].

Privacy first. The website is explicit: “Everything stays on your machine. Dashdot doesn’t send data anywhere and works fully offline.” For a monitoring tool that reads CPU, disk, and network — data that can reveal a lot about server activity — this matters [website].

ARM support out of the box. The Docker image supports both x86 and ARM64, which means it runs on Raspberry Pi without extra configuration. The website explicitly says “perfect for your Raspberry Pi or small VPS” [website]. This is not universal among self-hosted monitoring tools — some drop ARM support or require separate builds.

Lightweight footprint. The Docker image is ~210 MB. That’s relevant when you’re running it on a 1 GB RAM VPS alongside your actual workloads and every container allocation counts [website].

Features

From the README and documentation:

Live metrics dashboard:

CPU: real-time utilization percentage, processor model, per-core breakdown [docs]
Memory: current RAM utilization [docs]
Storage: disk usage across all mounted drives [docs]
Network: live up/down speed and cumulative transfer data [docs]
GPU: usage monitoring — but only NVIDIA, and only via Docker with --privileged [docs]

UI/UX:

Glassmorphic design with dynamic backgrounds and smooth animations [README]
Dark mode and light mode [README]
Mobile-responsive layout [docs]
Live demo available at https://dash.mauz.dev [README]

Deployment:

Single Docker container, AMD64 and ARM64 [website]
Docker Compose support [README]
Source build option [docs]
Read-only host filesystem mount for data collection [README]

Configuration:

Entirely via environment variables — no config files, no YAML [docs]
Extensive customization options for appearance and behavior [docs]
Documented at https://getdashdot.com/docs/configuration

Integrations (limited):

REST API available [merged profile]
No native alerting integrations
No Slack/email/webhook notifications out of the box

What it doesn’t do:

No historical data or time-series graphs — metrics are session-live only
No multi-server/multi-node support — one instance per machine
No alerting or threshold notifications
No user authentication on the dashboard by default (you secure it via your reverse proxy)
No log viewer or process manager
GPU support is NVIDIA-only and requires privileged Docker access [docs]

The scope is deliberate. This is not Netdata, which has 300+ collectors and its own alerting engine. It’s a status panel with serious design investment. Judge it on that axis, not the other.

Pricing: SaaS vs self-hosted math

dash. itself costs $0. MIT license, no cloud tier, no commercial edition [README][GitHub].

The question is what it replaces.

Paid monitoring SaaS alternatives:

Datadog Infrastructure: $15/host/month (annual). One VPS = $180/year.
New Relic: tiered by data ingestion, free tier limited to 100 GB/month. Paid from ~$25/user/month.
Site24x7 Infrastructure: from $9/month for basic server monitoring.
Netdata Cloud: free tier with 14-day retention; paid plans from ~$15/month per node for longer retention and alerting.
Better Uptime / Uptime Robot: these are uptime monitoring, not server metrics — different tool, but often conflated.

Self-hosted math:

If you’re running a single VPS that you already pay for (say $6/month on Hetzner), dashdot adds exactly $0 to that bill. The Docker container runs in the background using minimal resources.

If you’re currently paying Netdata Cloud $15/month for retention and alerts on one node, dashdot saves you $180/year — but you also lose the alerting and retention. It’s not a fair swap unless all you actually use is the live dashboard view.

The realistic comparison: dashdot is not a replacement for Datadog or New Relic — those are production observability platforms. It’s a replacement for the situation where you SSH into your server, run htop, and close the terminal. If your “monitoring” is currently “I occasionally check if things are running,” dashdot gives you a permanent, visual answer for free [website][README].

Deployment reality check

The install is genuinely simple. One command:

docker container run -it \
  -p 80:3001 \
  -v /:/mnt/host:ro \
  --privileged \
  mauricenino/dashdot

Three things to know before you run this:

The --privileged flag is required if you want GPU monitoring. It’s also recommended for full hardware detection. Privileged containers have elevated access to the host. If you’re running dashdot alongside sensitive services, assess whether you’re comfortable with this. The filesystem mount is read-only (ro), which limits the blast radius, but --privileged is still non-trivial from a security standpoint [README].

No built-in authentication. The dashboard is served publicly on whatever port you expose. Standard practice is to put it behind a reverse proxy (Caddy, nginx, Traefik) with basic auth or IP allowlist. If you expose port 80 directly to the internet without this, your server stats are public [docs].

GPU monitoring requires NVIDIA + Docker. If you’re on AMD GPU or running on bare metal without Docker’s NVIDIA toolkit configured, GPU metrics won’t show. The docs are explicit about this [docs].

What you actually need:

Any Linux VPS or local server (also supports macOS and Windows) [website]
Docker installed
Optional: a reverse proxy for HTTPS + auth
~210 MB of image space, minimal RAM overhead [website]

Time estimate: 10 minutes on a server where Docker is already running. 30–45 minutes if you’re adding a reverse proxy and SSL. It’s genuinely the simplest deploy in the monitoring category.

Pros and cons

Pros

Best-looking dashboard in the category. Glassmorphic design with smooth animations. If aesthetics matter to your homelab or you’re displaying this on a secondary monitor, nothing else comes close [README][website].
Zero cost, MIT license. No tiers, no commercial edition, no feature gating [README].
Single Docker container, ~210 MB. Minimal resource overhead, runs fine alongside other containers on a low-end VPS [website].
ARM64 support. Works on Raspberry Pi and ARM-based VPS instances without extra configuration [website].
Privacy by design. No telemetry, no external calls, works fully offline [website].
One-command install. Lowest barrier to entry in the monitoring category [README].
Configurable via environment variables. No config file to manage, easy to version-control your docker-compose.yml [docs].
Live demo available so you can evaluate the UI before installing [README].

Cons

No historical data. Metrics are live only — there are no time-series graphs, no “what was CPU at 3am” capability. If you need that, you need Netdata or Prometheus [docs].
No alerting. No email, Slack, or webhook notifications when CPU spikes or disk fills up. You have to check it manually [merged profile].
No multi-node support. One dashdot instance per machine. For a fleet of servers, you need a separate dashboard (or separate instances) [docs].
GPU monitoring is NVIDIA-only via Docker. AMD GPU, bare-metal installs, or non-Docker setups don’t get GPU stats [docs].
Requires --privileged for full functionality. This is a legitimate security consideration for hardened server environments [README].
No built-in authentication. You need to add auth at the reverse proxy layer — extra step, not optional if exposed to the internet [docs].
Narrow scope by design. Not a replacement for Netdata, Grafana, or Prometheus. If you need log aggregation, process inspection, or alerting, you need a different tool [website].
Solo maintainer. The project is maintained by one developer. The history note in the README about a full git history rewrite in March 2025 (due to repo size issues) is worth noting — it broke existing forks [README].

Who should use this / who shouldn’t

Use dash. if:

You run one or a few private servers (VPS, homelab, Raspberry Pi) and want a clean live view of system health.
You want the best-looking self-hosted monitoring dashboard available and you don’t need alerting or history.
You’re already comfortable with Docker and want a five-minute deploy.
You’re building a homelab display and want something that looks impressive on a wall screen.
You want zero telemetry and fully offline operation.

Skip it (use Netdata instead) if:

You need alerting when CPU, memory, or disk cross thresholds.
You want historical metric graphs with retention.
You need to monitor multiple machines from one interface.
You need 100+ system collectors (processes, containers, databases, web servers).

Skip it (use Grafana + Prometheus) if:

You’re running production infrastructure and need a serious observability stack.
You need custom dashboards, correlations across metrics, and long-term retention.
You have engineering resources to set up and maintain the stack.

Skip it (use Cockpit) if:

You want to actually manage your server (start/stop services, manage users, edit files) through the web UI, not just view metrics.

Skip it (use Uptime Kuma) if:

Your actual need is uptime monitoring and alerting — “is my service responding?” — not server resource metrics. These are different tools solving different problems.

Alternatives worth considering

Netdata — the most capable self-hosted monitoring agent. 300+ collectors, built-in alerting, long-term retention via Netdata Cloud (or local). Significantly more complex to configure. Less polished visually. Strong choice if you need more than a status panel.
Grafana + Prometheus — the production-grade stack. Highly customizable, excellent ecosystem, powerful alerting via Alertmanager. Substantial setup time; not for someone who wants “quick install, it works.”
Cockpit — Red Hat’s server management web UI. Includes basic resource monitoring plus actual administration capabilities (services, storage, networking, terminal). Less visual polish, more utility. Good if monitoring is a secondary need.
Glances — terminal and web UI, multi-platform, wide metric coverage including Docker containers and processes. Closer to htop-in-a-browser than a dashboard. Useful if you want process-level visibility.
Homepage / Heimdall — these are service dashboards (links to your self-hosted apps), not server monitoring. Often confused with dashdot in homelab setups but they’re complementary, not competing.

For the non-technical founder audience this site targets, the realistic shortlist is dashdot vs Netdata. Pick dashdot if you want something installed in ten minutes that looks great and shows you live stats. Pick Netdata if you need alerts and history.

Bottom line

dash. does one thing and it does it well: it shows you what your server is doing right now, and it looks genuinely good doing it. The scope is narrow by design and honest about it. There’s no paid tier trying to upsell you, no telemetry, no configuration complexity. For a homelab operator or a solo founder running a single VPS who wants to stop SSHing in to run htop, the install takes ten minutes and the result is the nicest-looking server panel in the self-hosted category. The trade-off — no alerts, no history, no multi-node — is real, and if you need any of those things you should use Netdata instead. But if you don’t, dashdot removes all the reasons to pay for monitoring SaaS on a single server.

Sources

Primary sources:

[README] GitHub Repository — dash./dashdot README, installation instructions, and configuration. https://github.com/mauricenino/dashdot (3,393 stars, MIT license)
[website] Official website and documentation. https://getdashdot.com
[docs] Dashdot Documentation — installation, configuration, integrations, FAQ. https://getdashdot.com/docs
[GitHub] GitHub project metadata — stars, license, contributor history. https://github.com/mauricenino/dashdot
[merged profile] Structured tool profile — feature flags, canonical metadata, article summaries.