Bottom Line: Flame Is Easy to Containerize, but the 2023 BigBearCasaOS Post Is Historical
Flame is a self-hosted start page for bookmarks and application shortcuts. The old post points to a community App Store package, but the upstream project already provides Docker and Compose examples, so a fresh deployment should be checked against upstream rather than copied from a 2023 catalog definition.
Minimum Useful Flame Container
services:
flame:
image: pawelmalak/flame
container_name: flame
ports:
- "5005:5005"
volumes:
- /path/to/flame/data:/app/data
environment:
- PASSWORD=replace_me
restart: unless-stoppedThe Flame repository documents this layout and its persistent /app/data path.
Docker Integration Requires More Privilege Than a Simple Dashboard
Flame can read Docker labels and auto-add applications, but that requires access to the Docker API/socket. Mounting /var/run/docker.sock gives the container a powerful control path into Docker, so only enable that feature if you need it and understand the risk. Docker's security guidance explains why daemon access is sensitive.
On Current ZimaOS, Compose Is a Cleaner Baseline Than an Old CasaOS Store Package
The current ZimaOS app model accepts standard Compose plus optional store metadata. Use the Portainer hardware guide if you prefer a GUI for custom containers, and the ZimaOS App Store directory before adding another start page.
Keep the Flame Database Persistent
Bookmarks, app links and configuration live under /app/data. Back that path up before updates or container recreation. Do not treat the container image as the data store.
Consider Project Status Before Standardizing on Flame
The upstream project still has a published v2.4.0 release, but activity is much lighter than newer dashboard projects. If you are starting a long-lived deployment, compare maintenance activity and export options before building your whole home-server navigation around one dashboard.
The ZimaOS App Store hardware guide helps keep that decision tied to the current ZimaOS ecosystem.
