Homepage
inari.homepage
Configuration-driven start page for a self-hosted deployment, showing service links with live status and widgets that pull counts and health directly from each service's own API.
A Docker Compose file for Homepage alone, generated from the catalog and checked by the safety inspector. Sign in and use Kitchen Credits to activate it.
Uses the Medusa cart and payment-session path. This test control does not create an order or capture payment.
Homepage is defined entirely in YAML: services, groups, bookmarks, widgets and layout are declared in configuration files rather than assembled through an interface, which makes the whole page reproducible from a directory. A service entry can carry a widget that queries that service's API for live figures — queue depth, container counts, disk use, transfer progress — so the page reports state rather than only linking to it. Docker and Kubernetes integrations can discover services from labels instead of listing them by hand. A first deployment mounts the configuration directory and declares a handful of services with their URLs.
You know it worked when
- The page loads and shows the services declared in configuration.
- A configuration change is reflected after a reload without rebuilding the container.
- A service widget reports live values from that service's API.
- Links resolve to the intended services from the browser actually being used.
Known sharp edges
- The configuration directory must be mounted and writable at first start, and an empty mount silently produces a default page rather than an error.
- Widgets hold API keys for the services they query, in plain text in the configuration files.
- Docker integration needs socket access, which should go through a filtering proxy rather than a direct mount.
- It has no authentication of its own, so the page and every widget's data are visible to anyone who can reach it.