Dashy vs Homepage

Dashy and Homepage are both YAML-configured start pages for a homelab or a small VPS: a grid of links to your self-hosted services, status indicators, and widgets that show numbers from those services. Both run as one container, both are MIT or GPL open source, and both keep the whole dashboard in files you can copy or commit. The differences are in how you edit those files, where the widget requests come from, and how much each one knows about Docker.

One conf.yml, or a directory of YAML

Dashy keeps its configuration in one file, conf.yml, in the mounted /app/user-data directory. The README says that directory "must" contain at least a conf.yml, and it can also hold sub-config files, icons, fonts and custom CSS. Extra pages are separate config files listed under pages.

Dashy can also be edited in the browser. Right-click an item and choose "Edit", or enter Edit Mode, and changes show immediately. The README says they "will not be saved until clicking 'Save to Disk' or 'Save Locally'". The config menu can also export, back up or reset the config, and it has a raw editor with schema validation. disableConfigurationForNonAdmin stops non-admin users from changing it.

Homepage splits its configuration across several files in /app/config: services.yaml, widgets.yaml, bookmarks.yaml, settings.yaml, docker.yaml and others. It copies in a skeleton version of any file that is missing. You change the page by editing those files; the docs open with YAML tips ("Indentation matters") and suggest a linter.

If you want YAML as the source of truth but also want to fix a typo from your phone, Dashy has the editor. If the files are going into Git and you want one file per concern, Homepage's layout fits.

Docker discovery

This is the clearest feature difference.

Homepage can add services from Docker labels. Put homepage.group, homepage.name, homepage.icon and homepage.href labels on a container and its automatic service discovery adds the tile. With the Docker socket mounted (read-only in the README example), it also shows container status and stats. The docs cover remote Docker hosts over TCP with TLS, and recommend a docker-socket-proxy "due to security concerns with exposing the docker socket directly". There is Kubernetes and Proxmox config as well.

Dashy's docs describe no label discovery: items are entries in conf.yml. Where its docs mount the Docker socket, it is into helper containers such as Autoheal, Watchtower or Glances, and its management guide has a section headed "Don't Expose the Docker Daemon Socket". You keep the socket away from the dashboard, but every new service is another YAML entry.

Where widget requests come from

Homepage's README says "all API requests to backend services are proxied, keeping your API keys hidden". Widgets call Sonarr, Jellyfin or Pi-hole from the Homepage server, and the key in services.yaml never reaches the browser. Config values can also come from HOMEPAGE_VAR_* and HOMEPAGE_FILE_* environment variables.

Dashy leaves more to the widget. Its widget docs label each widget's CORS status. Some call the API straight from the browser. Others go through Dashy's built-in proxy, either because the widget forces it or because you set useProxy: true. The docs warn that "widget options are sent to the browser", so a secret such as a private calendar URL should go in a DASHY_-prefixed environment variable, which the proxy substitutes "server-side, so the URL never reaches the browser". Status checks are different: Dashy's docs say "all requests are made straight from your server". It checks HTTP responses and can also send an ICMP ping to a host.

On Dashy, check each widget you use and keep API keys out of conf.yml when other people can open the dashboard.

Login and access control

Dashy has several options. Built-in auth lists users in conf.yml, each with a SHA-256 password hash and an optional type such as admin. On its own that login is client-side only. Its built-in auth guide says setting ENABLE_HTTP_AUTH=true makes "every API endpoint, every .yml file, and every server-side route" require a valid session. It also warns that per-user visibility rules are "UI-only". Dashy also supports guest access, header auth from a reverse proxy, Keycloak, and generic OIDC with guides for Authentik, Authelia and Pocket ID. Its auth docs say "never expose your Dashy instance to the public internet or untrusted users without sufficient authentication".

Homepage added a login gate in v2.0: HOMEPAGE_AUTH_ENABLED=true, a cookie secret, the external URL, and either one password or an OIDC provider. The README calls it an "authenticated or not" guard; there are no users or roles. The docs warn that it does not rate-limit password attempts, and they still recommend a reverse proxy with authentication, or a VPN, for public deployments.

So Dashy has per-user roles and guest access. Homepage has one door. For anything on the internet, both projects recommend putting an authenticating proxy in front.

Features only one of them has

Dashy:

• Three views: the default page, a minimal view for use as a browser start page, and a workspace view that keeps several apps open.
• Opening methods per item: same tab, new tab, a pop-up modal, workspace, or copy the URL to the clipboard.
• Built-in themes with a UI colour editor, and custom CSS.
• An optional cloud backup that encrypts the config in the browser and stores it in a Cloudflare Worker's KV store, so you can restore it on another instance.

Homepage:

• Docker label discovery and container stats, described above.
• Quick Launch, which searches your services as soon as you start typing.
• "Over 100 service integrations" and support for "over 40 languages", per the README.

Both have web search and information widgets such as weather and Glances.

Footprint and install

Both are one docker run with a mounted directory, and images for amd64 and arm64. Dashy publishes on Docker Hub (lissy93/dashy) and GHCR, with version tags you can pin. Homepage's one extra step is HOMEPAGE_ALLOWED_HOSTS, required since v1.0. It must list the host (and port) you open the dashboard on, or requests fail host validation.

Measured idle on our GCP e2-standard-2 test box (2026-09-29), Dashy used ~40 MB of RAM and Homepage ~102 MB. Neither publishes a minimum; our 256 MB floor for each is an estimate. Dashy's README says 1 GB of memory "should be more than enough", which is a ceiling, not a floor. We rate both 1 out of 5 to deploy, and both installs are tested on this site.

Dashy is MIT; Homepage is GPL-3.0. For a private dashboard, neither licence asks anything of you.

Which to choose

Choose Dashy if you want a single conf.yml that you can also edit in the browser, per-user logins with roles and guest access, or its minimal and workspace views. Turn on ENABLE_HTTP_AUTH if you use its built-in users, and use DASHY_ environment variables for anything secret in widget options.

Choose Homepage if you want tiles that appear from Docker labels, container stats on the page, and widgets whose API calls always go through the server. Set HOMEPAGE_ALLOWED_HOSTS and put it behind an authenticating proxy or its own password gate before it faces the internet.

Choosing between Homepage and Dashy

Starting from Homepage, the usual reason to move is editing: you want to change the page from the browser, or give family members their own logins. Starting from Dashy, the reason is usually Docker: labels that keep the page in step with your containers. If you would rather drop YAML entirely and build the dashboard with drag and drop, see Homarr vs Homepage.