Flame: a self-hosted startpage with built-in editors and Docker label discovery

What Flame solves for people running a server full of apps

Anyone running a home server or a small cluster ends up with a browser bookmarks folder that no longer reflects reality. Services move ports, get renamed, or get replaced, and the bookmarks file is the last place anyone updates. Flame takes the position that the startpage itself should own that list. The README describes it as a self-hosted startpage whose design is heavily inspired by SUI, and the feature list is built around one idea: you create, update and delete applications and bookmarks from inside the app through GUI editors, so no file editing is required.

The audience is narrow but real. Someone running a dozen containers on a home box, or a few ingresses on a small Kubernetes cluster, who wants a landing page that shows what exists and links to it. It is not a monitoring tool, not a status page, and not an authentication gateway for the services behind it. Flame protects its own settings and content, and that is the extent of its security scope.

How Flame is put together: Express, SQLite and a React client

The repository layout is a conventional two-part application. The backend is Node.js with Express, using Sequelize as the ORM over SQLite; server.js sits at the top level alongside routes/, controllers/, models/, middleware/ and db/. The frontend lives in client/ and is React with Redux, written in TypeScript. The package.json lists the runtime dependencies that matter here: express, sequelize, sqlite3, jsonwebtoken, multer for uploads, node-schedule, ws for websockets, plus @kubernetes/client-node and docker-secret.

State lives in a SQLite database under the mounted data directory, which is why the Docker examples mount /path/to/host/data to /app/data. There is no external database to run. The websocket dependency and the Socket.js and Sockets.js files at the top level suggest the client receives live updates rather than polling, though the README does not describe the socket protocol. Authentication is handled with jsonwebtoken, and the README points to a wiki page on authentication rather than documenting the flow inline. That is a pattern worth noting: several behaviours are documented only in the project wiki, which means the README alone is not a complete operating manual.

Installing Flame with Docker and adding your first app

Docker is the recommended path. The README gives a pull command and a run command, and the run command is the one that matters because it sets the port and the data volume. The PASSWORD environment variable is what protects the settings area, so change it before the container is reachable from anywhere but localhost.

docker pull pawelmalak/flame
docker run -p 5005:5005 -v /path/to/data:/app/data -e PASSWORD=change_me pawelmalak/flame

After that, the startpage answers on port 5005. For ARM hardware such as a Raspberry Pi, the README points at a separate tag, pawelmalak/flame:multiarch, and it also shows that a specific version can be pulled, for example pawelmalak/flame:2.0.0. Pinning a tag is the safer default given how far apart the releases are.

A docker-compose file is the tidier option, and the README provides one. Note the second volume: it is optional, but it is what enables automatic app discovery, and the secrets block is what lets you keep the password out of the compose file.

version: '3.6'
services:
  flame:
    image: pawelmalak/flame
    container_name: flame
    volumes:
      - /path/to/host/data:/app/data
      - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - 5005:5005
    environment:
      - PASSWORD=change_me
    restart: unless-stopped

With the container up, log in, open the settings area and use the built-in editor to create your first application. Nothing needs to be written to disk by hand. If you prefer to drive the list from your compose files instead, add labels to each service and enable the Docker integration, which the README places under Settings > Docker.

labels:
  - flame.type=application
  - flame.name=My container
  - flame.url=https://example.com
  - flame.icon=icon-name

Once the option is switched on, containers carrying those labels appear in Flame without further input. The README notes that the icon label is optional and defaults to "docker", and that multiple apps can share one label by separating values with a semicolon.

Docker socket access and the single-password model

The Docker integration is the feature most likely to bite you. To read container labels, Flame needs access to the Docker API, and the README's compose example achieves that by mounting /var/run/docker.sock into the container. That socket is effectively root on the host. Anyone who can reach Flame's settings, or exploit it, inherits that access. The README offers no mitigation beyond making the mount optional; it does not discuss socket proxies or read-only socket configurations.

The project does show awareness of the remote-host case. It documents editing ExecStart in /lib/systemd/system/docker.service to add -H tcp://0.0.0.0:${PORT}, restarting the daemon, and testing with curl against /version. Exposing the Docker API over plain TCP to all addresses is a larger exposure than the local socket, and the README presents it without a warning. Treat that section as a description of what is possible, not as a recommendation.

Authentication is a single shared password. The README describes an authentication system that protects settings, apps and bookmarks, and it supports passing the password through a Docker secret using PASSWORD_FILE, with the secret taking precedence if both variables are set. There is no mention of multiple users, roles, or integration with an external identity provider. For a household dashboard that is usually fine. For anything shared with people you do not fully trust, it is the wrong shape.

Where Flame stops being the right tool

Flame stores everything in SQLite inside the mounted data directory. The README's bookmark importer section says it plainly: back up db.sqlite before running the script. That instruction generalises. There is no documented export, no sync, and no replication. If the volume is lost, the dashboard is lost, and the README does not document rollback or restore procedures beyond that one warning.

The experimental HTML bookmark importer deserves its own caution. It requires python3 plus the Pillow and beautifulsoup4 packages, runs from the .dev directory, and the README lists incorrect generated icons among its known issues. It is a migration aid, not a supported import path.

There is also the release cadence. The last push to the repository was on 2026-06-25, and the most recent release, v2.4.0, is dated 2026-04-24. Before that, v2.3.1 landed in July 2023 and v2.3.0 in March 2022. Anyone planning to depend on Flame should read that history as it is: long quiet stretches punctuated by a release. If your requirement is a project with frequent, predictable updates, this is not it. If your requirement is a startpage that works and does not change under you, the same history reads differently.

Finally, Flame is not a status page. It links to services; it does not check whether they are up. If you want to know that a container died, you need something else.

Flame compared with a plain static dashboard file

The obvious alternative is a hand-written HTML or YAML dashboard served by whatever you already run, or a config-file-driven dashboard such as Homepage or Dashy, where the whole page is described in a file you edit and version in git. The difference in approach is where the source of truth lives. With a config-file dashboard, the file is the truth, and the page is a rendering of it. Changes go through your editor, your git history, and your deployment pipeline.

Flame inverts that. The database is the truth, and the GUI editor is how you change it. The README's central claim is that you can set up your application hub with no file editing necessary, and that is a genuine advantage for the case where several people in a household need to add a link and none of them want to touch a repository. It is a disadvantage when you want the dashboard to be reproducible from a file, reviewed in a pull request, or restored by redeploying rather than by restoring a volume.

The Docker label integration is the interesting middle ground. It lets the containers themselves carry the metadata, so the source of truth is your compose files, while Flame still provides the rendering and the manual editing for anything not in Docker. That is the configuration most people should start with, because it keeps the dashboard recoverable from the same files that define the services.

Licence, upgrade cost and what to check before you commit

Flame is MIT licensed. In practice that means you can run it, modify it and redistribute it, with the usual requirement to preserve the licence notice. The package.json declares "license": "ISC" while the repository carries LICENSE.md and the project metadata says MIT, so the two disagree; if the licence matters to your organisation, read LICENSE.md directly rather than trusting either field. This is not legal advice.

Upgrades are a container image swap, but the shape of the release history changes how you should do it. Because the gap between v2.3.1 and v2.4.0 spans years, a jump across that boundary is not a routine patch. The repository includes umzug, a migration framework for Sequelize, and a db/ directory, which indicates schema migrations are part of the application. The README does not document the upgrade procedure or whether migrations run automatically at startup. Pin an explicit image tag, copy the data volume before upgrading, and check the running container's logs for migration output on first boot after the change.

The weather widget has its own external dependency and cost consideration. It requires an API key from Weather API, plus latitude and longitude for your location, entered in the settings. The README states that the free plan allows for one million calls per month and that Flame makes fewer than three thousand calls per month, so the free tier is not a practical constraint. If you do not want a third-party service in the loop, leave the widget off; it is not required for anything else.

Editorial conclusion

Adopt Flame if you run a small set of self-hosted services and want to manage the hub from a browser instead of a YAML file, and if you are comfortable with a single SQLite database as the whole state of the tool. Do not adopt it if you need per-user dashboards, external identity providers, or a project with a steady release cadence, since the gap between v2.3.1 in 2023 and v2.4.0 in April 2026 shows how irregular releases are. Before committing, verify that the Docker socket mount is acceptable on your host, that you have a backup routine for the file at /app/data/db.sqlite, and that your reverse proxy terminates TLS in front of port 5005.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. pawelmalak/flame on GitHub
4. README
5. Releases