Run Glance as a Self-Hosted Dashboard With Docker Compose

Put Glance in front of your feeds, bookmarks, and a few operational widgets when you want a fast dashboard surface, not another oversized monitoring platform.

Glance Docker Compose Dashboard
Illustrated guide cover for Run Glance as a Self-Hosted Dashboard With Docker Compose
Glance • Docker Compose • Dashboard
What you learn

How to deploy Glance, mount a clean glance.yml, add a first page, and keep the dashboard private and lightweight.

Best for

Operators who want one browser landing page for feeds, bookmarks, service links, and a small amount of at-a-glance status.

Risk to watch

The common mistake is trying to turn a dashboard into a source of truth for deep monitoring, secrets, and public admin access all at once.

Before you begin

  • A Linux host with Docker Compose v2.
  • A place to store the Glance config directory.
  • A short list of feeds, bookmarks, or internal links you actually check daily.
  • A plan to keep the dashboard on localhost, behind a VPN, or behind an authenticated reverse proxy.

Glance's current upstream install docs describe a compact Docker Compose setup that mounts ./config to /app/config and expects a glance.yml there. The project is explicit about being lightweight and configurable through YAML, which makes it a good fit for a small self-hosted home page.

Expected outcome: you will finish with Glance serving one useful page from a local config directory and a dashboard that stays in the lane of quick visibility rather than pretending to replace proper monitoring.

Step 1: Create the Glance stack

Create the stack directory and config folder:

mkdir -p /opt/stacks/glance/config
cd /opt/stacks/glance

Save this as compose.yaml:

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

The upstream Compose example publishes port 8080. Binding it to 127.0.0.1 is the safer first move for an admin-facing dashboard because it keeps the service private until you intentionally proxy or tunnel it.

Step 2: Build a first useful glance.yml

Glance reads configuration from YAML files. Start small instead of loading every widget you can find on day one.

Save this as /opt/stacks/glance/config/glance.yml:

pages:
  - name: Home
    columns:
      - size: small
        widgets:
          - type: calendar
            first-day-of-week: monday
          - type: rss
            title: Self-hosting
            limit: 5
            collapse-after: 3
            cache: 12h
            feeds:
              - url: https://selfh.st/rss/
                title: selfh.st
      - size: full
        widgets:
          - type: bookmarks
            groups:
              - title: Admin
                links:
                  - title: Portainer
                    url: https://portainer.example.com
                  - title: Beszel
                    url: https://beszel.example.com
          - type: monitor
            title: Public checks
            sites:
              - title: Main site
                url: https://example.com
              - title: API
                url: https://api.example.com/health

Upstream docs include a downloadable starter glance.yml. This stripped-down version is enough to prove the layout, the YAML mount, and a useful first page without turning setup into a research project.

Start the container and verify it loads:

docker compose up -d
docker compose ps
docker logs glance --tail 50

Step 3: Keep the dashboard private-first

Glance is a dashboard surface. That means it can easily collect links and status signals that point at sensitive tools. Treat it as an internal asset unless you have a clear reason to expose it more broadly.

Two safer access patterns:

  • Keep the localhost bind and reach it through SSH port forwarding.
  • Place it behind an authenticated reverse proxy or a private tailnet/VPN.

If you already use Authelia or Tailscale for dashboards, Glance fits naturally behind the same gate. Do not publish it openly just because it looks like a harmless landing page.

Step 4: Add widgets without overpromising

Glance supports many widget types, and the upstream README highlights feeds, weather, server stats, Docker container status, and custom widgets. That does not mean every dashboard should mount the Docker socket or collect live metrics immediately.

Use these rules of thumb:

  • Bookmarks, RSS, and simple monitor widgets are low-risk starters.
  • Server stats are useful when they stay informational and not your only alert signal.
  • Docker-aware widgets deserve extra caution because they often imply socket access or sidecar integrations.
Caution: if a widget requires access to the Docker socket, treat that as privileged host access. Do not mount /var/run/docker.sock casually just to make a dashboard look more impressive.

Step 5: Operate and update the stack

Routine checks:

cd /opt/stacks/glance
docker compose ps
docker logs glance --tail 50
sed -n '1,120p' config/glance.yml

Update the container like any other small Compose service:

cd /opt/stacks/glance
docker compose pull
docker compose up -d

When changing the dashboard, edit one section at a time and reload. Small YAML errors are easy to fix when you know the last thing that changed.

Rollback notes

Glance is easy to roll back because the important state is mostly your config directory. Keep a copy of glance.yml and any extra CSS or assets you add. If an update goes wrong, revert the image tag or the config change before you start rewriting the whole dashboard.

Troubleshooting

The container starts but the page is blank or wrong.
Check docker logs glance for YAML parse problems and confirm the config volume is mounted to /app/config.

A widget times out.
Reduce scope first. Verify the target URL from the host, then remove nonessential widgets until the page is clean again.

You want deep historical metrics and alerting.
Glance is not that system. Pair it with real monitoring such as Beszel, Uptime Kuma, Prometheus, or Netdata instead of stretching the dashboard past its strengths.

You are tempted to expose it publicly.
Use a private access pattern or an auth gate. Dashboards often leak operational context even when they do not hold credentials directly.