Homarr vs Homepage

Homarr and Homepage are the two self-hosted start pages people most often weigh for a homelab or a small VPS: one page with a tile for every service, status dots, and widgets that pull numbers from Sonarr, Jellyfin, Pi-hole and the rest. Both are Next.js apps shipped as one container, and both read live data from the services they link to. The split is in how you edit them. Homarr is edited in the browser with drag and drop and keeps its state in a database, with real user accounts. Homepage is a set of YAML files you edit on disk, with an optional password or OIDC gate in front.

Editing: a drag-and-drop board or YAML files

Homarr calls each dashboard a board. Its docs describe "a complex drag-and-drop system that can be used from the browser", and its README says app management needs "no YAML involved". You can create as many boards as you want, set a column count, and give each board separate layouts for different screen widths. Apps, widgets and integrations are all added from the UI, and the icon picker covers "over 11K icons".

Homepage is configured through YAML files in its config directory. When one is missing, it copies in a skeleton file: services.yaml, widgets.yaml, bookmarks.yaml, settings.yaml, docker.yaml, kubernetes.yaml, proxmox.yaml, plus custom.css and custom.js. You change the page by editing those files. The docs spend their first page on YAML tips ("Indentation matters") and suggest running a linter before deploying. If you already keep your Compose files in Git, the dashboard can live in the same repository.

That is the main question. If you want to click a tile into place, pick Homarr. If you want the dashboard in version control, Homepage is built for that.

Docker integration

Homepage can build the page from your containers. Add labels such as homepage.group, homepage.name, homepage.icon and homepage.href to a service, and Homepage's automatic service discovery adds it. With the Docker socket mounted (read-only in the README's example) it also shows container status and stats. The docs cover reaching a remote Docker host over TCP with TLS, and they suggest a docker-socket-proxy container "due to security concerns with exposing the docker socket directly".

Homarr uses the socket for more than reading. Its Docker stats widget lists container resource use, and each row has actions to view logs, start, stop, restart or remove the container, or add it to Homarr as an app. The widget is limited to administrators. The standalone docker run in Homarr's docs mounts the socket read-write. Our install line leaves it out, so add -v /var/run/docker.sock:/var/run/docker.sock if you want this widget.

Container actions are a real difference. Mounting the socket read-write into a web app gives that app control of the Docker host, so leave it out unless you want those buttons.

Users and access

Homarr has real accounts. Its README lists "user management with permissions and groups" and single sign-on via OIDC or LDAP. The AUTH_PROVIDERS variable picks credentials (the default), ldap or oidc. The first admin is created in the onboarding screen. Boards can be restricted to groups or made public, and each user can have their own home board. A family can share one instance, each person with their own board.

Homepage added login in v2.0. It is a simple gate: set HOMEPAGE_AUTH_ENABLED=true, a signing secret and the external URL, then either HOMEPAGE_AUTH_PASSWORD for one shared password or the HOMEPAGE_OIDC_* variables for an identity provider. The README calls it an "authenticated or not" guard. There are no per-user views, and with OIDC the docs say Homepage "grants access to any identity" the provider authorizes for the client. They also warn that there is no rate limiting on password attempts, and they still recommend a reverse proxy with authentication, TLS and Host checking, or a VPN, for anything reachable from an untrusted network.

API keys and the proxy

Both tools call your services from the server, not from your browser. Homepage's README says "all API requests to backend services are proxied, keeping your API keys hidden". Homarr encrypts what it stores; its README names BCrypt and AES-256-CBC. The SECRET_ENCRYPTION_KEY it requires is the key for those stored secrets. Homarr's docs say that if the key is missing, the container prints a random one in the error message and exits. Keep the key: our install writes it to homarr.env so a re-run reuses it.

Homepage has its own required variable. Since v1.0, HOMEPAGE_ALLOWED_HOSTS must list every host name (with port where needed) you use to reach it. The docs say this "helps prevent certain kinds of attacks when retrieving data from the homepage API proxy". If the page loads with host-validation errors, the exact host from the logs has to be added to the list.

Integrations and widgets

Both cover the usual homelab set: the *arr apps, download clients, media servers, DNS blockers and system stats.

• Homepage's README counts "over 100 service integrations", including Radarr, Sonarr, Plex, Jellyfin, Emby, qBittorrent, Transmission and SABnzbd. It also has information widgets for weather, time, search and Glances, plus Quick Launch, which searches your services as soon as you start typing.
• Homarr's docs list integrations such as Pi-hole, AdGuard Home, Jellyfin, Plex, Immich, Proxmox, TrueNAS, Unraid, Home Assistant and OPNsense. Widgets include a calendar, media requests, DNS blocker controls, an RSS feed, system health and a notebook. Its README says widgets update in real time over WebSockets, and its built-in search reaches into integrated services.

Neither list is a reason to choose on its own. Check that the few services you care about are on the one you pick.

What runs inside the container

Homepage is one Next.js process with its YAML config mounted at /app/config. Images are built for AMD64 and ARM64.

Homarr carries more inside its one container. It stores boards, users and integrations in SQLite by default (/appdata/db/db.sqlite), and can use MySQL or PostgreSQL through the DB_* variables. Its docs say Redis runs "within the installation" by default, with an option to point at an external Redis. Upstream asks for at least 500 MB of RAM and 600 MB of free disk, on linux/amd64 or linux/arm64. linux/arm/v7 is not supported. There is also a Helm chart for Kubernetes.

Measured idle on our GCP e2-standard-2 test box (2026-09-29), Homarr used ~135 MB of RAM and Homepage ~102 MB. Homepage publishes no minimum; our 256 MB floor is an estimate. We rate both 1 out of 5 to deploy, and both installs are tested on this site. Homarr's extra step is the encryption key; Homepage's is the allowed-hosts variable.

Licences

Homarr is Apache-2.0. Homepage is GPL-3.0. For a dashboard you run for yourself, neither licence changes anything. The GPL only matters if you distribute a modified Homepage.

Which to choose

Choose Homarr if you want to build the dashboard in the browser, share one instance with several people who each get their own boards and permissions, sign in through OIDC or LDAP, or start and stop containers from a widget. Keep the encryption key somewhere safe.

Choose Homepage if you want the dashboard as text files you can diff and commit, services that appear on the page from Docker labels, and a single lightweight process. Put it behind a reverse proxy with authentication, or turn on its built-in password or OIDC gate, before exposing it.

Choosing between Homepage and Homarr

Starting from Homepage, the usual reason to move is people: several users who each need their own view, or someone who will not edit YAML. Starting from Homarr, the reason to move is usually the opposite. You want the whole dashboard in Git, next to the Compose files it describes. If you like Homepage's YAML approach but want an in-browser editor, see Dashy vs Homepage.