Heimdall

What is Heimdall?

Heimdall presents your services as tiles with real application icons, and for many popular apps it can show live statistics through built-in integrations rather than just a link.

Best for

A clean launcher for a known set of apps

Why choose Heimdall

Heimdall is the dashboard with the least configuration friction for a known set of applications. It presents services as tiles with real application icons, and for many popular self-hosted apps it ships prebuilt integrations that can show live statistics — download counts, queue sizes, library totals — on the tile itself rather than just a link. Adding a service means picking it from a list and entering a URL, which is considerably faster than looking up an icon and writing a config entry. It has a database so it survives restarts, an optional authentication layer, and it handles being the front door to a media or automation stack well because that is exactly the use case its integrations were built for.

Replaces

• Homer
• Homarr
• Organizr

Key features

• Large library of built-in app icons and integrations
• Live stats for supported applications
• Groups, tags and custom links
• Simple web-based administration

What to watch out for

The application database and configuration live in a persistent volume that must be backed up, and losing it means losing every tile you configured. Its integration support depends on the target applications' APIs staying stable, so a major upgrade of a media server can break the statistics on its tile until the integration is updated. The interface is functional rather than flexible — it does not offer much layout freedom, and the themes are limited. Self-hosted authentication exists but is basic, so it belongs behind a reverse proxy if it is reachable from outside. Development has been less active than some alternatives, which shows in the pace of new integrations.

How to deploy

• Docker with persistent config
• Add applications through the UI
• Enable authentication in settings

Getting started

Deploy it with a persistent volume and add that volume to your backups before you build out the dashboard, because the configuration is the asset. Add a handful of services through the built-in search rather than by hand, since that is where the icon and integration come from for free. Test any integration that requires an API key by confirming the statistics actually appear. Enable the built-in authentication if other people will reach it, and put a reverse proxy with TLS in front for anything beyond the local network. Keep the deployment simple, because the appeal here is that it does not need much maintenance.

Typical setup

A container with a persistent volume holding the application database, added to the backup routine before the dashboard is built out, because the configuration is the asset. Services are added through the built-in search so icons and integrations come along for free, and any integration requiring an API key is confirmed to actually display statistics. Built-in authentication is enabled if other people will reach it, with a reverse proxy terminating TLS for anything beyond the local network. The deployment stays deliberately simple, since the appeal is that it needs almost no maintenance.

Who should look elsewhere

Do not choose it if you want fine control over layout and theming, because flexibility is not what it offers. Avoid it if you run few popular applications, since the prebuilt integrations are most of the value and a dashboard of plain links can be had more cheaply. And if you need an active project with frequent updates, check the release cadence against your expectations first.

Project health

• GitHub stars: 9,343
• Last code push: 2026-09-09
• Open issues: 4
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.