A self-hosted startpage for homelabbers and founders running multiple services. No subscription, no SaaS, just Docker.

TL;DR

What it is: MIT-licensed self-hosted startpage — a browser home page that lists all your self-hosted apps and bookmarks with a built-in editor, search bar, and weather widget [1].
Who it’s for: Homelabbers and technical founders running 5–30 self-hosted services who want a single URL to launch everything, without managing a config file every time they add a service.
Cost savings: There is no SaaS equivalent to replace. The value is operational: without Flame, you’re either memorizing ports (192.168.1.100:8096 for Jellyfin, :9000 for Portainer) or maintaining a personal bookmarks folder that doesn’t know when a container is running. Flame replaces both — and the software is free [1].
Key strength: Docker label integration that automatically picks up new containers and adds them as app entries, no manual editing required [1].
Key weakness: Development has visibly slowed — 304 total commits, 17 releases, and the repository shows no recent major feature additions. The self-hosting category has moved fast; newer alternatives like Homarr and Homepage now offer more widgets and more active maintenance.

What is Flame

Flame is a self-hosted startpage for your server. You deploy it in Docker, point your browser at it, and get a clean home screen listing all your self-hosted applications and bookmarks. Click an entry to jump straight to that service. The description on GitHub is deliberately plain: “Flame is self-hosted startpage for your server. Its design is inspired (heavily) by SUI. Flame is very easy to setup and use. With built-in editors, it allows you to setup your very own application hub in no time — no file editing necessary.” [1]

That last phrase — “no file editing necessary” — is the product decision that sets Flame apart from its older competitors. Tools like Homer require you to edit a YAML file and restart the container every time you add a service. Flame gives you a browser-based GUI editor: you fill in a name, URL, and icon and click save. The startpage updates immediately [1].

The project was built by Paweł Malak and sits at 6,264 GitHub stars with 320 forks as of this writing [1]. It runs on Node.js with Express on the backend, React and TypeScript on the frontend, and SQLite for storage — a stack that’s intentionally lightweight and easy to run on a Raspberry Pi or a cheap VPS [1].

The target user is someone who has crossed the threshold from “one or two self-hosted apps” into “I have a dozen services and I can’t remember all the ports.” That moment — when your homelab stops fitting in a mental tab — is when Flame becomes useful.

Why people choose it

The GitHub star count and the Ubuntu installation guide [2] point to a consistent adoption pattern: Flame shows up when someone installs their third or fourth self-hosted service and realizes they need a dashboard. Three practical reasons surface repeatedly:

The GUI editor removes friction. Homer and its derivatives ask you to write YAML. For a non-technical founder who just managed to get Nextcloud running, opening a config file to add a bookmark is a second obstacle. Flame’s browser editor removes it entirely [1].

Docker integration is genuinely useful. If you label your containers correctly, Flame detects them automatically:

labels:
  - flame.type=application
  - flame.name=My container
  - flame.url=https://myapp.local

Add those three lines to any docker-compose service and Flame picks it up without any manual action [1]. For homelabbers running 15–30 containers, this saves real time.

It runs on the same hardware you already have. There’s no separate server to provision. If you’re running Nextcloud or Jellyfin, you already have a VPS or home server. Flame adds roughly 50MB of RAM overhead and runs alongside everything else on port 5005. The marginal cost is close to zero [1].

The honest counter-point: Flame’s traction predates a wave of better-funded alternatives. Homarr and the benphelps/homepage project both launched after Flame and have attracted more active development communities. If you search Reddit’s r/selfhosted today, Homepage gets more recommendations for new setups. Flame is the tool that was there first — which means it has the star count, the documentation, and the institutional knowledge of the early homelab community, but not necessarily the newest features.

Features

Based on the GitHub README [1]:

Core dashboard:

Create, update, and delete app and bookmark entries via browser GUI — no config file editing [1]
Pin favourite items to the homescreen for quick access [1]
15 built-in color themes plus a custom theme builder [1]
Custom CSS support for full visual control [1]
Authentication system to password-protect settings, apps, and bookmarks [1]

Search:

Integrated search bar with local filtering across your apps and bookmarks [1]
11 built-in web search providers (Google, DuckDuckGo, etc.) with custom provider support [1]
Prefix-based search routing: type /g what is docker to route directly to Google [1]

Integrations:

Docker integration: reads container labels and automatically adds detected apps [1]
Docker socket mount is optional but required for auto-discovery [1]
Kubernetes deployment support via Skaffold [1]

Widgets:

Weather widget with current temperature, cloud coverage, and animated status [1]
Requires a WeatherAPI key (free plan: 1M calls/month; Flame uses under 3K/month) [1]

Deployment:

Docker (recommended), Docker Compose, Kubernetes [1]
ARM architecture support (flame:multiarch tag) — runs on Raspberry Pi [1]
Docker Secrets support for password management [1]
SQLite storage — single file, easy to back up [1]

What it doesn’t have:

Service health checks or uptime monitoring (Uptime Kuma handles that separately)
Widget integrations for media servers, NAS stats, or calendar data — that’s Homarr or Homepage territory
Multi-user support or per-user dashboards
A REST API for external management

Pricing: self-hosted math

Flame has no SaaS offering and no paid tier. The software is MIT-licensed and free in every sense [1].

The cost math is simple:

Setup	Monthly cost
Flame on existing VPS	$0 software — already paying for the VPS
Flame on new $6 Hetzner VPS	$6/mo total (shared with other services)
Start.me (hosted dashboard alternative)	$3/mo for the paid plan
Notion as a personal dashboard	Free to $10/mo depending on team size

The honest framing: you’re probably not choosing between Flame and a paid service. You’re choosing between Flame and a browser bookmarks folder, or Flame and memorizing ports. On that comparison, the math is unambiguous.

If you’re already running a homelab server, deploying Flame is a docker run command and one port forward. The ongoing cost is a few megabytes of disk for SQLite and negligible CPU. There’s no vendor lock-in, no account to create, and no API key other than the optional WeatherAPI key for the weather widget [1].

Deployment reality check

Flame is one of the simpler Docker deployments in the self-hosted space. The README’s Docker Compose example is 20 lines including comments [1]. An unixcop tutorial covers getting it running on Ubuntu 22.04 in a single article [2], which is itself a signal about complexity — if setup required a multi-part guide, there wouldn’t be a “single post” tutorial.

What you actually need:

Any Linux host with Docker installed (VPS, home server, Raspberry Pi)
One open port (default: 5005)
A reverse proxy if you want HTTPS (Caddy or Traefik, both common in homelab setups)
Optional: Docker socket access for auto-discovery (/var/run/docker.sock)
Optional: WeatherAPI key for the weather widget

The docker-compose in 4 lines of meaning:

image: pawelmalak/flame
volumes:
  - /path/to/data:/app/data
  - /var/run/docker.sock:/var/run/docker.sock  # for auto-discovery
ports:
  - 5005:5005
environment:
  - PASSWORD=your_password

What can go sideways:

The Docker socket mount is optional but without it, auto-discovery doesn’t work. You’d need to add services manually, which reduces the main convenience feature [1].
Mounting /var/run/docker.sock gives the container read access to your Docker daemon. This is a known security trade-off — acceptable for a home network, something to evaluate carefully on an internet-exposed VPS.
ARM builds exist (flame:multiarch) but building the image locally for non-amd64 platforms can hit memory limits: the README explicitly warns that building multiarch failed multiple times at 2GB memory usage, suggesting you use the pre-built image rather than building from source [1].
There’s no built-in HTTPS — you’ll need a reverse proxy in front of Flame for anything beyond a local network. This is standard for self-hosted tools but is an extra setup step for newcomers.

Realistic time estimate for someone comfortable with Docker: 15–30 minutes to a running instance. For a first-time Docker user following a tutorial: 1–3 hours including reverse proxy setup.

Pros and cons

Pros

MIT license. Genuinely free to use, fork, and modify. No commercial restrictions, no “fair-code” ambiguity [1].
No config file editing. The browser GUI for adding apps and bookmarks is the feature that drove adoption. Editing YAML is a tax on non-developers; Flame removes it [1].
Docker auto-discovery. Label your containers once, and they appear in the dashboard automatically. This is the killer feature for active homelabs where new services get added regularly [1].
ARM support. Runs on Raspberry Pi. The homelab community runs heavily on ARM hardware, and Flame supports it via the multiarch tag [1].
Lightweight. SQLite backend, minimal RAM footprint, runs comfortably alongside 20+ other containers on modest hardware [1].
15 themes + custom CSS. Enough visual customization to match your preferences without needing to fork the project [1].
6,264 GitHub stars. Mature community, extensive documentation, and years of forum posts covering common setup issues [1].

Cons

Development pace has slowed. The repository shows 304 total commits and 17 releases — both numbers that suggest a project in maintenance mode rather than active feature development. The issues tab on GitHub reflects this: many feature requests and bug reports sit unanswered. If you need a feature Flame doesn’t have, you’re writing it yourself or switching tools.
No service health monitoring. Flame shows your apps; it doesn’t tell you whether they’re up. You’ll need a separate tool (Uptime Kuma, Healthchecks.io) if uptime visibility matters.
No widget ecosystem. Homarr and Homepage both offer integrations that pull live data — Sonarr queue depth, NAS disk usage, calendar events, media server stats. Flame has weather and nothing else. If you want a data-rich dashboard, Flame isn’t it.
Single-user by design. No multi-user support, no per-user views, no RBAC. Fine for a personal homelab; doesn’t scale to shared infrastructure or team setups.
Docker socket exposure. Auto-discovery requires mounting the Docker socket, which is a security consideration worth understanding before deploying on internet-facing infrastructure [1].
No REST API. You can’t programmatically add apps from a CI/CD pipeline or deployment script. Everything goes through the UI or the container labels.

Who should use this / who shouldn’t

Use Flame if:

You’re running 5–20 self-hosted services and you want a single home page to launch them from, with no YAML editing required.
You’re on a Raspberry Pi or low-resource VPS and need something genuinely lightweight.
You value a stable, well-documented tool over one with more features but faster-moving code.
You want Docker auto-discovery and don’t need service health widgets or live data integrations.

Consider Homarr or Homepage instead if:

You want an actively maintained project with regular updates and new integrations.
You want widgets that pull live data from Sonarr, Radarr, Jellyfin, Plex, Pi-hole, or similar services.
You’re setting up a new homelab from scratch in 2025 and want the tool with the most momentum in r/selfhosted right now.

Consider Homer if:

You prefer config-file-driven setup (YAML) and want something even more minimal.
You’re comfortable editing files and don’t need a GUI editor.
You want the most static, dependency-light option possible.

Skip all startpages if:

You have fewer than 5 services — browser bookmarks are genuinely sufficient.
You want service monitoring, not just a launcher — that’s Uptime Kuma’s job, not a startpage’s.

Alternatives worth considering

Homepage (benphelps/homepage) — The current momentum leader in r/selfhosted. Highly configurable YAML-based dashboard with a large widget library covering most popular self-hosted services. More complex setup than Flame, but dramatically more features and active development.
Homarr — Browser-based editor like Flame but with a tile/widget system and integrations for Sonarr, Radarr, Jellyfin, etc. More feature-rich, more moving parts, heavier resource footprint.
Homer — The predecessor Flame was inspired to improve on. YAML-only, zero JavaScript framework, extremely lightweight. Use this if you want maximum simplicity and don’t mind editing config files.
Organizr — More complex multi-tab dashboard with user authentication and SSO-style integration for services like Plex. Better for shared homelabs, overkill for personal use.
Dasherr — Minimal, fast, similar feature set to Flame, also YAML-based.

For a non-technical founder running a personal homelab and deploying 10–15 services, the realistic choice is Flame vs Homarr. Pick Flame if setup simplicity and stability matter more than features. Pick Homarr if you want service integrations and are willing to accept a more complex configuration.

Bottom line

Flame solved a real problem at the right time: it gave the self-hosting community a GUI-editable, Docker-aware startpage when the main alternative was editing YAML. That’s why it has 6,264 stars. The Docker auto-discovery via container labels is still one of the cleaner UX decisions in the space — label your container, it appears in your dashboard, no other action required.

The honest caveat in 2025 is that Flame’s development has plateaued while the category around it has accelerated. If you’re starting fresh, Homepage or Homarr offer more active ecosystems. But if you want a stable, lightweight, MIT-licensed tool that does exactly what it says — a self-hosted startpage with a browser editor and Docker integration — Flame delivers that without drama. Deploy it in 20 minutes, forget about it, and focus on the services it’s linking to.

If the 20 minutes is a blocker, upready.dev deploys this kind of self-hosted infrastructure for clients as a one-time engagement.

Sources

GitHub — pawelmalak/flame — “Flame is self-hosted startpage for your server. Easily manage your apps and bookmarks with built-in editors.” https://github.com/pawelmalak/flame
LinuxCompatible / Unixcop — “Install Flame on Ubuntu 22.04 - Your self-hosted startpage” https://www.linuxcompatible.org/story/install-flame-on-ubuntu-2204-your-selfhosted-startpage/