Dashy: a YAML-configured self-hosted dashboard with status checks and widgets

The problem Dashy solves for people running many local services

Anyone running a homelab accumulates bookmarks. A NAS admin page on one port, a media server on another, a router at a fixed IP, a handful of containers behind a reverse proxy. The browser bookmark bar stops scaling somewhere around the fifteenth entry, and it carries no information about whether anything is actually up. Dashy's stated purpose is to be "the homepage for your homelab": one page listing your services, with a status indicator per item and optional widgets pulling live data from those services. The target user is someone who self-hosts, is willing to maintain a config file, and wants the dashboard to live on their own hardware rather than on a hosted startpage service. The README frames the feature set around that audience: multiple pages, status monitoring, widgets, search, theming, icon packs, optional authentication, and a UI config editor. Nothing in the material suggests a hosted or managed offering, so the deployment model is entirely your responsibility.

How the config file drives rendering, status checks and widgets

The architecture visible from the repository is a Vue single-page application served by a Node process, with all user state in a YAML file. The README is explicit that the mounted /app/user-data directory "must contain at least a conf.yml", and that the same directory can hold sub-config files, item icons, fonts and custom CSS served from the web root. That single file is the source of truth for sections, items, themes, layout options and widget bindings. Status indicators work by having the browser attempt to reach each configured item; the README lists "real-time status monitoring for each of your apps/links/hosts" as a feature, which means the check originates from the client rather than from a server-side poller. The practical consequence is that a service can be reachable from the Dashy container but blocked by CORS or a private network boundary in the browser, and the indicator will report it as down. Widgets follow the same client-side pattern: they display "info and dynamic content from self-hosted services", so each widget needs network access from the browser to the target API. Alternate views (workspace and minimal) and opening methods (new tab, same tab, clipboard, pop-up modal, workspace) are all rendering decisions taken from the same config. There is no database and no service discovery layer in the described design.

Getting an instance running with Docker or from source

The README gives a one-line container start: docker run -p 4000:8080 lissy93/dashy. For anything persistent it shows the fuller form with a bind mount and a restart policy: docker run -d -p 4000:8080 -v /path/to/your/user-data:/app/user-data --name my-dashboard --restart=always lissy93/dashy:latest. Images are published on Docker Hub as lissy93/dashy and on GHCR as ghcr.io/lissy93/dashy, and the README states they are multi-arch for amd64 and arm64. You can pin a version tag such as 4.0.0 instead of :latest. A sample docker-compose.yml exists in the repository root. Building from source requires Node 20 or newer plus git and yarn: clone the repo, fill in ./user-data/conf.yml, then run yarn, yarn build and yarn start. The README also lists one-click deployment templates for Netlify, Vercel and Render, though those presets move the config away from a local bind mount. Port 8080 is the container's internal port; the examples map it to 4000 on the host, which is worth noting because copying the command verbatim and then browsing to 8080 will not work.

Status indicators and widgets depend on the browser, not the server

This is the design decision most likely to surprise a new user. Because checks run from the client, a dashboard served over HTTPS cannot probe plain HTTP endpoints without mixed-content warnings, and a service on a private LAN is only visible if the browser itself is on that LAN or on a VPN with a route to it. Reverse proxies that strip or rewrite paths can also break widget API calls in ways that do not show up in the container logs, since the failing request never reaches Dashy. The README does not describe a server-side health-check proxy, so there is no documented way to move probing off the client. If your dashboard is meant to be reachable from outside your network while the monitored services stay internal, the status dots will be decorative. That is not a defect in the code so much as a boundary of the client-side model, and it is the first thing to test before rolling Dashy out to other people.

Authentication, multi-user access and what the README leaves open

Dashy offers "optional authentication with multi-user access, configurable privileges, and SSO support", plus an encrypted off-site backup and restore feature. The README does not spell out the auth implementation, the supported SSO protocols, or where credentials are stored, so treat those as things to confirm in the linked documentation before exposing an instance to the internet. The same applies to the cloud backup: it is described as optional, encrypted and free, with no detail in the supplied material about the key handling or the storage backend. Configurable privileges imply a distinction between users who can edit config and users who can only view, which matters if the config editor is enabled, because that editor writes to the mounted user-data directory. A read-only mount would make the editor appear to work and then fail on save.

Where Dashy is the wrong tool

Dashy assumes you know what you want to display. There is no discovery of containers, no import from a Docker socket, and no automatic inventory of hosts on your network. If your environment changes weekly and you want the dashboard to follow along, you will be editing YAML each time. The single-file config is also a scaling limit in a different sense: it is easy to read at fifty items and harder to reason about at several hundred, especially when sub-config files and custom CSS are involved. Finally, the project is a personal dashboard, not a monitoring system. Status indicators answer "can my browser reach this right now", which is a different question from uptime history, alerting, or latency percentiles. If you need those, you need a monitoring tool, and Dashy is not trying to be one.

Alternatives and the actual difference in approach

The README itself links an Alternatives section, which is the honest place to start. The most direct comparison is Homepage, the project whose tagline Dashy borrows in its own description ("Dashy is the homepage for your homelab"). Homepage also renders a service dashboard from YAML and also offers widgets, but its integration model is built around per-service widget definitions with a shared set of service presets, and it is commonly deployed alongside a Docker socket for container-aware widgets. Dashy's emphasis is different: a broader set of built-in themes, an in-browser config editor, multiple page support, alternate views such as workspace and minimal, and a PWA build for basic offline access. If your priority is a config file you edit by hand and a UI that you can rearrange without touching text, Dashy's editor is the differentiator. If your priority is widgets that know about your containers without you describing them, a socket-aware dashboard will save you configuration time. Both are self-hosted and neither is a monitoring system.

Licence, maintenance and the cost of staying current

Dashy is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence, and it means you can fork the project if upstream development stops. It does not give you any warranty, and the README makes no support commitment beyond pointing at the documentation and community channels. The release cadence visible in the supplied material is roughly one minor release per month through mid-2026 (4.4.0, 4.5.0, 4.6.0), with the default branch receiving pushes as recently as September 2026, so the project is active. The upgrade cost is low if you pin a version tag and read the release notes between versions, because your state lives in conf.yml rather than in a database that needs migrating. The real maintenance burden is the config itself: every service you add or move is an edit, and every widget you enable is another endpoint your browser must be able to reach. Budget for that, not for patching.

Editorial conclusion

Adopt Dashy if you want a homelab startpage whose entire layout lives in a conf.yml file you can commit, and if you are comfortable editing YAML or using the built-in config editor. Skip it if you need a dashboard that discovers services on its own, or if you cannot expose the container to the browser for status checks and widgets to work. Before committing, verify three things: that /app/user-data is mounted read-write so the config editor can save, that your reverse proxy passes the paths Dashy needs, and that your chosen auth mode matches the exposure of the instance.

Official sources

1. License: MIT
2. lissy93/dashy on GitHub
3. Project website
4. README
5. Releases