Homarr 1.76: A drag-and-drop dashboard that trades YAML for a grid you can actually touch

What Homarr actually is and who it serves

Homarr is a self-hosted dashboard for people who run a pile of services on a home server or a small VPS. The README lists integrations for AdGuard Home, Plex, Jellyfin, Pi-hole, Home Assistant, Immich, and dozens more. If you have a NAS with a media stack plus a couple of network tools, Homarr gives you one page that links to them and shows live status. The target user is the homelab operator who wants a polished front end without writing configuration files. The project's own pitch is explicit: "no YAML involved." That sentence is the core of its identity. It competes with dashboards that treat config as code, and it deliberately walks the other way. For a family member who just wants a big button for Plex and a tile for the weather, that is the right call.

The mechanism: a grid, not a file

The configuration model is a drag-and-drop grid system. You place widgets and app icons on a canvas, resize them, and the layout is stored internally. The README does not say what the storage format is, but it is not YAML. The absence of a config file is the defining architectural choice. The project also ships an icon picker with over 11K icons, so you do not need to hand-edit SVG paths or hunt for favicon URLs. The live data comes through a stack the README names explicitly: WebSockets, tRPC, and Redis. Real-time widget updates flow through that path. So the data model is split: the layout is in the app's own store, and the live metrics come from integrations via a realtime channel. That is a clear separation, but it means the dashboard is not a static site. It needs a backend process that maintains those connections.

Getting it running: Docker, Helm, and the hardware floor

The README points to an installation section on homarr.dev and lists compatibility with Windows, Linux, TrueNAS, and Unraid. It highlights x86, Raspberry Pi, and old laptops as supported hardware. The primary deployment path is a Docker image, built by the project's own CI workflow. For Kubernetes, there is a Helm chart, described as "extensive" and aimed at "scaling and high reliability." The actual install command is not in the README, so you will need to follow the docs link. The release cadence is active: v1.76.2 came out on 2026-08-27, with three releases in the same week. That tells you the project is maintained, but it also means upgrades come frequently. The Docker image is the simplest route: pull the image, mount a volume for data, expose a port. The Helm path is for people who already run a cluster and want replicas. Neither path is shown verbatim in the README, so budget time to read the installation docs.

Where the real-time claim gets complicated

The README says realtime widget updates use WebSockets, tRPC, and Redis. That is three pieces of infrastructure to keep alive. Redis is an external dependency, not something Homarr bundles. If you run the Docker image on a Raspberry Pi, you now have a second container or a system service to manage. That is a real operational cost. A dashboard that only shows static links would not need Redis. Homarr's live widgets, like a Pi-hole query counter or a Jellyfin now-playing card, justify it, but only if you actually use those widgets. If you just want a bookmark page, the Redis requirement is overhead. The README also mentions BCrypt and AES-256-CBC for encrypting "valuable data," which suggests some integrations store credentials. That encryption is a plus, but it also means there is a key management question. The docs do not explain where the encryption key lives. That is a gap you should investigate before storing API tokens for your media server.

Authentication and user management: built-in but not trivial

Homarr ships authentication out of the box, with user management, permissions, and groups. It also supports single sign-on via OIDC and LDAP. That is more than most dashboard projects offer by default. The README lists these as features, not as configuration steps. So you get a login screen on first run, but the setup path is not described in the README. For a single-user homelab, the built-in user system may be overkill, but it is useful if you share the dashboard with a household. The permission model means you can give a guest read-only access and an admin full control. The OIDC and LDAP support is the feature that matters for a homelab that already has an identity provider. The README does not say which providers are tested. That is a verification step. If you rely on Authelia or Keycloak, you need to confirm the flow works before you commit.

A real limitation: the integration list is the ceiling

Homarr's value is tied to its integration list. The README shows 40+ integrations, but that is a finite set. If your service is not on the list, you get a generic tile with a link and an icon, but no live widget. The list includes common homelab tools, but it omits many niche ones. For example, the README shows no entry for Grafana, which is a popular self-hosted tool. That means you cannot put a Grafana panel on your dashboard as a native widget. You can still link to it, but the real-time data path is closed. The other limitation is the reverse: some integrations are listed with a null docs link in the README, like ArchiveTeam Warrior and Audiobookshelf. That suggests those integrations exist but have incomplete documentation. So the integration count is not the same as the documented integration count. Check the specific docs page for your tool before you rely on a widget.

The alternative: dashboards that treat config as code

The main alternative is a dashboard like Dashy or Heimdall, which are also self-hosted but take a different approach. Dashy, for instance, uses a YAML config file for layout and widgets. That is the opposite of Homarr's drag-and-drop model. The difference is not cosmetic. A YAML-based dashboard can be versioned in git, reviewed in pull requests, and deployed from a known state. Homarr's grid is stored in its own database, so you cannot diff your layout or roll it back with git. For a homelab that treats infrastructure as code, that is a real loss. For a user who hates YAML, it is the selling point. The README even says "no YAML involved" as a bullet point, so the project knows exactly what it is trading. If you want reproducibility, pick Dashy or similar. If you want a point-and-click UI, pick Homarr. There is no middle ground here.

Maintenance and upgrade cost: frequent releases, Apache-2.0

Homarr is under active development, with three releases in a single week. That means bug fixes and features land often, but it also means you need to track updates. The project is licensed under Apache-2.0, which is permissive and allows commercial use with attribution. That is a low-license-risk choice for a homelab or a small business. The upgrade path is not documented in the README, but with a Docker image, you would typically pull the new tag and restart the container. The Helm chart complicates upgrades slightly, because you need to update the chart and the image version together. The encryption feature (AES-256-CBC) means you must be careful with your data volume during upgrades, because losing it could lose encrypted credentials. The README does not mention a migration guide. So the maintenance cost is moderate: frequent updates, a Redis dependency, and a data volume you need to back up. That is acceptable for a homelab, but it is not a set-and-forget tool.

Editorial conclusion

Adopt Homarr if you self-host several apps and want a dashboard that non-technical users can rearrange without touching config files. Skip it if you need a stateless, single-binary dashboard or if your deployment can't run Redis alongside the app. Before adopting, verify that your target integrations are in the supported list and check the Helm chart's resource requirements if you plan Kubernetes. Then test the OIDC or LDAP login path with your identity provider, because authentication is built in but the exact flow is not documented in the README.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes