# Dashy: a self-hosted dashboard configured by a single YAML file

> Dashy is a Vue-based personal dashboard for homelabs, shipped as a multi-arch Docker image and steered by conf.yml. It is easy to stand up and hard to outgrow, but the YAML is the product.

**lissy93/dashy** — 🚀 A self-hostable personal dashboard built for you. Includes status-checking, widgets, themes, icon packs, a UI editor and tons more!

- Repository: https://github.com/lissy93/dashy
- Website: https://dashy.to
- Stars: 26,599 · Forks: 1,945
- Language: Vue
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/lissy93-dashy

## What Dashy is for, and who ends up running it

A homelab tends to accumulate bookmarks: the router admin page, three container UIs, a NAS, a media server, a couple of internal tools. Dashy's job is to collapse that into one page you can set as a browser start page. The README calls it "the homepage for your homelab", and the feature list backs that framing: multiple pages, per-link status monitoring, widgets that pull live data from self-hosted services, instant search by name, domain or tags, and a choice of launch behaviour (new tab, same tab, clipboard, pop-up modal, or workspace view).

The audience is narrow and clear. You need to be comfortable editing a YAML file or using the built-in UI editor, and you need somewhere to run a Node process or a container. People who want a dashboard generated automatically from Docker labels will find Dashy's model backwards: here the config is the source of truth and the running services are just entries in it. People who want a hosted bookmark manager with no server are not the audience at all.

## How the config, the server and the UI fit together

The repository layout tells most of the story. server.js is the entry point (package.json sets "main": "server" and "start": "node server"), built on Express. The front end is Vue 3 with vue-router and vue-i18n, built by Vite into dist/, which the Express server serves. Configuration lives in user-data/conf.yml, and the Dockerfile copies services/ and the config schema into the image so the server can validate and serve them.

At runtime the mounted /app/user-data directory is the contract. The README is explicit that this directory "must" contain at least a conf.yml, and that it can also hold sub-config files, item icons, fonts, custom CSS, or anything else served from the web root. That is a real design decision: assets are files on disk, not database rows, so a backup is a directory copy and a migration is a file move. The schema is published as JSON (src/utils/config/ConfigSchema.json) and validated with ajv, which is what makes the UI config editor able to lint your YAML as you type rather than after a restart.

Status indicators are the one part that is not purely static. The image installs iputils-ping and grants cap_net_raw to the ping binary, so the server can perform reachability checks from inside the container rather than relying on the browser. Widgets are separate: they call out to the services you configure and render the responses, which means a widget is only as good as the API behind it.

## Installing Dashy with Docker and getting a first page

The README's quickest path is a single container run. It publishes the app on host port 4000 and maps container port 8080, which is the port the image sets via PORT=8080.

```bash
docker run -p 4000:8080 lissy93/dashy
```

That gets you the default dashboard with no persistence. For anything real, mount a directory for config and assets. The compose file in the repository does this, with the volume line commented out so you have to opt in:

```yaml
services:
  dashy:
    container_name: Dashy
    image: lissy93/dashy:latest
    ports:
      - 4000:8080
    volumes:
      - ./user-data:/app/user-data
    environment:
      - NODE_ENV=production
    restart: unless-stopped
```

Save that as docker-compose.yml, create ./user-data, and put a conf.yml inside it before running docker compose up -d. The README states the mounted directory must contain at least conf.yml. If you skip it, expect the app to come up without your content rather than to fail loudly. The compose file also defines a healthcheck that runs node /app/services/healthcheck.js every 90 seconds with a 30 second start period, so docker ps will tell you whether the server actually came up.

From source, the README requires Node 20 or later plus git and yarn: clone the repository, fill in ./user-data/conf.yml, then run yarn, yarn build and yarn start. That path is for contributors and for people who want to modify the front end, not for a normal deployment.

## Where Dashy gets awkward

The single-file YAML model is the selling point and the main failure mode. Once you have a few dozen items, widgets and pages, conf.yml becomes a large document with no includes beyond what you arrange yourself, and the README does not document rollback, schema migration between versions, or what happens to an existing conf.yml when a release changes the schema. The config validator script (yarn validate-config) exists, which is a signal that invalid configs are a real category of problem.

Offline behaviour is limited. The README describes the PWA as providing "basic offline access", not full operation, so a status dot or widget that depends on a live request will not be meaningful without a connection. Multi-user access is optional and described as configurable privileges with SSO support, but the README does not document an audit trail or per-user views.

Finally, the search-related noise around this name is worth naming. A large share of what people type about "Dashy" concerns a Call of Duty player and a streamer, not this project. If you are searching for help, add the maintainer or the term homelab, or you will land on the wrong results entirely.

## Dashy versus Homepage, Homarr and Heimdall

The comparison people actually search for is Dashy against Homepage, Homarr and Heimdall, and the difference is where configuration comes from. Dashy is config-first: you write conf.yml, the UI editor edits that same file, and the dashboard reflects it. Homepage is also YAML-driven and is commonly used for a denser service list with widgets, but it targets a leaner presentation than Dashy's themed, icon-heavy layout. Homarr takes the opposite approach and derives much of its content from the container runtime, so the dashboard tends to follow your Docker environment rather than a hand-written file. Heimdall is the closest in spirit to Dashy's link-launcher role, with a narrower set of features and a different application-based config model.

The practical consequence: if you redeploy containers often and want the dashboard to keep up, a runtime-derived tool will save you editing. If you want a specific layout, custom CSS, multiple pages and a particular set of widgets, Dashy gives you more knobs, and you pay for them in YAML maintenance. There is no single winner here, only a question of whether you would rather maintain a config file or a set of labels.

## Licence, releases and the cost of keeping it current

Dashy is MIT licensed, and the Dockerfile carries the matching org.opencontainers.image.licenses="MIT" label. For most self-hosters that means you can run it, modify it and redistribute it, including inside a company, provided you keep the copyright notice and licence text. It does not give you warranty or support, and it does not cover the third-party services your widgets call, whose own terms apply. None of this is legal advice; read LICENSE in the repository if the distinction matters to you.

Maintenance cost is mostly your config, not the software. The last push to the repository was on 2026-09-05, and releases 4.4.0, 4.5.0 and 4.6.0 landed on 2026-07-04, 2026-07-26 and 2026-08-21, so the project is moving at a steady cadence. That cuts both ways: frequent releases mean features arrive, and they also mean the config schema can shift. Pinning to a tag such as lissy93/dashy:4.6.0 rather than :latest is the cheap insurance, and the README notes that images are multi-arch for amd64 and arm64, so a pinned tag works on a Raspberry Pi as well as a VPS. Keep your conf.yml in version control next to the compose file and an upgrade becomes a diff you can read.

## Conclusion

Adopt Dashy if you run a handful of self-hosted services behind a browser bookmark and want the links, status dots and widgets in one place. Skip it if you need server-side rendering, a database-backed config, or a dashboard that works fully offline. Before committing, run docker compose up -d with your own conf.yml mounted at /app/user-data, confirm the healthcheck passes, and check whether the widgets you actually want are listed in the docs.

## FAQ

### How do I install Dashy?

The README gives a one-line Docker run, docker run -p 4000:8080 lissy93/dashy, or a compose file that mounts ./user-data to /app/user-data. You can also build from source with Node 20 or later, yarn, yarn build and yarn start.

### How do I set up Dashy?

Create a user-data directory containing a conf.yml, mount it at /app/user-data, and start the container. The README states that directory must contain at least conf.yml, and it may also hold sub-config files, icons, fonts and custom CSS.

### What is Dashy?

Dashy is a self-hostable personal dashboard built for homelabs, written in Vue and licensed MIT. It supports multiple pages, per-link status monitoring, widgets, themes and a UI config editor.

### Dashy vs Homepage: what is the difference?

Dashy is config-first, with conf.yml as the source of truth and a UI editor that writes to it. Homepage is also YAML-driven but aims at a leaner service list, while Dashy offers more layout, theming and widget options to maintain.

### Dashy vs Homarr: which should I pick?

Homarr derives much of its content from the container runtime, so the dashboard follows your Docker environment. Dashy reflects a hand-written conf.yml instead, which gives you more control over layout and pages at the cost of editing that file.

### What are the alternatives to Dashy?

The README links an alternatives section in the docs. The tools most often compared with it are Homepage, Homarr and Heimdall, which differ mainly in whether configuration comes from a file or from the container runtime.

## Sources

- [License: MIT](https://github.com/lissy93/dashy/blob/master/LICENSE)
- [lissy93/dashy on GitHub](https://github.com/lissy93/dashy)
- [Project website](https://dashy.to)
- [README](https://github.com/lissy93/dashy/blob/master/README.md)
- [Releases](https://github.com/lissy93/dashy/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lissy93-dashy