Open-source application dashboard, honestly reviewed. No marketing fluff, just what you get when you run it on your own server.

TL;DR

What it is: A statically generated, YAML-configured application dashboard that sits in front of your self-hosted services and shows you their live status, stats, and bookmarks from one page [README].
Who it’s for: Homelab operators, self-hosters with a stack of Docker containers they want to visualize, and anyone tired of remembering which port Jellyfin runs on. Not for non-technical users — YAML configuration is the only way in.
Cost savings: There’s no SaaS to replace here. Homepage itself is free, and it costs nothing beyond whatever VPS or home server you’re already running. The comparison is against paid alternatives like Dashy Pro, or just the cognitive overhead of juggling browser bookmarks.
Key strength: The widest service integration catalog in the category — over 100 widgets for popular self-hosted apps (Radarr, Sonarr, Jellyfin, Plex, Nextcloud, Pi-hole, and dozens more), all proxied so your API keys never hit the browser [README][1].
Key weakness: No built-in authentication. None. This is not a minor omission — it’s a deliberate design choice by the maintainers, and it has resulted in documented remote code execution vulnerabilities against integrated services [2]. If you expose it to the internet without a reverse proxy that enforces auth, you are handing strangers a control panel for your homelab.

What is Homepage by gethomepage

Homepage is a dashboard — a single web page that aggregates the status and live data from all your self-hosted services. You point it at your Jellyfin server and it shows you active streams and library counts. You point it at qBittorrent and it shows active downloads and speeds. You point it at Pi-hole and it shows you how many DNS queries it blocked today.

The project lives at github.com/gethomepage/homepage under a GPL-3.0 license and has accumulated 28,988 stars, which makes it one of the most popular self-hosting projects on GitHub — sitting alongside Nginx Proxy Manager, Portainer, and Immich in the usual “tools every homelab eventually runs” category [4]. Version 1.10.0 shipped in early 2026, indicating the project is actively maintained [3].

The architecture is deliberately minimal. The site is statically generated at build time, meaning what your browser loads is fast, flat HTML with no server-side rendering overhead [README]. All the live service data comes through a backend proxy built into Homepage itself — your browser talks to Homepage, Homepage talks to your services, and your API keys and credentials never leave your server. This is the “secure” in their pitch, and it’s real: the API key protection is genuine [README][2].

Configuration is entirely via YAML files. There is no GUI for setup. You write services.yaml, bookmarks.yaml, widgets.yaml, and settings.yaml, and the dashboard reflects exactly what you specified. Groh’s homelab guide [1] describes this as a feature rather than a limitation — the files are simple enough that copying a Pi-hole or TrueNAS block from community configs takes five minutes, and once they’re done, there’s nothing that can accidentally break them through a UI click.

The project also supports Docker label-based auto-discovery, where properly labeled containers appear in your dashboard automatically without any manual YAML entry [README]. This is the feature that makes it feel magical in an all-Docker homelab.

Why People Choose It

The practical reason Homepage wins is the integration depth. Groh [1] compared several dashboard options for his homelab guide and landed on Homepage specifically because the service widgets surface useful live data, not just uptime pings. His example: instead of a green dot that says “TrueNAS is up,” he gets pool status, storage utilization, and temperature. For a homelab operator, that difference matters every single day.

The community is also a driver. By 2026, Homepage has become a de facto standard in homelab circles — when someone posts a screenshot of their self-hosted setup on r/selfhosted or asks what dashboard to use, Homepage is the answer the thread converges on. That network effect means there are ready-made community configs for almost every popular self-hosted app. You don’t have to figure out what API endpoints your Sonarr instance exposes; the integration already exists and someone already documented it [1].

Docker auto-discovery closes the loop for people running heavy container stacks. Deploying a new service and having it appear on your dashboard automatically — via a label in docker-compose.yaml rather than a manual YAML edit — removes friction from the daily homelab maintenance loop [README].

The multi-architecture builds (AMD64 and ARM64) mean it runs on the same hardware as everything else, whether that’s a cloud VPS, a homelab x86 box, or a Raspberry Pi [README]. The 40+ language translations, managed through Crowdin, put it in the minority of homelab tools that don’t assume English as the only option [README].

Features

Dashboard and display:

Static site generation — loads instantly, no spinners [README]
Bookmarks section for arbitrary links alongside service tiles
Service tiles with live data pulled from each app’s API
Information widgets: weather, time, date, search bar, system resource usage [README]
Customizable layouts, custom CSS and JS, multiple theme options [README]
Full i18n with 40+ languages via Crowdin [README]

Service integrations:

Over 100 service integrations including Radarr, Sonarr, Lidarr, Bazarr, Plex, Jellyfin, Emby, qBittorrent, Deluge, Transmission, Pi-hole, AdGuard Home, Nextcloud, Authentik, Portainer, Uptime Kuma, and many others [README][1]
API keys are proxied through Homepage’s backend — the browser never sees credentials [README]
Ping monitoring per service with configurable thresholds [1]
Live stats displayed per integration (download speeds, library counts, DNS query stats, etc.) [1]

Docker integration:

Automatic service discovery via Docker labels [README]
Container status and resource stats [README]
Works with docker-compose and Docker standalone [README]

Deployment:

Docker Compose install (the standard path)
Kubernetes / Helm support [README]
Unraid support [website]
Source install for non-Docker setups [website]

What it doesn’t do:

No built-in authentication layer (intentional, see the security section) [2]
No write operations to services — it’s read-only display (with a few minor exceptions like media playback controls) [2]
No built-in notifications or alerting
No mobile app — it’s a web interface only

Pricing: Self-Hosted Math

Homepage has no pricing tiers, no SaaS offering, and no commercial license. It’s GPL-3.0 software that you run yourself.

What it costs to run:

Software: $0
Server: whatever you’re already paying for. If you’re running Homepage, you’re almost certainly already running other Docker services on that machine. Homepage adds negligible resource overhead — it’s a static site with a lightweight Node.js proxy backend.
Domain/HTTPS: optional. Most homelab users access it on a local IP or through a reverse proxy they already run.

The comparison to make isn’t against a SaaS — it’s against the alternatives. Dashy (the main competitor) is also free and open source. Homer is free. Flame is free. The cost comparison in this category is denominated in setup time and configuration complexity, not dollars.

If you’re currently managing a homelab without any dashboard, the “cost” is your cognitive overhead — remembering that Jellyfin is at port 8096, Sonarr at 8989, Pi-hole at 80, and so on. Homepage turns that into one page you bookmark once.

Deployment Reality Check

The standard install path is Docker Compose, and it’s short. The docker-compose.yaml is about a dozen lines: image, container name, a required environment variable (HOMEPAGE_ALLOWED_HOSTS), port mapping, and two volume mounts — one for your config YAML files, one for the Docker socket if you want auto-discovery [README].

What can catch you:

The HOMEPAGE_ALLOWED_HOSTS environment variable is required and must be set to your domain or IP, or requests will be rejected. New users who skip this will see their dashboard refuse to load and have to read the error message to find it [README].

The Docker socket mount (/var/run/docker.sock) is needed for container auto-discovery. Mounting the Docker socket gives Homepage — and anything else with access to that container — root-equivalent access to the Docker daemon. The standard mitigation is to use a Docker socket proxy (a container that sits between Homepage and the socket and limits which API calls get through). The README documents this but doesn’t enforce it, so users who copy the quickstart without reading the security context are taking a risk they may not be aware of [README].

The authentication gap is the serious one. Anvil Secure’s security research [2] found that in version 0.8.13, the proxy architecture — the same feature that hides your API keys — could be exploited by an attacker with access to the Homepage interface to send authenticated requests to your integrated services. Their proof-of-concept achieved remote code execution on a Jellyfin server by deploying a malicious plugin through Jellyfin’s admin API, using credentials Homepage had proxied [2].

The key phrase is “with access to the Homepage interface.” If your Homepage is accessible only on your home network or behind an authenticating reverse proxy, this attack requires prior network access. But Anvil Secure found trivially many publicly exposed Homepage instances via Shodan — meaning real users are running it exposed to the internet, with no auth, with Jellyfin and qBittorrent and other services connected [2].

The maintainers have historically declined feature requests to add built-in auth, arguing that Homepage is read-only and auth belongs at the reverse proxy layer [2]. This is architecturally defensible but practically risky: the “put it behind a reverse proxy” advice requires users to have a reverse proxy configured and to know to configure auth on it.

Time estimate for a technical user: 20–45 minutes to a working install, including initial service configuration. For someone new to Docker but following a guide: 1–2 hours. For someone trying to set up YAML configs without any reference examples: budget extra time finding community configs for your specific services.

Pros and Cons

Pros

Widest service integration catalog in the category. 100+ integrations covering essentially every popular self-hosted app [README]. No other open-source dashboard comes close.
API key proxy is genuinely secure. Your credentials don’t hit the browser. This is a real security property, properly implemented [README][2].
Static generation means fast load times. No waiting for server-side rendering on every page load [README].
Docker auto-discovery is a quality-of-life win. Label a container, it appears on the dashboard. No manual config edit required [README].
29,000 stars and active maintenance. The project is well past “someone’s weekend project” — it has momentum, regular releases, and a large community supplying configurations [3][4].
Multi-architecture and multi-language. ARM64 support means it runs on Raspberry Pi and similar hardware. 40+ languages means it’s actually usable for non-English speakers [README].
GPL-3.0 license. Copyleft, but fully open source — no commercial restrictions or “fair-code” complications.

Cons

No built-in authentication. This is the biggest issue. Exposing Homepage to the internet without an authenticating reverse proxy is genuinely dangerous — not theoretically, but demonstrably so via Shodan-discoverable instances and confirmed exploits [2]. The maintainers’ position that auth belongs elsewhere is reasonable for experienced operators and wrong for everyone else.
YAML-only configuration. There is no GUI for setting up services, widgets, or bookmarks. For a non-technical user, this is a hard blocker. You either know YAML or you don’t.
The security track record includes RCE. The Anvil Secure research [2] found vulnerabilities that enabled full remote code execution on integrated services. These were fixed in subsequent versions, but the underlying architecture (a proxy that forwards authenticated requests) remains a meaningful attack surface if access controls fail.
Read-only with narrow exceptions. You can view stats; you can’t manage services from the dashboard. It’s a status board, not a control panel.
No alerting or notification. If Jellyfin goes down, Homepage will show it as offline, but it won’t tell you. You need a separate monitoring tool (Uptime Kuma is the common companion) for that.
GPL-3.0 complicates embedding. If you’re building a product and want to ship a dashboard, GPL-3.0 requires you to open-source your modifications. Less restrictive than AGPL but still relevant if you have commercial intentions.

Who Should Use This / Who Shouldn’t

Use Homepage if:

You’re running a homelab with multiple Docker containers and you want a single page that shows you what’s running and how it’s doing.
You already have a reverse proxy (Nginx Proxy Manager, Caddy, Traefik) that you can put in front of it with authentication.
You’re comfortable editing YAML files and don’t need a setup GUI.
You want the best service integration depth in the open-source dashboard category.
You’re running on ARM64 hardware (Raspberry Pi, Apple Silicon) — full native support [README].

Skip it if:

You’re a non-technical founder or user who has never touched a YAML file. The configuration is not optional or deferrable — YAML is the only configuration interface.
You want to expose your dashboard to the public internet and you don’t understand reverse proxies or authentication. The security risk is documented and real [2].
You need write operations — service restarts, configuration changes, deployments. Homepage doesn’t do that.
You need alerting built in. Pair with Uptime Kuma instead, or use Homepage alongside it.

Use Dashy instead if:

You want a GUI-based setup experience rather than YAML files. Dashy has an in-browser config editor.
You want more visual customization options and icon management.

Use Glance instead if:

You want a more opinionated, lightweight dashboard with a different visual style and a smaller setup footprint.

Alternatives Worth Considering

Dashy — 24,549 stars [4]. Also open source, also Docker-based, but with a GUI config editor. Better for users who don’t want to write YAML. Fewer service integrations than Homepage.
Flame — Lighter-weight dashboard focused on bookmarks and apps, with Docker label support. Less integration depth but simpler to configure.
Glance — Newer entrant with a different visual approach, good for RSS feeds and server monitoring alongside bookmarks. Active development as of 2026 [3].
Homer — The predecessor-era option. Simpler, YAML-based like Homepage, but fewer integrations and slower development cadence.
Homarr — Offers drag-and-drop grid configuration, built-in auth options, and service integrations. More actively developed feature set than Homer. Worth comparing directly against Homepage if YAML configuration is your sticking point.
Organizr — PHP-based, includes authentication options natively. More complex setup but better story around access control for public exposure.

For most homelab operators, the practical choice is Homepage versus Homarr — Homepage wins on integration breadth, Homarr wins on configuration ergonomics and built-in auth options.

Bottom Line

Homepage is the best self-hosted dashboard if you’re willing to write YAML and you have a reverse proxy with authentication already in front of it. The service integration depth is unmatched in the category, Docker auto-discovery removes ongoing friction, and the API key proxy genuinely protects your credentials. At 29,000 GitHub stars and with active releases in 2026, the project is healthy.

The non-negotiable: do not expose this to the internet without authentication. The no-built-in-auth design choice is documented, the exploits are documented [2], and the number of instances found publicly exposed via Shodan suggests many users missed the memo. If you have a reverse proxy with auth in front of it, none of this is a problem. If you don’t, get one before you deploy Homepage.

For non-technical founders specifically — unless you’re deploying this as infrastructure for an already-technical team, the YAML-only configuration will be a hard stop. The tool is excellent for what it is; what it is requires comfort with text-based config files.

Sources

Dustin Groh, Road to Homelab — “The Ultimate Homelab Homepage Guide” (August 24, 2023, updated June 18, 2024). https://roadtohomelab.blog/homelab-homepage-guide/
Daniel Kachakil, Anvil Secure — “Vulnerabilities in Homepage Dashboard” (August 22, 2024). https://www.anvilsecure.com/blog/vulnerabilities-in-homepage-dashboard.html
v3ritas.tech — “w33k in g33k: February 06, 2026” (February 6, 2026). https://v3ritas.tech/posts/2026/02/20260206-w33k_in_g33k_february_06_2026/
RelatedRepos — “nginx-proxy-manager alternatives and similar packages”. https://relatedrepos.com/gh/NginxProxyManager/nginx-proxy-manager

Primary sources:

GitHub repository and README: https://github.com/gethomepage/homepage (28,988 stars, GPL-3.0 license)
Official website and documentation: https://gethomepage.dev