Monitoring a home server or self-hosted infrastructure without a proper dashboard means constantly SSH-ing into machines, running htop, and guessing why something feels slow. Dashdot fixes that with a clean, real-time system dashboard you can run entirely on your own hardware.
What Dashdot Actually Does
Dashdot is a lightweight, self-hostable server dashboard that displays live CPU usage, RAM consumption, storage, network throughput, and GPU stats in a minimal, visually polished interface. Unlike heavier monitoring stacks that require Prometheus, Grafana, and a separate database just to show you a line graph, Dashdot ships as a single Docker container with no external dependencies. You get a working dashboard in under five minutes.
The project is open source and actively maintained on GitHub. It runs a Node.js backend paired with a React frontend, and it pulls system metrics directly from the host machine using OS-level APIs. There is no agent to install separately, no configuration file to wrestle with before you see anything useful, and no account creation required. You open it in a browser and your server stats are already there.
Dashdot supports Linux hosts natively, and works well on Debian, Ubuntu, Raspberry Pi OS, and similar distributions. Windows and macOS hosts are possible through Docker Desktop, though metric accuracy on those platforms can vary depending on how Docker exposes system resources. For most self-hosters running a Linux home server or NAS, native Linux is the intended and most reliable environment.
One design decision worth understanding upfront: Dashdot intentionally shows a snapshot of the current state rather than long-term historical graphs. If you need weeks of retained metric history and alerting thresholds, a tool like Netdata or a Grafana stack serves that purpose. Dashdot is for quickly glancing at what your server is doing right now – it prioritizes speed and simplicity over deep analytics.
Installing Dashdot with Docker Compose
The cleanest way to deploy Dashdot is with Docker Compose. Before starting, make sure Docker and Docker Compose are installed on your Linux host. On Debian or Ubuntu, that means running sudo apt update && sudo apt install docker.io docker-compose -y, then confirming the install with docker –version. If you already manage other self-hosted services – whether that is a self-hosted PDF toolkit or a media stack – you likely have Docker running already and can skip straight to creating the Compose file.
Create a directory for Dashdot and navigate into it:
- mkdir ~/dashdot && cd ~/dashdot
Then create a file named docker-compose.yml and paste the following configuration:
- version: ‘3’
- services:
- dashdot:
- image: mauricenino/dashdot:latest
- container_name: dashdot
- restart: unless-stopped
- privileged: true
- ports:
- – “3001:3001”
- volumes:
- – /:/mnt/host:ro
The privileged: true flag is required because Dashdot reads system-level hardware data that Docker containers cannot normally access. The volume mount /:/mnt/host:ro gives the container read-only access to your host filesystem, which is how it reads disk usage and other OS metrics without a separate agent. This is not a security hole as long as the container image itself is trusted and the volume is mounted read-only, which it is by default in this config.
Start the container with docker-compose up -d. Docker pulls the image on first run, which takes a minute or two depending on connection speed. Once it finishes, open a browser and navigate to http://your-server-ip:3001. You should immediately see CPU, RAM, storage, and network widgets displaying live data. If any widget shows as unavailable, it usually means the host system does not expose that particular metric through the APIs Dashdot uses – this is common with virtual machines that abstract GPU and some network interface data.
To confirm the container is running correctly, use docker ps and look for the dashdot container with a status of Up. If something went wrong, docker logs dashdot shows the startup output and typically points directly at the issue – a missing privilege flag or a port already in use being the two most common problems on a first install.
Configuring Dashdot with Environment Variables
Dashdot’s behavior is controlled through environment variables passed in the Compose file. Adding an environment: block beneath the container definition unlocks options like custom page titles, widget visibility toggles, network interface selection, and storage device filtering. For example, setting DASHDOT_PAGE_TITLE=Home Server changes the browser tab label, and DASHDOT_SHOW_HOST=true displays your hostname prominently in the header. If you have multiple disks and only want to monitor specific ones, DASHDOT_STORAGE_POLL_INTERVAL and disk filter variables let you exclude loop devices and temporary filesystems that would otherwise clutter the storage widget.
Network interface selection matters most on machines with multiple NICs or virtual interfaces created by Docker itself. By default Dashdot may pick up Docker’s internal bridge interfaces alongside your real ethernet port, which skews throughput numbers. Setting DASHDOT_NETWORK_SHOWN_DATAPOINTS and using the interface name filter – typically matching your actual interface like eth0 or enp3s0 – keeps the graph accurate. After editing the Compose file, apply changes with docker-compose up -d –force-recreate to restart the container with the new environment loaded.
