Homer Hosting

How Homer works

Homer reads its dashboard structure from YAML and renders a static web interface. Administrators group services into sections, add names, icons, subtitles, tags, and links, then choose layout and theme options. Search and keyboard navigation make a larger collection easier to scan, while supported smart cards can fetch limited status information from selected services.

The dashboard does not proxy, authenticate, monitor, or repair the destinations it lists. Clicking a card sends the visitor to the configured URL, where the destination’s own login and permissions apply. Smart cards depend on browser access to external APIs and may fail when a service blocks cross-origin requests, changes its endpoint, or requires credentials the browser cannot safely expose.

Key Homer features

Homer is a static application, so its configuration and assets are served to visitors. The upstream documentation warns that config.yml is publicly accessible by design. Administrators should not place API keys, passwords, private tokens, or internal secrets in the dashboard configuration, even when a card appears only on an obscure address.

The catalogue persists the /www/assets directory that contains Homer’s configuration and branding files. Homer has no built-in user login, role model, or page-level access control. A custom HTTPS address protects network transport, but the application itself should be treated as a public dashboard unless a separate access layer is explicitly provided outside this app package.

Who uses Homer

Homelab operators use Homer to reach administration panels, media servers, monitoring pages, and documentation. Small teams can publish an internal launchpad for approved tools, while support staff collect frequently used customer, ticket, status, and knowledge links into themed groups.

It is not suitable for storing credentials, enforcing single sign-on, hiding sensitive URLs, replacing uptime monitoring, or acting as a security gateway. Every linked system needs its own authentication, and any status data shown in the browser inherits the limitations of the target API and cross-origin policy.

Self-hosting Homer: requirements and cost

Homer resource use is shaped by public visits, dashboard size, icons and images, search activity, browser-fetched smart-card requests, and configuration reloads. The catalogue records PostgreSQL and MariaDB as Not required and persists the assets directory. Processor use is modest because rendering is static, while image assets and traffic account for most plan consumption.

On AvaHost, Homer uses Plan 1 at €2. The hosted Homer package includes one-click deployment, a custom domain with automated HTTPS, automatic application updates, and scheduled backups. Homer has no built-in authentication, and its configuration is public by design. Do not store passwords, API tokens, or private keys in YAML or assets. Linked services, status APIs, single sign-on, monitoring checks, and access gateways are not included. Keep destination applications protected independently and test smart cards against their browser and CORS requirements.