2026.09.18
Dashy: A Customizable Dashboard for Self-Hosted Services
Dashy gives homelab and self-hosting users a configurable homepage with pages, status checks, widgets, search, themes, icons, and optional authentication. Deployment still requires careful planning for configuration, networking, access control, and updates.
What it is for
Dashy is a self-hostable personal dashboard designed to act as a homepage for a homelab. It does not replace the services it links to; instead, it organizes access to applications, hosts, and service information in one customizable interface. This makes it useful when a self-hosted environment has grown beyond a small collection of bookmarks.
Main capabilities
Dashy supports multiple pages, allowing services to be grouped by purpose, environment, or user. Optional status indicators can check applications and hosts. The README describes application checks based on HTTP responses and host checks using ICMP ping. Widgets can display dynamic information from self-hosted services, while search can cover names, domains, or tags.
The interface includes built-in themes, a color editor, custom CSS, several icon sources, configurable layouts, and different launch methods. It also offers minimal and workspace views, PWA support for basic offline access, and multilingual support. Authentication is optional; the project documents basic authentication and Keycloak-based single sign-on. These options should be checked against the official documentation before being used in a real deployment.
The 4.7.0 release lists a calendar widget, an htmlSrc option for embedded widgets, and improvements to the Uptime Kuma widget, along with status-check fixes. These are release-noted capabilities, not a guarantee that every integration will work without additional configuration.
Who it suits
Dashy is a good fit for homelab users running several web services and wanting a more structured entry point. It may also suit small teams that need an internal service directory. Users familiar with YAML, Docker, reverse proxies, and identity systems will be better positioned to manage persistent data, routing, and authentication. For a few simple links, however, Dashy’s widgets, checks, and customization options may add unnecessary maintenance.
Limitations and deployment considerations
Docker is a practical deployment path, but the mounted /app/user-data directory must contain at least conf.yml. It may also contain sub-configurations, icons, fonts, and custom CSS, so backup and file-permission planning matter. The README states that the images support amd64 and arm64; operators should still verify the selected tag, architecture, and release policy at deployment time. Source deployment requires Node LTS, Git, and Yarn, which introduces dependency and build-management considerations.
Status checks and widgets may need to reach other services. Before deployment, verify network routes, DNS, cross-origin behavior, certificates, credentials, and reverse-proxy rules. If the dashboard is exposed publicly, access control, TLS, logging, and update procedures should be designed separately. Having authentication features does not by itself prove that a deployment is securely configured. Cloud backup, external widgets, and embedded content should also be reviewed for data sensitivity.
The repository metadata identifies the project as MIT-licensed and not archived. Regular releases do not mean every update is production-ready for every environment. A sensible approach is to pin a tested version and maintain a rollback path for both the application and its configuration.
Sources
Sources checked: 2026-09-18