Your health data in your own Postgres and Grafana

Yes, if you can run Docker. The demo profile in the same compose file starts the stack with 60 days of made-up data for two phones, under its own name and ports. The commands are under Run the stack. Without Docker, the screenshots on this page show the same dashboards.

No. Each release has a docker-compose.yml and an example .env, and the receiver, Postgres, Grafana and the MCP server are published images for amd64 and arm64. A clone is only for changing the receiver, the views or the dashboards themselves: a second compose file then builds the images from it.

No. There's no Life Dashboard server and no account: the phones send to your receiver, and the data stays in your Postgres. Grafana's usage reporting and update checks are switched off. Data only leaves when you connect something yourself, such as a cloud model over MCP, a script with the API token, or a reverse proxy you open to the internet.

Only if you let it. Start the optional MCP server with an MCP_TOKEN, and a model you connect gets six read-only tools for phones, days, nights, workouts, trends and screen time. It reads as dash_ro, so it can't write, delete or run SQL of its own. With a local model through Ollama, everything stays on your hardware; with a cloud model, Claude Desktop included, your questions and every tool result go to that provider. Health Connect data over MCP has the setup.

Yes, with a Helm chart for Helm 3 or 4. By default Postgres runs as a CloudNativePG cluster, with replicas if you want them and backups to object storage through the Barman Cloud plugin. Without CloudNativePG, the chart runs Postgres as one bundled pod or uses a Postgres you already run. The pods meet the restricted Pod Security Standard, and NetworkPolicies, an Ingress and Gateway API routes are optional. docs/kubernetes.md has the steps.

Put a reverse proxy with TLS in front of the receiver, forward only /webhook, and allow request bodies of 32 MB. The API shares the receiver's port, and /pair shows the signing secret: the receiver answers /pair only to your own network and never through a proxy, but a proxy that adds no forwarding header, or Docker Desktop's port forwarding, can make an outside request look local, so block it there or set PAIRING_PAGE=0. Keep Grafana and the MCP server on your own network or behind a VPN: anyone who can view a dashboard can read every health record. Before the first start, change GRAFANA_PASSWORD, GRAFANA_DB_PASSWORD and DASH_DB_PASSWORD in .env. Postgres publishes no port, so only the stack's own services reach it.

Yes, as a second home for the data, with two things to know. The Android app has one signing secret per tab (Health, Screen Time), the iPhone app one for all its webhooks. Pairing adds the receiver's URL and replaces that secret, and the dialog names the URLs that get signed with the new one, so pairing with the stack after Home Assistant gives Home Assistant payloads it refuses. Pair with Home Assistant, add the stack's webhook URL by hand, and set WEBHOOK_SECRET in the stack's .env to the same secret; or send one phone to each. A secret per destination is planned. And a payload counts as delivered once one destination takes it, so if the stack is down at that moment, it misses that payload.

Set LIFEDASH_VERSION in .env to the new release, then run docker compose pull && docker compose up -d. Set it to the major version alone, and every pull follows the releases that keep compatibility. Within a major version, the payloads, the database, the dash views, the read-only users, the settings and the ports stay the same, as docs/compatibility.md lists. An older install from a clone moves its data over once with a script that leaves the old volume untouched; the README has the steps.

With Docker Compose, one pg_dump line writes a dump, and one pg_restore line puts it into a fresh stack. Restart the receiver afterward so it rebuilds the views and the grants of the read-only users. On Kubernetes with CloudNativePG, backups go to object storage on a schedule, and a restore starts a new cluster from them.

Yes. They're built into the Grafana image, so Grafana won't save changes over them, and an upgrade brings their new versions along. Use Save as for a copy of your own, which an upgrade leaves alone. To change the originals, edit the JSON in a clone and build the images from it. Keep views of your own in the public schema, because the receiver rebuilds dash at every start.

Yes. Run the receiver and Postgres from the stack, and in your own Grafana add a PostgreSQL data source for the stack's database with the read-only user grafana_ro and your GRAFANA_DB_PASSWORD. Then import the six dashboard files from grafana/dashboards/life-dashboard/ and pick that data source. grafana_ro can read the records, the buckets and the dash views, and nothing else.

Series sent per time window are stored, but only the heart rate panels read them, so leave Data Resolution on Every record. Days follow the stack's one time zone, and a backfill doesn't remove records the phone no longer has. The API and the MCP server answer per day, night and workout, not with raw records. The known gaps list the rest.