Homepage: the dashboard that ties the lab together

May 11, 2026

Picture the first month of running a homelab. You have five services you actually care about, and you know roughly where each one lives. Then six months pass. Now there are twenty services, and half the time you can’t remember whether it’s this port or that one, this subdomain or another. You copy login URLs into a notes app. You keep a sticky note on your monitor. You end up with four browser bookmark folders named some variation of “homelab stuff.”

There is a better way, and it is almost embarrassingly simple once you see it: a dashboard. One page. Every service. Live status at a glance.

That’s the whole idea behind Homepage — and it’s what ties this lab together.

What a dashboard actually is

A homelab dashboard is a web page you run yourself that shows tiles for every service you care about. Each tile has a name, an icon, and a link. Many can do more than that: they can pull live data directly from the service they represent, so instead of just a link to your media server you see how many movies and shows are in the library. Instead of a link to your network ad blocker you see the current query count and block rate.

The dashboard doesn’t replace those services. It’s the front door — the place you open first, find what you need, and click through.

For a small lab with a handful of services, this might sound like a luxury. By the time you’re running more than ten services across multiple hosts, it stops being a luxury and starts feeling like a necessity.

The problem it solves

A growing homelab has a specific, quiet kind of friction: cognitive overhead. Not any one service being hard to use, but the accumulation of dozens of small acts of remembering. Which host runs which container? What was the port for that monitoring tool? Which one requires VPN and which one is available externally?

This friction compounds. When you’re troubleshooting something at midnight and you can’t quickly get to the tools you need, the homelab starts feeling like a liability instead of an asset.

A good dashboard attacks this in two ways.

First, it centralizes navigation. One URL, one page. Every service you operate is there, organized the way you think about your infrastructure — not alphabetically in a browser bookmark folder, but in categories that reflect the actual shape of the lab: infrastructure tools here, security tools there, media stack over here.

Second, it surfaces live status. The best dashboards can talk to the services behind the tiles and show you real numbers in real time: current CPU and memory on your hypervisors, pending downloads in your media stack, alert counts from your monitoring stack, uptime status for critical services. You develop a habit of glancing at the dashboard before you start a session in the lab, and in thirty seconds you know whether anything needs attention.

Is there a commercial equivalent?

Honestly, not a direct one. The concept of a “start page” or personal dashboard exists in various forms — browser extensions, web portals, productivity tools like Notion or Obsidian with custom dashboards — but none of them are designed to integrate deeply with self-hosted infrastructure services. They don’t know what Proxmox is, or Gitea, or AdGuard.

The closest commercial parallel is probably the management console of a managed hosting provider or cloud infrastructure platform: a single pane of glass that shows you the health and status of all the resources you’re running. AWS has one. Azure has one. But those exist to manage their platform’s resources, not the collection of Docker containers and VMs you’re running on your own hardware.

In the self-hosted world, the dashboard niche is almost entirely owned by the community. Which is a good thing — it means the tools are built by people who actually run homelabs and know what information they want to see.

The options worth knowing

If you go looking for a self-hosted dashboard, you’ll quickly find a handful of names that come up repeatedly. They’re all free and open source. The differences are mostly in configuration style, visual design, and how deeply they integrate with other services.

Heimdall was one of the early popular choices. It’s clean and simple: you add tiles manually, assign icons and links, and that’s most of it. The application-specific integrations (“Enhanced Apps” in Heimdall’s terminology) are limited compared to newer options. Good for someone who wants minimal setup and doesn’t need live service data.

Dashy is the most customizable of the major options. You configure everything in a single YAML file or through a built-in GUI editor, and you can structure the layout with considerable precision. It also supports a wide variety of status checks and widgets. The tradeoff is that it can feel like more than you need — very flexible, but there’s a lot to configure before it looks and behaves exactly how you want.

Homarr takes a different approach with a drag-and-drop interface and a more opinionated set of integrations. It’s particularly well-suited for people who prefer configuring things through a UI rather than editing config files. It has its own integration ecosystem and a polished look.

Homepage — the one running in this lab — sits in a sweet spot that feels right for a lab that’s already managed with infrastructure-as-code. Configuration is entirely file-based: a small set of YAML files that define your services, widgets, bookmarks, and layout. Those files live in a Docker volume, they can be committed to version control, and they can be deployed automatically. The integration library is large and actively maintained — at time of writing it covers dozens of common self-hosted applications with live-data widgets, not just static links.

The tradeoff is that Homepage has no GUI editor. If you’re comfortable editing YAML and you already manage your infrastructure through config files and code, this is a feature: the dashboard is reproducible, versioned, and deployable like everything else. If you prefer point-and-click configuration, Homarr is probably a better fit.

How it fits in this lab

This lab runs Homepage in a minimal container — one virtual CPU and a gigabyte of RAM is plenty; the service is lightweight by design. The container gets deployed and configured automatically as part of the same infrastructure-as-code workflow used for everything else in the lab.

The dashboard is organized into categories that match the mental model of the infrastructure: infrastructure tooling, security services, observability, AI tools, media stack, and general utilities. Each category has a column of tiles.

The tiles that just link to a service are the minority. Most of them surface live data. The hypervisor tiles show current CPU and memory utilization across the cluster. The media stack tiles show library sizes and active download queues. The network ad-blocker tile shows the current query rate and block percentage. The uptime monitoring tile shows a status summary for everything being tracked.

Widget configuration is where the initial setup effort lives. Each integration requires an API token or credentials for the backing service, and those need to be plumbed through properly — usually via environment variables in the Docker Compose configuration rather than hardcoded in the YAML files. A few integrations have quirks. The Proxmox widget requires a specific token format. One popular secrets management tool lacks a widget entirely in the current version, so it gets a ping-only status tile instead. These are minor details, but worth knowing going in.

The config files themselves are compact. The services file is a straightforward list of categories, each containing tiles with a name, icon, and URL — plus an optional widget block for the services that support live data. The settings file handles cosmetic choices: the page title, color theme, and column layout. The widgets file controls the top-of-page bar items. Docker connectivity goes in its own file. The separation is clean and the learning curve is shallow if you’ve ever written any YAML. Most of the time spent on initial setup isn’t fighting the tool — it’s collecting the tokens and credentials the various integrations need, and organizing the categories in a way that reflects how you actually think about your services.

Updates follow the same pattern as every other Docker-based service: pull the new image, recreate the container. Since all the configuration lives in mounted files, not inside the container, updates are non-destructive. The dashboard comes back exactly as it was.

The dashboard is accessible both internally (no authentication needed on the local network) and externally through a secure tunnel with single sign-on protecting it. The external access is primarily useful when you’re away from home and need to check on something — the same dashboard, the same live data, from anywhere.

Beyond the main service tiles, there’s a bookmarks section for quick links that don’t need live status, and a top bar with the current time, date, and a summary of system resource utilization. It’s the first thing that opens when a browser session starts in the lab.

One architectural detail worth noting: Homepage can connect to Docker hosts directly to show container status. Rather than exposing the Docker socket itself, each Docker host in this lab runs a read-only proxy that Homepage connects to. This keeps the attack surface narrow — the proxy exposes only the specific information Homepage needs, not the full Docker API.

Who should run a dashboard

If you’re running more than a handful of services and you find yourself fumbling for bookmarks or having to look up which port something runs on, a dashboard will immediately earn its keep. The setup investment is a few hours at most, and the return is a persistent quality-of-life improvement.

If you’re early in your homelab journey and you have three or four services running, it’s probably not the first thing to deploy — there are more foundational pieces worth setting up first. But it’s worth putting on the list for when the service count climbs.

The main reason not to run one is if you have genuinely strong opinions about everything being configured through a GUI and none of the GUI-friendly options (Homarr, Dashy’s built-in editor) appeal to you. That’s a legitimate preference. Most people find that the combination of live service data, organized navigation, and reproducible configuration is worth whatever configuration style they have to adapt to.

The broader point

A homelab dashboard is a small service, but it’s one of those small services that changes how the whole thing feels. A lab without a dashboard is a collection of services. A lab with a dashboard starts to feel like a cohesive system.

It’s also a good example of a broader principle in self-hosting: the infrastructure to manage your infrastructure is worth investing in. Monitoring, documentation, automation, and yes, navigation — these are the tools that make the actual services sustainable to run over time. The homelab that’s genuinely enjoyable to operate three years in is the one where the overhead of managing it stayed manageable as it grew.

Homepage is one of the simplest, highest-return investments in that direction.

← all posts