Glance (glanceapp/glance): A Self-Hosted YAML Dashboard for Your Feeds

The problem Glance solves, and who ends up using it

Most people who self-host accumulate a dozen browser tabs: a feed reader, a subreddit, a Hacker News front page, a weather page, a Grafana panel, and a terminal running docker ps. Glance exists to collapse that into one page. The README describes it as "a lightweight, highly customizable dashboard that displays your feeds in a beautiful, streamlined interface," and the widget list backs that up: RSS, subreddit posts, Hacker News posts, weather forecasts, YouTube channel uploads, Twitch channels, market prices, Docker container status, server stats, and custom widgets.

The audience is narrow and specific. You are comfortable editing YAML by hand, you already have a machine that stays on (a VPS, a home server, a NAS that runs containers), and you want a page that loads fast on a phone. Glance assumes you are the only user. There is no mention of accounts, roles, or per-user layouts in the README, so it is a personal or household dashboard, not something you hand to a team.

The design bet is that configuration files age better than admin panels. A YAML file diffs cleanly, lives in git, and survives upgrades. The cost is that every change is a text edit, and a malformed file is a broken dashboard.

How Glance renders a page: widgets, columns, and YAML

A Glance instance is a Go binary that reads YAML, fetches remote data on the server side, and serves HTML. The repository layout confirms the shape: main.go at the root, an internal/ directory for the application code, and a pkg/ directory for reusable pieces. The dependency list in go.mod tells you what the fetching layer actually is: gofeed for RSS and Atom parsing, gjson for pulling fields out of JSON APIs, gopsutil for the server stats widget, and fsnotify, which is how the process notices that you edited a config file without a restart.

The configuration model is pages, columns, and widgets. A page is a tab. A column has a size, small in the README's example. Widgets sit inside columns and each one declares a type plus its own options. The README's sample config shows a calendar widget with first-day-of-week: monday, and an rss widget with limit, collapse-after, cache, and a feeds list where each entry has a url and an optional title and per-feed limit.

Two details in that example are worth reading closely. The cache key takes a duration, written as 12h, which means the server holds fetched results rather than hitting every feed on every page load. And collapse-after controls how many items stay visible before the widget folds the rest away. Both are per-widget, so a slow feed and a fast one can be tuned independently.

The README claims uncached pages usually load within about a second depending on internet speed and widget count. That is a server-side fetch budget, not a rendering budget, and it is the number that degrades first as you add widgets.

Installing Glance with Docker Compose and adding a first feed

The README recommends the provided docker-compose template. This command creates a glance directory, downloads the template archive, and strips the leading path components so the files land in the current directory.

mkdir glance && cd glance && curl -sL https://github.com/glanceapp/docker-compose-template/archive/refs/heads/main.tar.gz | tar -xzf - --strip-components 2

After that you get a docker-compose.yml, a config directory containing home.yml and glance.yml, an assets directory, and a .env file. The README says to edit docker-compose.yml for the port and volumes, config/home.yml for the home page widgets, and config/glance.yml for the theme or extra pages. Then start it:

docker compose up -d

If the page does not come up, the README points at docker compose logs. For a manual compose file instead of the template, the README gives this minimal service definition, which mounts ./config into /app/config and publishes port 8080.

services:
  glance:
    container_name: glance
    image: glanceapp/glance
    restart: unless-stopped
    volumes:
      - ./config:/app/config
    ports:
      - 8080:8080

To add a feed, open config/home.yml and add an rss widget to a column. The README's example uses these keys, and a widget like this fetches the feed, keeps the newest ten items, and caches the result for twelve hours.

- type: rss
  limit: 10
  collapse-after: 3
  cache: 12h
  feeds:
    - url: https://selfh.st/rss/
      title: selfh.st
      limit: 4

Save the file. Because fsnotify is in the dependency list, the process is built to pick up configuration changes without a restart, though the README does not spell out which changes require one.

The binary path is different. If you skip Docker, the README says the binary looks for glance.yml in the directory it sits in, and that you can point it elsewhere:

/opt/glance/glance --config /etc/glance.yml

On Windows, the README says to extract the release zip, put glance.yml beside the executable, run it, and open http://localhost:8080. The Dockerfile confirms the container's default entrypoint is /app/glance --config /app/config/glance.yml, which is why the compose volume target is /app/config.

Where Glance breaks: rate limits, config errors, and no accounts

The README's own troubleshooting section names the most common failure: requests timing out. The stated cause is ad-blocking DNS services such as Pi-Hole or AdGuard Home, which ship with a fairly low default rate limit. Each widget that fetches a remote URL is a DNS lookup, and a page with many widgets can exceed that limit quickly. The prescribed fix is to raise the rate limit in the DNS service, not to change anything in Glance. That is an awkward dependency: a dashboard's reliability is partly governed by a resolver you installed for a different reason.

The second failure mode is configuration. Everything is YAML, and the README does not document a schema validator or a rollback path for a bad edit. If you break the file, the symptom is a dashboard that does not render, and your recovery path is your own backup or version control. Nothing in the README describes a dry-run flag or a config check command.

The third is scope. There is no mention of authentication, user accounts, or access control anywhere in the README. If the dashboard aggregates a private feed, an internal status page, or server stats, you are responsible for putting it behind a reverse proxy or a VPN. Glance itself does not appear to offer that layer.

Finally, the widget set is fixed. The README points to community widgets and a configuration document, so extension happens through configuration and custom widget definitions rather than a plugin runtime. If the service you care about is not covered, you are writing a custom widget, not installing one.

How Glance differs from Homepage and Dashy

The closest comparison is Homepage, another self-hosted, YAML-configured dashboard in the same category. The practical difference is what the dashboard is for. Homepage is built around service links and integrations with the apps you run, so its center of gravity is a grid of bookmarks with status indicators. Glance's widget list leans toward content feeds: RSS, subreddits, Hacker News, YouTube uploads, Twitch channels. If your start page is mostly "jump to these ten services," Homepage matches that intent more directly. If it is mostly "show me what is new," Glance does.

Dashy sits at the other end. It is oriented around a customizable link dashboard with a visual configuration editor, which is the opposite trade from Glance's hand-edited YAML. That editor is an advantage if several people maintain the page or if you dislike editing files; it is a liability if you want the whole configuration to live in a git repository as plain text.

The distribution model is Glance's other differentiator. The README describes a single binary under 20 MB for multiple operating systems and architectures, and a Docker image built from a two-stage Dockerfile that compiles with CGO_ENABLED=0 and copies the result onto alpine. There is no database in the dependency list, no Redis, no Postgres. State is the YAML files and whatever cache the process holds. That makes backup a directory copy, and it makes the upgrade path a container pull or a binary swap.

Maintenance, releases, and the AGPL-3.0 licence

The last push to the main branch was on 2026-05-30, the same date as the v0.8.5 release. The two releases before it, v0.8.4 and v0.8.3, are dated 2025-06-10 and 2025-05-19. That is a gap of roughly a year between v0.8.4 and v0.8.5, which tells you the release cadence is irregular rather than steady. Plan for long stretches without a new tag, and check the release page rather than assuming a schedule.

Upgrade cost is low by design. With Docker, pulling a new image and running docker compose up -d is the whole operation, and the config directory is a mounted volume that the container does not overwrite. With the binary, you replace the file. The risk is not the upgrade mechanics; it is configuration drift, since the README does not document a migration tool for config files between versions. Keep your config in git and read the release notes before jumping.

Licensing is AGPL-3.0, per the LICENSE file at the repository root. The practical consequence for most readers is that running Glance on your own server for yourself is unaffected. The clause that matters is the network one: if you modify Glance and let other people interact with it over a network, the AGPL's source-availability obligation is generally understood to apply to your modified version. That is a description of the licence's intent, not legal advice. If you plan to fork Glance into a hosted product, talk to a lawyer before you build on it.

Editorial conclusion

Adopt Glance if you already run Docker or systemd on a small box and want a hand-edited YAML start page that stays under 20 MB and needs no database. Skip it if you need a visual config editor, per-user accounts, or widgets outside the documented set. Before committing, verify two things on your own host: that your DNS resolver's rate limit is high enough for the number of widgets on one page, and that the binary reads the config path you expect, since it defaults to glance.yml in its own directory unless you pass --config.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes