Why bother with a dashboard at all

The baseline alternative is a bookmarks folder or a hand-written HTML page, and either one is a legitimate choice if you’re only running a few services and nobody else needs access. What a real dashboard buys you is two things beyond a link list: live status (is Sonarr actually up right now, how much disk is left on the NAS, is a download in progress) pulled directly from each service’s API, and a single, low-friction entry point that works as well for a technical household member as a non-technical one. Neither of those matters until you cross roughly six or seven self-hosted apps. Past that point, “where do I even start” becomes a real daily friction, and a dashboard is one of the highest-value-for-effort things you can add to a homelab.

Homepage: config-as-code, deep integrations

Homepage (the gethomepage project, not to be confused with any site’s literal homepage) is built around a YAML configuration file rather than a point-and-click editor. You define services, groups, and widgets in text files that live in a config/ directory, which means your entire dashboard layout is git-trackable, diffable, and restorable from a backup the same way the rest of your infrastructure-as-code setup already is. That’s a deliberate tradeoff: there’s no drag-and-drop builder, so changing anything means editing YAML and letting the app hot-reload, which is friction for someone who doesn’t want to touch a config file but is a non-issue for anyone already comfortable with docker-compose.yaml.

Where Homepage earns its reputation is integration depth. It ships with first-class widgets for a long list of self-hosted software (the *arr stack, Uptime Kuma, Proxmox, Portainer, Immich, Paperless-ngx, and dozens more), each one pulling real data through that service’s API: active downloads and queue size from Sonarr/Radarr, VM and container status from Proxmox, uptime history from Uptime Kuma, not just a static icon and a link. It also supports Docker label-based auto-discovery, so a service can announce itself to Homepage via labels in its own compose file instead of you hand-adding every entry, which scales well as your stack grows. The cost is mostly upfront: getting widgets working means generating and feeding in API keys for each integrated service, which is more setup work than a plain bookmark grid, but it’s a one-time cost per service.

Homarr: the UI-first option with a similar integration depth

Homarr covers almost the same integration ground as Homepage (Sonarr/Radarr, Proxmox, Docker, Uptime Kuma, and a comparable widget library) but takes the opposite configuration philosophy: everything is built through a drag-and-drop board editor in the browser, not a YAML file. You add widgets, resize and rearrange them visually, and create multiple boards for different users or contexts (a technical “admin” board and a simpler “family” board pointed at the same backend, for example). For anyone who wants the same live-status depth as Homepage without maintaining a text config, this is the more approachable path.

Homarr also supports Docker integration for auto-discovering running containers, and its newer versions have closed most of the integration gap that used to exist between it and Homepage. The tradeoff mirrors Dockge-versus-Portainer from the Docker-management-UI comparison already on this site: a UI-first tool stores its layout and config in its own internal database rather than a portable text file, so backing up your dashboard means backing up Homarr’s own data volume specifically, not just a YAML file you can read in a text editor. If you want your dashboard config to be something you can version-control and read without running the app, that’s a real point in Homepage’s favor. If you’d rather never open a YAML file, Homarr removes that requirement entirely.

Heimdall: simple, mature, and intentionally limited

Heimdall is the oldest of the three and takes a much narrower view of the problem. It’s fundamentally an application launcher: a grid of icons and links with light theming, a handful of basic widgets (weather, a clock, a few built-in app integrations), and a simple web UI for adding and arranging tiles. It does not attempt the live-status, API-driven widget depth that Homepage and Homarr both lean into. There’s no Docker auto-discovery, and its library of deep service integrations is much smaller and has grown slowly.

That narrowness is also Heimdall’s appeal. If what you actually want is a clean, low-maintenance grid of links to your dozen self-hosted apps, with maybe a weather widget, and you have zero interest in pulling live queue status from Sonarr onto the same page, Heimdall does that with less setup and less to maintain than either of the other two. It’s a reasonable pick for a shared household dashboard where “here’s where everything lives” is the whole requirement, or for anyone who finds Homepage’s API-key-per-service setup to be more plumbing than the payoff is worth.

Comparing the practical dimensions

Configuration model: Homepage is YAML-first and git-friendly by nature. Homarr is UI-first with config stored internally. Heimdall is UI-first and simpler still, with less to configure in the first place.

Integration depth: Homepage and Homarr are roughly tied at the top, both offering real live-status widgets for dozens of common self-hosted apps. Heimdall covers far fewer integrations and leans toward static links with occasional basic widgets.

Auto-discovery: Both Homepage and Homarr support Docker label-based auto-discovery of running containers. Heimdall has no equivalent, every tile is added by hand.

Backup and portability: Homepage’s config lives in plain text files, trivial to back up alongside the rest of your infrastructure repo. Homarr and Heimdall both need their own data volume backed up as a unit, since the layout lives in an internal database.

Setup effort: Heimdall is the fastest to get something useful on screen. Homepage and Homarr both take longer upfront, mostly spent generating and entering API keys for each integrated service, in exchange for a dashboard that shows real status instead of just links.

Multi-user boards: Homarr’s multiple-board feature is the strongest fit if different household members need different views of the same backend. Homepage can approximate this with grouping but isn’t built around separate boards the way Homarr is. Heimdall doesn’t offer this at all.

Picking one for your homelab

If you already manage your homelab as config files under git and want your dashboard layout to live there too: Homepage. The YAML-first model fits directly into a workflow you’re probably already running, and the integration library covers almost everything you’d want live status from.

If you want the same integration depth as Homepage but would rather drag-and-drop than edit text, or want separate boards for different people in the house: Homarr. It’s closed most of the feature gap with Homepage and the UI-first model is the more approachable choice for anyone who isn’t comfortable editing YAML.

If all you actually want is a clean grid of links with minimal setup and you don’t care about live status widgets: Heimdall. It solves the “where do I even start” problem without asking for an API key from every service you run.

Bottom line

A dashboard isn’t mandatory the way backups or monitoring are, but it’s one of the cheapest upgrades to daily usability once your service count climbs past a handful. Homepage if you want deep, git-tracked integrations and don’t mind YAML. Homarr if you want that same depth through a UI instead. Heimdall if you just want a landing page and nothing more. None of them lock you in hard enough to matter, the config in all three is small enough to rebuild in an evening if you change your mind later.