Homer

Static, fast and simple service dashboard

Dashboards & Startpages ★ 11.6k stars Easy setup Apache-2.0

Homer is a very simple static dashboard for your services, configured with a single YAML file and served as static assets. It targets users wanting the lightest possible start page. It is deployed via Docker or any static host.

Key features

  • Single YAML configuration
  • Pure static, no backend
  • Themes and search
  • Tiny resource use

Pros & cons

Strengths

  • Extremely lightweight
  • Trivial to host
  • Fast

Trade-offs

  • No dynamic widgets
  • Manual config edits

Homer replaces

Last reviewed Aug 26, 2026 · 856 words

Homer is 1 YAML file and a folder of icons, served as static files; nothing runs on the server. The catalogue's 64 MB is generous, because a file_server line in a Caddy you already run could serve it with no container at all. If a start page with grouped links, a search box and a dark theme is what you want, that is the entire reason to pick it, and 11,500 stars say plenty of people want exactly that. If you want tiles that show disk usage, download queues and container status, stop here and go to Homepage, because Homer will not grow into that and was never meant to.

config.yml is the product

title: "Home"
subtitle: "lab"
logo: "assets/logo.png"
header: true
footer: false
theme: default
colors:
  light:
    highlight-primary: "#3367d6"
  dark:
    highlight-primary: "#3367d6"

links:
  - name: "Wiki"
    icon: "fas fa-book"
    url: "https://wiki.example.com"

services:
  - name: "Media"
    icon: "fas fa-photo-video"
    items:
      - name: "Jellyfin"
        logo: "assets/icons/jellyfin.png"
        subtitle: "Movies and TV"
        tag: "media"
        url: "https://jellyfin.example.com"
        target: "_blank"
  - name: "Infra"
    icon: "fas fa-server"
    items:
      - name: "Pi-hole"
        type: "PiHole"
        logo: "assets/icons/pihole.png"
        url: "https://pihole.example.com"

Groups, items, an icon or a logo, a subtitle and a tag: that is the whole vocabulary, and a homelab of 30 services is about 150 lines. The file is read by the browser at load time, so editing it and refreshing is the entire deployment. There is no editor in the UI; the catalogue lists "manual config edits" as a con, and for people who keep the file in git it is the feature.

The "smart cards" are as dynamic as it gets

A type: on an item, PiHole or Ping or a few others, makes the card call that service's API from the browser and show a number or a coloured dot. That is the ceiling. Because the call comes from your browser rather than a backend, it hits the service's CORS policy, and the usual outcome for anything beyond Pi-hole is a card that quietly shows nothing. Treat the cards as a bonus and design the page as if they did not exist; if a card breaks you have lost nothing.

Docker, or any web server you already have

services:
  homer:
    image: b4bz/homer:latest
    ports:
      - "8080:8080"
    volumes:
      - ./assets:/www/assets
    environment:
      - INIT_ASSETS=1
    restart: unless-stopped

INIT_ASSETS=1 copies a sample config.yml and icon set into an empty volume on first start, which is the fastest way to get a page to edit, and the container runs as an unprivileged user by default. The alternative is to download the release archive, drop it in a directory, and let Caddy or nginx serve it next to everything else, which is what I do on the box that already terminates TLS: one fewer container for something that is, in the end, a web page.

Icons come from 2 places. icon: takes a Font Awesome class name, which is bundled, and logo: takes a path under assets/, where the community dashboard-icons collection gives you a matching PNG or SVG for practically every self-hosted app.

Static means public if you are careless

A static page has no login, and this one lists the URL of every service you run. Put it behind whatever protects the rest of the stack: forward auth from Authelia or Authentik at the reverse proxy, or simply keep it reachable only on the LAN or over Tailscale. Homer's single-user design is a consequence of the same fact; there are no accounts to give different people different pages, though you can run 2 copies with 2 config files in 2 subdirectories in about a minute.

Against Homepage, Dashy and Heimdall

Homepage is the widget-first dashboard: it reads Docker labels, polls service APIs from a backend so CORS is not your problem, and shows live data on the tiles, at the cost of a Node process and a config that takes an afternoon. Dashy adds in-browser editing, status checks and a long theme list, and is heavier still. Heimdall sits between them, a PHP app with a database and a click-to-add interface, for people who never want to open a YAML file. Homer is the lightest thing in the dashboards category by a wide margin, and it loads in the time the others take to render their first widget.

What I'd do

If your dashboard is a list of links you open 20 times a day, run Homer as static files under the reverse proxy you already have, keep config.yml in the same git repository as your compose files, and ignore the smart cards. The page will load instantly on a phone, survive every update for years because there is nothing to update, and cost nothing to run. The day you catch yourself wanting to see the Sonarr queue on the tile, switch to Homepage in an afternoon; the YAML groups translate almost line for line.

Compare Homer

11 head-to-head comparisons.

Similar dashboards & startpages apps