Homarr
Drag-and-drop homelab dashboard with real user accounts and no config files to edit
A dashboard you build in the browser by dragging tiles onto a grid, with 40-plus service integrations, built-in user management and an icon library. It replaces a hand-maintained links page and the per-service bookmark sprawl of a homelab.
Our verdict on Homarr#
Homarr 1.x is the dashboard you pick when the person using it is not going to edit YAML. Current stable is the 1.7x line (v1.77.0, September 2026), shipping weekly, and the whole thing is one container at ghcr.io/homarr-labs/homarr on port 7575 with a /appdata mount and a 64 character hex SECRET_ENCRYPTION_KEY. Two live facts matter. First, the 0.x line is dead: ajnart/homarr was archived in June 2026 and 1.0 was a full rewrite with an incompatible schema, so you migrate through the export page that only exists in 0.15.10 or later. Second, a v2 beta is already public (announced September 2026, no release date), so if you are standing something up now you are on a line that has a known successor. The tradeoff against Homepage is plain: you get a real UI and real accounts, and you give up config you can diff.
Who Homarr is for#
Choose it if
- A household or small team dashboard where someone other than you will add and rearrange tiles
- Anyone who wants per-user boards and OIDC or LDAP login without bolting an auth proxy in front
- People coming off Organizr or a hand-rolled links page who want integrations that show queue counts, not just links
- Unraid and Proxmox users who want the docker integration to fill in tiles rather than typing every service twice
Look elsewhere if
- You want the dashboard config in git; it lives in a SQLite database and the UI is the only supported editor
- You are on armv7 hardware such as a Pi 3 or an older NAS, because the images are amd64 and arm64 only
- You are running a box where 500 MB of headroom is a stretch; Glance does a smaller job in a tenth of the memory
What running it actually looks like#
One container, one absolute-path bind mount to /appdata, port 7575. SECRET_ENCRYPTION_KEY is mandatory: without it the container prints a randomly generated key in the error message and exits, so generate one with openssl rand -hex 32 and store it somewhere you will still have it after a disk failure. Optionally mount /var/run/docker.sock for the container integration. Defaults are SQLite at /appdata/db/db.sqlite; DB_DRIVER and DB_URL switch it to MySQL or PostgreSQL if you would rather. The image bundles nginx and Redis internally and starts them from its own entrypoint, so a single docker compose pull && up -d is the whole upgrade path and schema migrations run on boot. Coming from 0.x you do not upgrade in place at all: export from the old install, import into a fresh 1.x.
Resource profile#
- Memory
- 500 MB idle, around 750 MB in ordinary use. The project documents 500 MB RAM as the hardware minimum. The single container runs Node, nginx and its own bundled Redis under one entrypoint, so the floor is genuinely higher than a plain web app.
- CPU and acceleration
- Single or dual core is the documented requirement. Integrations poll on timers and the ping widget can make it busy if you point it at dozens of hosts; nothing here needs a GPU.
- Storage growth
- The Docker image alone wants about 600 MB of free disk. `/appdata` itself stays small: a SQLite file, uploaded icons and board images, typically tens of megabytes.
- Operational load
- 2 of 5, Light. One container with its state in a single mounted directory, and weekly releases that upgrade in place. The score is not 1 because there is a real database with schema migrations behind the UI, so a bad restore order or a half-copied SQLite file will bite you.
Figures describe a small single-household install and are the working assumptions behind our stack planner. Your numbers will differ with library size, user count and hardware. See methodology.
Data and backup surface#
Everything is under the /appdata mount: db/db.sqlite plus uploaded images and icons. The SQLite file is the whole configuration, so stop the container before copying it or use sqlite3 .backup; a live cp of an in-flight database is how people end up with a board that will not load. Back up SECRET_ENCRYPTION_KEY separately and with the same care as the data, because every stored integration token in that database is encrypted with it and a restore without the key gives you a working dashboard with every integration dead. Nothing under /appdata is regenerable except the icon cache. If you moved to MySQL or PostgreSQL, dump that instead and still keep the images directory.
Derived backup shape
SQLite backup. sqlite3 <db> ".backup out.db" while running, or stop the container and copy. A live cp of a WAL-mode SQLite file can restore corrupt.
Traps and surprises#
0.x to 1.x needs an intermediate version
1.0 was a rewrite with a schema that shares nothing with 0.x, and the old Docker mounts are not readable by the new image. The export tool lives under Management, Tools, Migrate to 1.0 and only exists in 0.15.10 and later, so a box sitting on 0.12 has to reach 0.15.10 first. Export, then import into a parallel 1.x install rather than over the top of the old one.
Lose SECRET_ENCRYPTION_KEY, lose every integration token
That 64 character hex string encrypts the API keys and passwords stored in the database. Restore the database onto a container started with a different key and Homarr comes up looking healthy while every integration fails to authenticate, with no obvious error pointing at the cause. Keep the key in the same vault as the backup, not only in the compose file on the host you are restoring from.
The repo and image moved organizations
Anything you find referencing ghcr.io/ajnart/homarr or github.com/ajnart/homarr is the dead 0.x line. That repository was archived by its owner in June 2026 and the README points at homarr-labs/homarr. Pull ghcr.io/homarr-labs/homarr and read homarr.dev docs, not blog posts that predate the move.
A v2 beta is in the field with no release date
The prerequisites page carries a v2 beta notice as of September 2026, with a separate preview docs site and its own feedback channel, and no fixed release date. Expect another migration eventually. The beta announcement offers a full SQLite backup download before switching images, which is a strong hint about how disruptive the change is; do not run the beta on your only dashboard.
Compose network hostnames break some integrations
Docker Compose puts Homarr on its own network, and integrations that hand a URL to your browser rather than fetching it server-side will emit a name your laptop cannot resolve. The docs call out Dash. specifically. Use the LAN IP or a DNS name that resolves everywhere instead of the compose service name.
Specifications#
- Category
- Dashboards and automation glue
- Licence
- Apache-2.0 (Permissive)
- Written in
- TypeScript / Next.js
- First release
- 2022
- Maturity
- Stable
- Datastore
- SQLite by default; MySQL or PostgreSQL optional
- Default ports
7575- Ships as
- docker, unraid app, kubernetes
- arm64 builds
- Yes
- Identity
- Native OIDC. Credentials, OIDC and LDAP are all first-class in the box, selected through the auth provider environment variables, with per-user and per-group board permissions.
- Replaces
- Start.me, Netvibes, Protopage, Organizr
- Project site
- homarr.dev
- Source
- github.com/homarr-labs/homarr
- Documentation
- homarr.dev/docs/getting-started
Alternatives to Homarr#
Everything else in dashboards and automation glue, closest in operational weight first.
| Tool | Ops load | Idle RAM | Licence |
|---|---|---|---|
| Homepage | 2, Light | 110 MB | GPL-3.0 |
| Glance | 1, Set and forget | 25 MB | AGPL-3.0 |
| n8n | 4, Heavy | 400 MB | Sustainable Use License 1.0 (plus n8n Enterprise License for .ee files) |
Sources#
Facts on this page were checked against the project's own material. Where a number is our own estimate rather than a published figure, the text says so.
Published . Last reviewed . Found something out of date? Tell us and we will fix it and log the change.