Your Browser’s New Tab, On Your Own Terms
Flame is an open-source, self-hosted start page built for homelab users who want a clean, fast dashboard without handing their data to a third-party service. It runs as a Docker container, stores everything locally, and gives you a customizable grid of app shortcuts alongside live weather and built-in search bar support – all accessible from any browser on your network.
What Flame Actually Does and Why It Matters
Most browser start pages are either locked to a cloud service or painfully limited. Flame sits in a different category: it is designed specifically for self-hosters who already run services like Nextcloud, Jellyfin, Gitea, or Home Assistant, and who want one place to reach all of them without memorizing ports. You pin your apps, organize them into categories, and load a URL that becomes your actual browser homepage.
The interface is minimal by design. There are no feeds, no ads, no telemetry pinging external servers. What you get is a search bar (pointed at whichever search engine you prefer), an optional weather widget pulling from OpenWeatherMap, and a grid of bookmarks and app tiles that you manage entirely through the Flame admin panel. The visual theme is customizable enough to feel personal without requiring CSS knowledge.
Flame also has a built-in Docker integration feature that can automatically detect running containers and surface them as app tiles – though this requires mounting the Docker socket, which carries its own security tradeoffs. For most users, manually adding apps through the UI is faster and safer. The admin panel is simple: you log in, click “Add Application,” fill in a name, URL, and optional icon, and the tile appears on the grid immediately.
One detail worth knowing before setup: Flame stores its configuration in a SQLite database inside its data directory. This makes backups straightforward – you copy one folder and everything is preserved, including your app list, categories, theme settings, and weather configuration. If you are already running a homelab with Docker, Flame fits cleanly into that workflow without adding complexity.
Setting Up Flame with Docker Compose
The cleanest way to run Flame is with Docker Compose. Start by creating a directory for the project and a docker-compose.yml file inside it. The official image is pawelmalak/flame, and the setup requires very little configuration. Below is a working Compose file you can copy directly:
Create the file at /opt/flame/docker-compose.yml with the following content:
- image: pawelmalak/flame:latest
- container_name: flame
- ports: “5005:5005”
- volumes: ./data:/app/data
- environment: PASSWORD=yourpassword
- restart: unless-stopped
The PASSWORD environment variable sets the admin panel password. Flame does not have user accounts or OAuth – it is a single-password setup, so pick something you would not mind rotating occasionally. Once the file is saved, run docker compose up -d from the same directory. Flame will pull the image and start within a few seconds. You can reach the interface at http://your-server-ip:5005 from any device on your local network.
After your first login, go to Settings and configure the basics: set your preferred search provider, enable or disable the weather widget (you will need a free OpenWeatherMap API key for weather to work), and choose a theme. Flame ships with a handful of built-in themes covering light, dark, and a few color variants. From there, go to the Apps section and start adding your services. Each entry takes a name, a URL, and an icon – Flame supports both self-hosted icons and auto-fetched favicons via a built-in icon picker that pulls from a hosted icon library.
For users running Flame behind a reverse proxy, the setup pairs naturally with Caddy as an automatic HTTPS reverse proxy, since Flame itself serves plain HTTP on port 5005 and benefits from TLS termination if you are exposing it beyond localhost. A typical Caddy config block for Flame is just four lines: a site block pointing to your subdomain, a reverse_proxy directive targeting the container’s port, and Caddy handles certificate renewal automatically. With a valid domain and Caddy in front, your Flame instance becomes accessible over HTTPS at something like home.yourdomain.com, which is far cleaner than bookmarking an IP and port.
Category management is the part of Flame that most users discover late but end up using the most. Rather than dumping 20 tiles into a single grid, you can create named groups – Media, Development, Infrastructure, Finance, and so on – and assign each app tile to one. The grid then organizes itself into labeled sections, which makes the page genuinely useful rather than just decorative. You can also control which categories appear on the main page versus staying hidden in the full app list, which helps keep the homepage clean while keeping everything reachable.
Keeping Flame Maintained and Accessible
Flame’s update process is the same as any Docker container: pull the new image and recreate the container. Running docker compose pull && docker compose up -d from the project directory handles it in one step, and because the data volume is mounted separately, your configuration survives the update without any manual export. The SQLite database stays on the host at ./data/flame.db, so dropping that file into a backup rotation is enough to protect everything.
The only persistent limitation worth flagging is that Flame has no mobile-specific view or PWA support built in. It is browser-based and technically usable on a phone, but the tile grid is designed for a desktop viewport. If your homelab access pattern is heavily mobile, you may find the layout less convenient than on a laptop or desktop. That said, for the core use case – a local-network start page you open every time you sit down at a machine – Flame does exactly what it promises, with no subscription, no external account, and no moving parts that can break because a company changed its pricing.
