Homarr

What is Homarr?

Homarr gives you a dashboard you configure entirely in the browser: drag widgets onto a grid, drop in service links with icons, and show live status for your containers without editing a file.

Best for

A dashboard for people who do not want to write YAML

Why choose Homarr

Homarr is the dashboard for people who find YAML an obstacle rather than a feature. Everything is configured in the browser: drag widgets onto a grid, drop in service links, and arrange the layout visually with immediate feedback. It integrates with Docker so containers appear as tiles with live status without you writing any configuration for each one, and it supports several kinds of widgets — calendars, weather, bookmarks, integration status — that make the page useful beyond a list of links. Board layouts can be shared, and the app has a proper user model. For a homelab where several people use the services and nobody wants to maintain a config file, it is the natural choice.

Replaces

• Homer
• Dashy
• Homepage

Key features

• Drag-and-drop grid editor
• Service integrations with live status
• Widgets for weather, calendars, media and more
• Multiple boards and user accounts

What to watch out for

It is a stateful application, which means a database, a persistent volume and something to back up — the small cost of not editing a file. Its layout editor is the product, so it changes between major versions, and the migration path has historically been a source of friction when upgrading across versions. Docker integration requires mounting the socket, which is effectively root on the host and makes the container a serious security consideration. The integration widgets depend on external APIs that occasionally change or rate limit. Running it behind an external address without putting proper authentication in front would expose both the dashboard and its socket access.

How to deploy

• Docker with a persistent config volume
• Mount the Docker socket for container widgets
• Create users before exposing it

Getting started

Deploy it with a persistent volume for its database, and include that volume in your backup routine, since losing it means rebuilding every board by hand. Mount the Docker socket read-only if your configuration permits, and never expose the service publicly — the socket access makes that a serious mistake. Build one board with the handful of services you actually use before adding widgets, so you learn the editor on something small. Use the built-in user management for household access and keep the app on an internal interface. Before upgrading a major version, read the release notes and take a database backup, because the migration is not always automatic.

Typical setup

A container with a database on a persistent volume that is explicitly included in the backup routine, because losing it means rebuilding every board. The Docker socket is mounted read-only where the configuration allows, and the service is never reachable from the internet because of that access. One board is built with the handful of services actually used before widgets are added, so the editor is learned on something small. Built-in user management handles household access, and major version upgrades are preceded by a database backup and a read of the release notes.

Who should look elsewhere

Skip it if you prefer your configuration in a file that lives in version control and deploys reproducibly — Homer or Dashy fits that workflow far better. Avoid it if you cannot grant Docker socket access, because a large part of its value is the container awareness. And do not expose it to the internet, ever, because the socket mount makes it a direct path to the host.

Project health

• GitHub stars: 4,941
• Last code push: 2026-10-01
• Open issues: 169
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.