Flame

Last reviewed Sep 13, 2026 · 810 words

Flame's last significant release was a while ago, its repository is quiet, and I still recommend it to about a third of the people who ask me for a start page. That is not a contradiction. Flame does one small thing, a page of application tiles and bookmark columns with a search bar, and small finished things do not need weekly commits. What you need to decide is whether you want a start page or a dashboard, because Flame is only the first of those.

A start page is not a dashboard

The dashboards category lumps together two products. A dashboard like Homepage or Homarr pulls live data from your services: download queues, disk usage, container status, calendar. A start page like Flame is a nicer version of your browser's new-tab page: links, grouped, searchable, with a clock and the weather. Flame's 6,526 stars come from people who want the second thing and found the first kind noisy. If you catch yourself wanting a Sonarr widget, stop reading and go to Homepage; Flame will not grow one.

Running it, then let Docker labels fill it in

services:
  flame:
    image: pawelmalak/flame:latest
    ports:
      - "5005:5005"
    volumes:
      - ./data:/app/data
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - PASSWORD=change-this
    restart: unless-stopped

That is all of it. The image is TypeScript on Node, uses SQLite in /app/data, and idles well under 128 MB. PASSWORD protects the settings and editing UI; the page itself is public to anyone who can reach port 5005, so put it behind your reverse proxy and whatever authentication you already use. There is no multi-user model, which for a personal home page is fine and for a shared team page is a limit.

The Docker socket mount is optional and the reason I bother with Flame over a static HTML page. With it mounted and Docker integration enabled in settings, any container carrying these labels appears as an application tile automatically:

labels:
  - flame.type=application
  - flame.name=Jellyfin
  - flame.url=https://jellyfin.example.com
  - flame.icon=jellyfin

Add a service to your compose stack and it appears on the start page; remove it and it disappears. flame.icon accepts Material Design Icon names, and there is also custom icon upload. If you run Kubernetes, the same works with ingress annotations. Mounting the socket read-only gives the container visibility into every other container, so weigh that on a shared box; on a personal homelab I accept it.

The rest of the feature list is short on purpose

Bookmarks are grouped in categories with their own icons. The search bar supports bang-style prefixes (/g for Google, /d for DuckDuckGo, /yt for YouTube, and you can add your own) and searches your own apps and bookmarks by default. The weather widget needs a free OpenWeatherMap API key and a latitude and longitude. Custom CSS is editable in the UI. Themes ship in a set of about 20 colour schemes and you can define your own. That is the list. No plugins, no widgets, no status checks, no per-user views.

How it compares

Between Flame and Homer the difference is where configuration lives. Homer is a single YAML file you edit and redeploy; Flame is a UI you click in plus the label discovery. I prefer Flame when I am adding containers often and Homer when the link list is stable and I want it in Git.

The stalled development question

The grid of tiles, the search bar and the Docker integration all work today, on current Docker and current browsers, and there are no known security issues that I am aware of in the image. What you are giving up by choosing a quiet project is a future: if a dependency in the Node build breaks, or a browser change affects the UI, the fix might take a long time or come from a fork. For a start page with no external exposure and no data of value beyond a list of URLs, that risk is small. Export the settings JSON occasionally and you can recreate it anywhere in 5 minutes.

What I'd do

If you want a fast links page and nothing else, deploy Flame with the socket mounted, label your containers, add an OpenWeatherMap key, and forget about it. If you have ever wanted a widget, install Homepage instead; it is the bigger, more active project and the safer long-term choice. Do not run both.