Flame: a self-hosted startpage with GUI editors and Docker label discovery
Flame is self-hosted startpage for your server. Easily manage your apps and bookmarks with built-in editors.
At a glance
- What is it?
- Flame is a TypeScript startpage for a home server, with built-in editors for apps and bookmarks and optional container and ingress auto-discovery. It is easy to run, but its authentication is a single shared password and the project ships one maintainer's database format.
- Who is it for?
- Adopt Flame if you want a startpage you configure from a browser, and you are comfortable with one shared password and a SQLite file you must back up before upgrades. Skip it if you need per-user accounts or an API-first dashboard.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 83 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Flame solves: a server hub you edit in the browser
A self-hosted server accumulates services: a dashboard here, a media server there, a few web apps behind different ports. The usual fix is a static HTML file or a YAML config that you edit over SSH every time a container moves. Flame takes the opposite position. Its README describes it as a self-hosted startpage whose built-in editors let you "setup your very own application hub in no time - no file editing necessary". Applications and bookmarks are created, updated and deleted through the GUI, and the data lives in a SQLite database inside the container's data directory rather than in a config file you hand-edit. The audience is a homelab operator who runs Docker or Kubernetes, wants a landing page reachable at a fixed port, and would rather click than commit. It is not aimed at teams that need role-based access or an audited configuration pipeline.
How the pieces fit: Express, SQLite and a React front end
The README's technology list is short and specific. The backend is Node.js with Express, using the Sequelize ORM over SQLite. The frontend is React with Redux, written in TypeScript. Deployment targets are Docker and Kubernetes. That stack explains the operating model: there is no external database to run, so the whole state is one SQLite file that the container writes to /app/data. It also explains the discovery features. Because the backend is a long-running Express process, it can call the Docker API or the Kubernetes Ingress API and translate container labels or ingress annotations into startpage entries. The README states that the "Use Docker API" option must be enabled in Settings > Docker before label discovery works, and the same settings area holds the Kubernetes Ingress API toggle. Search is handled locally: the default behaviour is to filter your own apps and bookmarks, and typing a prefix such as /g switches to a web search provider instead.
Running it: one docker run, or a compose file with a secret
The recommended path is Docker. The README gives `docker pull pawelmalak/flame`, with `pawelmalak/flame:multiarch` for ARM boards such as a Raspberry Pi and version tags like `pawelmalak/flame:2.0.0` for pinning. The single-container run is `docker run -p 5005:5005 -v /path/to/data:/app/data -e PASSWORD=change_me pawelmalak/flame`. The compose example adds two things worth copying: the volume mount `/path/to/host/data:/app/data`, and the optional `/var/run/docker.sock:/var/run/docker.sock` mount, which the README notes is "optional but required for Docker integration". Passwords can come from Docker secrets instead of a plain environment variable. The README states that any environment variable can be overridden by appending `_FILE`, so `PASSWORD_FILE=/run/secrets/password` reads the value from a file, and if both `PASSWORD` and `PASSWORD_FILE` are set, the secret takes precedence. For development, `npm run dev-init` runs once and `npm run dev` starts the backend and frontend servers. Building a multiarch image uses `docker buildx build --platform linux/arm/v7,linux/arm64,linux/amd64 -f .docker/Dockerfile.multiarch`, and the README warns that the build failed repeatedly under a 2GB memory limit.
Label discovery is the feature that separates Flame from a static page
Instead of adding each service by hand, you annotate the container. The README's example labels are `flame.type=application` ("app" also works), `flame.name`, `flame.url` and an optional `flame.icon`. Multiple apps can share one label set by separating values with semicolons, so `flame.name=First App;Second App` with matching URLs and icons produces two entries. Kubernetes uses annotations under the `flame.pawelmalak/` prefix with the same field names. The `flame.icon=custom` value is documented as the way to make an app editable inside Flame, which implies that discovered entries are otherwise managed by their labels. This design has a clear consequence: your container definitions become the source of truth, and anything you change in the GUI for a discovered app may be overwritten on the next scan. If you would rather keep the startpage independent of your orchestration layer, the label approach is the wrong fit and manual entries are the better choice.
Limitations: shared password, experimental importer, thin wiki
The authentication model is the largest constraint. The README lists an "authentication system to protect your settings, apps and bookmarks" and points to a wiki page, but the only credential shown anywhere in the material is a single `PASSWORD` value passed as an environment variable or secret. There is no mention of user accounts, roles or per-user views. Anyone who has the password can edit your apps and bookmarks. For a personal startpage on a home network that is reasonable; for anything shared with other people it is not. The HTML bookmark importer is labelled Experimental in the README, requires python3 plus the Pillow and beautifulsoup4 packages, and carries its own warning: "Backup your `db.sqlite` before running script!". Its known issues section admits that "generated icons are sometimes incorrect". Installation without Docker is not documented in the README at all; it is deferred to a wiki page, so the npm path is effectively unverified from the repository's main document. The weather widget needs a third-party API key from weatherapi.com and your latitude and longitude, which means coordinates leave your network. The README notes the free plan allows 1M calls per month and estimates Flame makes fewer than 3K calls per month, but the dependency on an external service remains.
Alternatives: Homepage and Dashy take different positions
Homepage (gethomepage/homepage) is the closest comparison and takes the opposite approach to configuration. Its service definitions are YAML files on disk with widget integrations for individual services, so the dashboard is version-controllable and reviewable in a pull request, but you edit files rather than clicking. Flame's GUI editors and its SQLite store are precisely what Homepage avoids. Dashy is another self-hosted dashboard that keeps its configuration in a YAML file, with a built-in config editor as an option, and supports multiple authentication backends including Keycloak and OIDC. If per-user login matters to you, Dashy's auth options are the more direct answer than Flame's single password. The trade-off is consistent across both alternatives: file-based configuration is easier to back up and diff, while Flame's database is easier to change from a browser but harder to review as a diff. None of these three is strictly better; the choice follows from whether you want your startpage in git or in a form.
Maintenance cost, licence and what to check before upgrading
Flame is MIT licensed, which permits commercial and private use and modification provided the copyright notice and permission notice are retained. That is the extent of what can be said here; if you redistribute it or bundle it into a product, read the licence text yourself rather than relying on this summary. The release history in the supplied material shows v2.4.0 in April 2026, then a gap back to v2.3.1 in July 2023 and v2.3.0 in March 2022. The repository is not archived and the last push is dated 2026-06-25, so activity has resumed, but the multi-year gap means the migration path across those versions is not documented in the README. Upgrades are therefore a data question rather than a code question: back up the host directory mounted at /app/data, which contains db.sqlite, before pulling a new image. The same file is what the experimental bookmark importer warns you to copy first. The README does not describe a migration command or a schema version, so if a release changes the database layout, restoring the backup is the documented fallback.
Editorial conclusion
Adopt Flame if you want a startpage you configure from a browser, and you are comfortable with one shared password and a SQLite file you must back up before upgrades. Skip it if you need per-user accounts or an API-first dashboard. Before deploying, verify that /app/data is a persistent volume, that PASSWORD is set, and that the weather widget is left unconfigured unless you want to send coordinates to weatherapi.com.
Community notes