Homepage vs Glance: Which Homelab Dashboard Should You Run?
Homepage vs Glance for a homelab dashboard: YAML service tiles and live widgets vs a single-binary, widget-first feed board. I run both; here's where each wins.
Both of these dashboards run in my homelab: Homepage on my Unraid box, and Glance in its own LXC. This comparison is built from each project’s documentation and configuration options, not from a long head-to-head, so read the verdicts below as researched rather than benchmarked.
What follows is what each tool is, where they differ, and which one fits which kind of board.
The two, in one sentence each
- Homepage (gethomepage.dev): a YAML-configured dashboard built around grouped service tiles, with optional live widgets pulled from the tools you’re already running.
- Glance (glanceapp/glance): a single-binary, single-config-file dashboard built around a widget-first layout, closer to an RSS reader crossed with a status board than a tile launcher.
Both are free, both are self-hosted, both solve the same base problem: fifteen services, fifteen IP:port combinations you don’t want to memorize, one page that gets you to all of them.
Homepage: where it’s good and where it’s annoying
Homepage’s config is a handful of YAML files, not a database, and not a click-to-edit web UI. Services get grouped into sections, so you can organize the board the way you already think about your stack instead of inventing a second taxonomy just for the dashboard.
Where it’s genuinely good: services that expose an API get a live widget instead of a static tile. A monitoring tool reports its status inline, a media server can show what’s active, and anything behind Docker gets a container-state indicator without you having to open a separate tool to check if it’s actually up. You stop treating the dashboard as a bookmarks page and start treating it as a first line of “is everything okay” before you go digging into logs.
Where it’s genuinely annoying: it’s plain YAML with no built-in visual editor. Get an indent wrong in services.yaml and the fix is edit the file, save, refresh the browser, and hope you found it. There’s no drag-and-drop, no in-browser layout builder. If that sounds like a downgrade from something like Homarr, which has its own guide and which does give you a database-backed, click-to-arrange board, that’s a fair read. The trade is that Homepage’s config is a plain text file you can put in git and diff. I’d rather own a file I can version than a database I have to remember to back up.
Icon coverage is the other thing worth knowing before you commit an afternoon to this. Homepage leans on a large community icon set that covers almost everything self-hosted by name, so most tiles look right without you hunting down a logo yourself. The handful of times it doesn’t have an icon for something obscure, you’re dropping in your own image or living with a generic placeholder. Minor, but it’s the kind of small friction that adds up over a full board.
Glance: what it is and what it does
Glance ships as a single binary with a single glance.yml. No database, no plugin marketplace, no separate widgets file to keep in sync with a services file. That alone is a different philosophy from Homepage’s multi-file split. You get one file, one mental model, and a widget-first layout: RSS feeds, a monitor widget for checking whether a set of URLs are responding, a Docker Containers widget for container status, weather, a bookmarks block, and a handful of others, arranged in columns rather than a strict tile grid.
The single-file config is appealing if you want something running in ten minutes and don’t want to think about file organization yet. The widget set leans more toward “information dashboard” (feeds, weather, quick status checks) than Homepage’s “here is every service I run, click one,” which may just mean the two tools are answering slightly different questions rather than one being strictly better.
What the documentation doesn’t settle: how it holds up once you’ve got 20+ services instead of a handful, whether the config stays pleasant at that scale, or whether the widget model ends up covering the same ground Homepage’s docker-aware tiles do. That only shows up after long use, so look at community configs at your scale before you commit.
Side by side
| Homepage | Glance | |
|---|---|---|
| Config format | Multiple YAML files (services, widgets, settings, bookmarks) | Single YAML file |
| Layout model | Grouped tiles by section | Widget columns |
| Live service status | Yes, via widgets and Docker integration | Yes, via a monitor widget (ping/HTTP check) and a separate Docker Containers widget |
| Icon coverage | Large built-in community set | Smaller, growing |
| In-browser editor | No, edit the YAML directly | No, edit the YAML directly |
| Resource footprint | Light | Light |
What should make you switch
Not “Glance falls short.” The question is what would make moving worth it. Judge Glance on three things: whether the widget model handles the same job grouped tiles do once your board has 20-plus services on it, not five; whether the config stays easy to reason about at that size; and whether you have a real reason to move at all. If your current dashboard isn’t broken, isn’t slow, and isn’t missing anything you’ve gone looking for, “newer and interesting” isn’t the same bar as “worth re-wiring a board you use every day.”
If you’re choosing between them today
If you’re starting from zero and just want a dashboard for a stack you’re actively running, in my read Homepage’s maturity and wider icon coverage make it the safer first pick, and the Homarr guide is worth a look too if a click-to-edit board matters more to you than a plain-text config. If you like the idea of one config file and a widget-first layout, and you’re comfortable being an early adopter on your own dashboard, Glance is worth the ten minutes it takes to stand up and see if it fits how you think.
Either way, keep it off the public internet. A dashboard is a map of everything you’re running, which makes it exactly the kind of thing you put behind Tailscale or your reverse proxy’s access list, not on an open port.