Flare

What is Flare?

Flare is a lightweight dashboard that keeps configuration in a single file, supports custom icons and search engines, and is designed to load instantly on a home network.

Best for

A fast, low-maintenance start page

Why choose Flare

Flare is the low-configuration start page for people who find most dashboards heavier than the problem. Configuration lives in a single file, it supports custom icons and multiple search engines, and it is built to load instantly on a home network — which sounds like a small thing until you compare it to a dashboard that queries a dozen APIs before rendering. It has a modern interface, a light footprint, and a philosophy that a launcher should be fast and forgettable rather than a platform. For a stable set of services and someone who wants the page to open in a blink, that is the right trade.

Replaces

• Homer
• Flame
• Dashy

Key features

• Single-file configuration
• Custom search engines and shortcuts
• Optional login protection
• Tiny container image

What to watch out for

It is a small project with a correspondingly small community and documentation that assumes you will read the configuration file. Features are deliberately limited: no live statistics, no per-service status, no user accounts and no layout engine. Anything beyond links, bookmarks, icons and search means editing the config directly. Because it is not widely deployed, an unusual problem has fewer answers available than for the more popular dashboards. The configuration file is the whole application, so keeping a copy in version control is entirely your responsibility.

How to deploy

• Docker with a mounted config directory
• Edit the app config file to add links
• Enable login if exposed

Getting started

Deploy it with its config file on a persistent volume, and copy the configuration into version control from the start so the file has a history. Set your search engines first, since that is the interaction you will use most. Add services in groups that match how you think about them. Keep it on the internal network and put authentication in front if anyone else can reach it. Resist the urge to add a reverse-proxied public endpoint unless there is a reason, because a start page that lists every service on your network is a useful map for someone else too.

Typical setup

Its configuration file sits on a persistent volume with a copy in version control from the first commit, because the file is the entire application. Search engines are set first, as that is the interaction used most, and services are added in groups that match how they are thought about. It remains on the internal network, with authentication in front if others need access, and no public endpoint is created — a page listing every service on a network is a useful map for someone else as well.

Who should look elsewhere

Do not choose it if you want status checks, statistics or any dynamic content — it is intentionally static and fast rather than informative. Avoid it if you value a large community and extensive documentation, because both are thin here. And if a plain HTML page with bookmarks would serve you equally well, that is honestly the simpler option.

Project health

• GitHub stars: 171
• Last code push: 2026-09-21
• Open issues: 16
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.