A Dashboard That Stays Out of Your Way
Most server dashboards try to do everything at once – logging, alerting, container management, metrics aggregation – and end up requiring more resources than the services they are supposed to monitor. Dashdot takes the opposite approach. It is a minimal, visually clean dashboard designed to show you exactly what your server is doing without running a background army of agents, exporters, and database processes to do it.
If you are running a home lab or a small VPS and just want CPU, RAM, storage, and network stats at a glance, Dashdot is worth your attention. It ships as a single Docker container, renders a smooth real-time interface in the browser, and stays well under 50MB of memory usage in most configurations. The setup takes under ten minutes, and there is nothing to configure beyond a handful of environment variables.
What Dashdot Actually Shows You
Dashdot surfaces the metrics that matter most during day-to-day server operation: CPU usage per core, RAM consumption, swap activity, disk read/write throughput, and network traffic in and out. All of it updates in real time through a WebSocket connection, so you are watching live data rather than polling a cached snapshot every 30 seconds. The visual presentation leans into a dark-themed, almost artistic aesthetic – animated graphs rather than static tables – which makes it readable at a glance from across a room on a wall-mounted monitor.
The dashboard also displays basic system information: hostname, OS version, uptime, and CPU model. It does not attempt to surface Docker container states, service health checks, or log output. That scope is intentional. Dashdot is not competing with Netdata or Grafana; it is solving a different problem – giving you a quick, always-on visual of server health without any of the overhead those platforms require.
One practical detail worth knowing: Dashdot reads metrics directly from the host system using the systeminformation Node.js library. For this to work correctly when running in Docker, you need to pass through specific host paths and run the container with elevated privileges or at minimum the right capability flags. Skipping this step is the most common reason people see zeroed-out or inaccurate readings on first launch.
Prerequisites Before You Deploy
You need a Linux host running Docker, ideally Docker Compose as well. Dashdot works on x86_64 and ARM64 architectures, so it runs fine on a Raspberry Pi 4 or any standard VPS. Make sure your Docker installation is current – anything past version 20 is fine. No reverse proxy is strictly required to get it running locally, but if you want to expose it over HTTPS you will need one. Nginx Proxy Manager or Caddy work well for this without much configuration overhead.
If you are already running a self-hosted identity provider such as Authentik, you can sit it in front of the Dashdot instance as a forward auth middleware layer to add login protection – particularly useful if you plan to expose the dashboard on a public domain.
Setting Up Dashdot with Docker Compose
Create a directory for the project and add a docker-compose.yml file. The core configuration is straightforward. You map port 3001 on the host to port 3001 in the container, mount /proc and /sys as read-only volumes so the container can read kernel metrics, and pass the –privileged flag or the specific capability set the image requires. The image you want is mauricenino/dashdot:latest from Docker Hub.
A minimal working compose file looks like this: set the image, expose port 3001, mount /proc:/mnt/host/proc:ro and /sys:/mnt/host/sys:ro, and add privileged: true under the service definition. Start it with docker compose up -d and open http://your-server-ip:3001 in a browser. If the graphs are populating with live data, the host mounts are working correctly.
Dashdot supports a solid set of environment variables for customization. DASHDOT_WIDGET_LIST controls which widgets appear and in what order – valid values include cpu, ram, storage, network, and gpu. If you are running a machine with a GPU and want usage metrics surfaced, set the widget list to include gpu and add the appropriate device passthrough in the compose file. DASHDOT_SHOW_HOST set to true will display the hostname prominently at the top, which is useful when you have multiple instances for different machines.
For multi-disk setups, DASHDOT_STORAGE_POLL_INTERVAL controls how frequently disk stats refresh, and you can use DASHDOT_FS_VIRTUAL_MOUNTS to filter out virtual filesystems like tmpfs or overlay that clutter the storage widget with Docker’s internal layers. Getting this right makes the storage section significantly more readable on a machine running many containers. Once you have the configuration dialed in, the dashboard genuinely requires no further attention – there is no database to maintain, no retention policy to set, no agents to keep updated on other machines. The container reads from the host, renders to the browser, and that is the full architecture.
