Grafana

Last reviewed Aug 23, 2026 · 646 words

Grafana turns the metrics you're already collecting into the dashboard wall every homelab secretly wants — but it stores nothing itself. It is a window, not a database: pair it with a data source like Prometheus (or InfluxDB, Loki, even PostgreSQL) and it becomes the single pane over all of them. Understanding that division of labour up front prevents the classic false start of installing Grafana first and wondering where the graphs are.

Two first-start gotchas, then it behaves

services:
  grafana:
    image: grafana/grafana-oss:latest
    user: "472"
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=change-me-now
    volumes:
      - ./grafana-data:/var/lib/grafana
    restart: unless-stopped

Gotcha one: the default login is admin/admin, and an internet-reachable Grafana with default credentials is a genuinely common breach story — set GF_SECURITY_ADMIN_PASSWORD before first start, not after. Gotcha two: the container runs as UID 472, so a fresh bind-mounted data directory owned by root fails with a permissions error on boot; chown -R 472:472 ./grafana-data (or the user: line above plus matching ownership) fixes the only install problem most people ever hit. Everything — dashboards you build, users, settings — lives in that volume's grafana.db, which makes backup a one-file affair.

Don't build dashboards from scratch — import them

Grafana's community dashboard library is the feature that makes the first evening magical: every dashboard has a numeric ID, and Dashboards → Import → ID pulls it in wired to your data source. Node Exporter Full (ID 1860) is the canonical first import — one dashboard and suddenly CPU, memory, disk, network, and temperatures for every machine look professionally observable. Import two or three for the stack you run, then learn panel editing by tweaking them rather than starting from white canvas. The full pipeline — exporters on each box, Prometheus scraping, Grafana on top — is assembled step-by-step in homelab monitoring that works.

Provision as code once it matters

Clicking together dashboards is fine until the rebuild, at which point Grafana's provisioning directory earns its keep: YAML files that declare data sources and dashboard folders, mounted into /etc/grafana/provisioning/, recreate the whole setup from git on a fresh container. The pragmatic middle path for a homelab: provision data sources as code (they're three lines each and never change) and keep dashboards in the database with grafana.db backed up — full dashboards-as-JSON-in-git discipline is worth it only when several people edit or several instances must match. Either way you're one docker compose up from recovered, which is the docker-compose pattern working as intended.

Alerting: use it small, or use something simpler

Grafana's unified alerting can evaluate any query and route notifications anywhere — and the catalogue's "alerting can be complex" warning is earned, because contact points, notification policies, and evaluation groups are real machinery with a real learning curve. The honest homelab guidance: if what you want is "tell me when a service is down", Uptime Kuma does that with none of the ceremony. Reserve Grafana alerts for the things only metrics can see — disk 90% full, backup job silent for 25 hours, UPS on battery — keep them under a dozen, and route them to one channel you actually read. An alert page nobody trusts is worse than no alerts.

What I'd do

The compose file above with the password set and the volume chowned, Prometheus plus node exporters as the data source layer, dashboard 1860 imported on night one, data sources provisioned as YAML, grafana.db in the nightly backup, and exactly the handful of metric alerts Kuma can't express. Resist the tinkering gravity well: the dashboard is done when it answers "is everything fine?" at a glance, and every panel after that is decoration you'll maintain forever.