Homer

What is Homer?

Homer reads a single config.yml and renders a static dashboard: services grouped into sections, with optional health checks and themes. No database, no admin panel, no runtime state to lose.

Best for

A static start page you edit as a file

Why choose Homer

Homer is the start page for people who would rather edit a file than click through a settings panel. One YAML file defines your services, grouped into sections, and it renders as a fast static page with no database and no admin interface. Because it is static, it loads instantly on a home network and there is no state to lose or back up — the config file is the entire application. It supports optional health checks so a service that is down shows as down rather than as a link that goes nowhere, and themes let you adjust the look without rewriting anything. For a homelab where the services change rarely and you want the page to just work, that simplicity is the feature.

Replaces

• Heimdall
• Dashy
• Homepage

Key features

• One YAML file drives everything
• Groups, icons and optional status checks
• Themes and custom styling
• No database required

What to watch out for

There is no web editor, so every change means editing YAML and restarting or rebuilding, which is fine for a stable setup and tedious if you are constantly adding services. Health checks only work for endpoints that return something meaningful without authentication, so services behind a login will always appear down unless you configure something specific. There is no multi-user support, no permissions and no sharing — it is a personal launch page, not a portal. Icons require you to reference or supply assets, and a missing icon makes the page look broken. Anything dynamic, such as live container statistics, is out of scope.

How to deploy

• Docker with config.yml mounted
• Edit the file and reload
• Serve behind your reverse proxy

Getting started

Start from the example configuration and strip it down rather than building up, because the sample is larger than most setups need. Group services by what you actually do with them rather than by what they are, since that is how you will look for them. Put the config file in version control, because a YAML file is exactly the kind of thing that benefits from a diff and a rollback. Add health checks only for endpoints you know are unauthenticated, and accept that the rest will show as unknown. Keep it on an internal network — it is meant to be reachable when you want to find something, not to be a public page.

Typical setup

One YAML file on a web server or in a tiny container, with no database and no runtime state — the config is the whole application. Services are grouped into sections that match how they are actually used rather than what they are, and the file lives in version control because that is the only way it can be reviewed or rolled back. Health checks are enabled only for endpoints that respond without authentication, and the rest are left untested rather than showing false alarms. It stays on the internal network, because a page that maps every service on the network is not something to publish.

Who should look elsewhere

Do not choose Homer if you want to add services from a browser, or if several people will need to edit it, because there is no UI and no multi-user model. Skip it if you need live statistics, container status or anything beyond a link and a health check. And if your service list changes weekly, the edit-and-redeploy loop will wear thin and a database-backed dashboard will fit better.

Project health

• GitHub stars: 11,638
• Last code push: 2026-09-28
• Open issues: 171
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.