Homepage vs Glance: The Dashboard I Run vs the One I'm Still Testing
A homelab dashboard comparison: Homepage, my daily driver wired into my whole stack, versus Glance, the newer tool I spun up to evaluate but haven't switched to.
I should say up front what kind of comparison this actually is, because it’s not the kind you usually get. I run Homepage. It’s been my daily driver for a while now, it’s wired into most of what’s on my stack page, and I open it more than I open any other tab on this machine. Glance is not that. I spun it up recently because it kept coming up in the same threads Homepage does, and I wanted to see what the fuss was about. I have not lived with it. I have not moved a single tile of my real setup over to it.
So this isn’t “I ran both for six months, here’s my verdict.” It’s the more honest version of that story: here’s the tool I actually depend on, here’s the tool I’m poking at, and here’s what would have to change for the second one to replace the first.
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: what it’s actually wired into
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, and my sections track the same categories I already use to describe this homelab: infrastructure, networking, files and documents, media, monitoring, automation. That’s not a coincidence. The dashboard is a front door onto the same stack I’ve written up in full elsewhere, so it made sense to organize the board the way I already think about the 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 I’ve covered separately 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, the same reason I like Dockge over Portainer for compose stacks. 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 I’ve seen so far
I want to be careful here, because this is the half of the article where I don’t have six months of scar tissue to report. What I can tell you is what Glance is and what it does out of the box, clearly as a first look, not as a verdict.
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 container I stood up for Glance sat outside my normal monitoring setup entirely. It’s not scraped by Prometheus alongside the rest of the stack, because it’s genuinely just something I’m looking at, not something I’ve committed to keeping alive. That’s the most honest signal I can give you about where it sits right now: evaluation, not production.
What I can say from that first look: 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 I can’t tell you yet: 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’s exactly the stuff that only shows up after real use, and I haven’t put in the hours.
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 |
| My status with it | Daily driver, wired into the real stack | Spun up to evaluate, not in daily use |
What would actually change my mind
Not “Glance falls short.” I haven’t run it long enough to say that, and it would be a cheap thing to claim about a tool I’ve barely touched. What I can say is what it would take for me to actually move.
I’d need to see the widget model handle the same job my grouped tiles do once the board has 20-plus services on it, not five. I’d need to know the config stays easy to reason about at that size, the same way I care about Dockge’s compose files staying plain and readable instead of turning into a database. And honestly, I’d need a real reason to move at all. Homepage isn’t broken. It isn’t slow. It isn’t missing anything I’ve gone looking for. “Newer and interesting” isn’t the same bar as “worth re-wiring a board I use every day.”
If Glance clears that bar after I’ve actually lived with it for a while, this article gets rewritten with real mileage behind it. Until then, this is what an honest look at the two of them gets you: one I trust with my whole stack, one I’m still just watching.
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, 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.