Grafana: The Self-Hosted Observability Layer That Turns Your Metrics Into Answers

"Your monitoring data is a floor plan of your infrastructure. The question isn't whether you need it — it's who else gets a copy."

Every metric your stack emits tells a story: how much traffic you serve, when your disk fills, which endpoint is slow, who logged in at 3 a.m. Ship that to a SaaS observability vendor and you've handed a stranger an unusually detailed map of your operations — and a bill that scales with your success. Grafana (GitHub: grafana/grafana) is the open-source answer. As of September 2026 it carries roughly 76,000 stars, is licensed AGPL-3.0 for the core, ships as v13.2.0, and connects to 150+ data sources through one query and dashboard interface. It doesn't collect anything itself. It is the layer where your telemetry becomes legible — and when you self-host it, that layer runs on your hardware. This is the honest breakdown: what Grafana actually does (and what it stubbornly won't), a real self-host walkthrough, the provisioning workflow that separates serious deployments from hobby ones, what it costs, and the licensing caveat that "Grafana is free" glosses over.

1. What Grafana Is (and Isn't)

The single most common misconception: Grafana is not a monitoring system. It doesn't scrape targets, store time series, or collect logs. It is a query and visualization layer that sits on top of systems that do those things. That distinction matters enormously for planning a self-hosted stack. Installing Grafana alone gives you a beautiful, empty application. To see anything, you also need:

• A metrics store — typically Prometheus or VictoriaMetrics, scraping your services.
• A log store — Loki, or Elasticsearch/OpenSearch.
• A trace store — Tempo or Jaeger, if you want distributed tracing.
• Node/host metrics — Prometheus node_exporter, or an agent like Grafana Alloy.

Grafana's job is to speak all of those query languages — PromQL, LogQL, SQL, and dozens more — through a uniform interface, and to let you compose panels from them side by side. This design is why it won. It never asked you to replace your existing collectors; it asked to be the shared front-end for whatever you already had. And because that front-end runs on your server, the queries you write, the dashboards you build, and the retention you configure are yours alone.

2. The Query Layer: One Interface, Many Backends

The core mechanic is the data source. You register a backend once — a Prometheus URL, a Postgres connection string, a Loki endpoint, a CloudWatch credential — and from that moment every panel editor in Grafana can query it. What makes this more powerful than it sounds is mixed data sources: a single dashboard can overlay a Prometheus CPU graph with a Postgres business-metric table and a Loki error-rate panel, all time-aligned. Correlating "CPU spiked" with "checkout errors jumped" with "revenue dipped" stops being three browser tabs and becomes one screen. Then there's templating. Dashboard variables let you build one dashboard parameterized by $host, $namespace, or $environment, with a dropdown at the top. Instead of forty near-identical dashboards that drift apart, you maintain one. This is the difference between a dashboard collection you maintain and one that quietly rots.

3. Why the Data Source Model Matters for Sovereignty

Here's the angle most Grafana reviews skip. When you self-host Grafana, the data source credentials live in your database, on your disk. The queries execute from your server. Nothing about your infrastructure topology is transmitted to Grafana Labs. Compare that with the SaaS path. A managed observability platform necessarily knows your hostnames, your service names, your cardinality, your retention, your alert rules, and your team's access patterns. Even with perfect vendor ethics, that's a materially different risk surface — and for anyone under data-residency or regulatory constraints, it may be disqualifying outright. Self-hosted Grafana also removes the pricing model that punishes success. Vendor observability bills scale with ingest volume and host count; the classic horror story is a metrics cardinality accident producing a five-figure invoice. Your own box has a fixed monthly cost regardless of how many series you throw at it. The trade-off is real, though: you now own the availability of your monitoring. If the Grafana host dies during an incident, you're blind. That's an argument for treating your observability stack as production infrastructure, not a side container on the same box it monitors.

4. Self-Hosting Grafana: The Real Walkthrough

The minimal deployment is genuinely simple: ``bash docker run -d --name grafana -p 3000:3000 \ -v grafana-storage:/var/lib/grafana \ -e GF_SECURITY_ADMIN_PASSWORD='change-me-now' \ grafana/grafana-oss:13.2.0 ` Note the -oss tag specifically — the default grafana/grafana image includes Enterprise code paths under a different license. For a clean AGPL-3.0 deployment, pull -oss. For anything you intend to keep, use Compose with a real database: `yaml services: grafana: image: grafana/grafana-oss:13.2.0 container_name: grafana restart: unless-stopped user: "472" volumes: - ./grafana-data:/var/lib/grafana - ./provisioning:/etc/grafana/provisioning environment: GF_DATABASE_TYPE: postgres GF_DATABASE_HOST: postgres:5432 GF_DATABASE_NAME: grafana GF_DATABASE_USER: grafana GF_DATABASE_PASSWORD__FILE: /run/secrets/grafana_db_password GF_SERVER_ROOT_URL: https://grafana.example.com GF_SERVER_DOMAIN: grafana.example.com GF_USERS_ALLOW_SIGN_UP: "false" GF_AUTH_ANONYMOUS_ENABLED: "false" GF_SECURITY_COOKIE_SECURE: "true" ports: - "3000:3000" depends_on: - postgres postgres: image: postgres:17-alpine volumes: - ./pgdata:/var/lib/postgresql/data environment: POSTGRES_DB: grafana POSTGRES_USER: grafana POSTGRES_PASSWORD__FILE: /run/secrets/grafana_db_password ` The details that bite people:

• user: "472" — the container's non-root UID. Skip it and volume permissions break on first write.
• Default storage is SQLite. Fine for evaluation, a genuine problem in production: it doesn't handle concurrent writes well and complicates backups. Move to Postgres early.
• GF_USERS_ALLOW_SIGN_UP: "false" — the default is open registration in some configurations. Turn it off before you expose anything.
• GF_SERVER_ROOT_URL — wrong value here produces broken links in alert notifications, which is a confusing failure to debug at 2 a.m.
• Secrets via __FILE — Grafana supports reading any config value from a file, which lets you use Docker secrets instead of baking passwords into environment variables.

Put it behind TLS with Traefik or Caddy rather than exposing port 3000. And don't put Grafana on the same host it's monitoring — when that host goes down, you lose the tool you need to find out why.

5. Dashboards That Don't Rot: Provisioning as Code

Clicking together dashboards in the UI is delightful for about a week. Then someone edits a panel, nobody knows which version is canonical, and there's no undo. Provisioning fixes this. Drop YAML files into /etc/grafana/provisioning/datasources/ and /etc/grafana/provisioning/dashboards/, and Grafana loads them at startup: `yaml apiVersion: 1 datasources: - name: Prometheus type: prometheus access: proxy url: http://prometheus:9090 isDefault: true editable: false ` With dashboards stored as JSON in a Git repository and mounted into the container, your entire observability configuration becomes version-controlled, reviewable, and reproducible. Rebuild the host from scratch and every dashboard returns exactly as it was. The practical rule: use the UI to explore, use JSON to keep. Whatever you build interactively, export it and commit it. Otherwise the next container rebuild wipes institutional knowledge you spent months accumulating.

6. Alerting: Where Grafana Stops Being a Pretty Graph

Dashboards are retrospective — someone has to be looking. Unified Alerting is what makes Grafana operationally load-bearing. The model: define an alert rule (a query plus a threshold or expression), set a pending period so transient blips don't page anyone, attach labels, and route through notification policies to contact points — Slack, email, webhooks, PagerDuty, Telegram, and dozens more. The honest assessment: it's competent and much-improved over the legacy alerting engine, but it is not a full incident-management platform. Expect to invest time in tuning. The failure mode is alert fatigue — rules that fire too often get muted, and then the one that mattered is lost in the noise. Start with a small number of high-signal alerts and add slowly, rather than enabling every community dashboard's bundled alert set. Also worth knowing: if you want Prometheus's own rule engine doing evaluation, you can keep alerting in Prometheus and use Grafana purely for visualization and notification. Many teams split it that way, and it's a legitimate choice — Grafana alerting adds a dependency between your evaluation path and your UI layer.

7. The Honest Limitations

Things the marketing page won't tell you: "Free" means AGPL core, not the whole product. Grafana Enterprise plugins, advanced RBAC, reporting, and some data source connectors are proprietary. Most self-hosters never need them, but if you assume every feature is open, you'll be surprised. It's a UI, not a pipeline. You still have to run Prometheus, Loki, exporters, and agents. Grafana is the smallest resource consumer in that list and the least of your operational burden. Default SQLite is not production-grade. Already covered, worth repeating — it's the most common self-hosting mistake. Dashboard sprawl is cultural, not technical. Grafana makes creating dashboards trivially easy and provides no opinion about which matter. Six months in, teams routinely have 200 dashboards and use four. Plugin lifecycle is real maintenance. Plugins have their own release cadences, and major Grafana upgrades occasionally break community plugins. Pin versions and test upgrades. Upgrades need attention. Skipping many versions at once has historically caused breaking config changes. Upgrade incrementally and read release notes. It's a big project with a big backlog. Several thousand open issues is normal for software at this scale, but it means your specific bug may wait.

8. What It Actually Costs

Line items for a realistic home or small-team deployment: | Item | Cost | Notes | |---|---|---| | Grafana OSS license | ¥0 / $0 | AGPL-3.0, unlimited users and dashboards | | VPS (2 vCPU / 4 GB) | ~$12–20/month | Grafana itself needs ~1 GB; the database and data sources need the rest | | Storage | ~$2–5/month | Depends entirely on retention and cardinality | | Domain + TLS | ~$1/month or free | Let's Encrypt | | Backups | ~$1–3/month | Object storage for dashboard JSON + DB dump | | Total | ~$16–29/month | Fixed, regardless of user count | The comparison that matters is against per-host or per-GB SaaS pricing. A small team paying $15–25 per host per month for a dozen hosts is looking at $200+/month. Self-hosting doesn't eliminate cost — you're paying in maintenance attention instead of dollars — but it converts a variable cost that scales with your growth into a fixed one that doesn't. The hidden cost is your time. Budget a few hours a month for upgrades, backup verification, and alert tuning. If that time is worth more than the SaaS bill, the SaaS bill may be the better deal — and that's a legitimate conclusion, not a failure.

9. Where Your Data Lives

Self-hosted Grafana has a clean data-sovereignty story, and it's worth stating precisely:

• Dashboards, users, alert rules → your Postgres or SQLite database, on your disk.
• Data source credentials → encrypted at rest in that same database, in your control.
• Query results → fetched at panel render time from your backends, never relayed through a third party.
• Metrics and logs themselves → wherever your Prometheus/Loki live. Also yours.

What does leave your network, if you let it:

• Usage telemetry — Grafana reports anonymous usage statistics by default. Disable with GF_ANALYTICS_REPORTING_ENABLED=false and GF_ANALYTICS_CHECK_FOR_UPDATES=false if you want zero outbound.
• Plugin downloads — fetched from Grafana's catalog at install time.
• Notifications — obviously, alert payloads go to whatever contact points you configure. Be mindful of what data ends up in a Slack message.

Turn off telemetry, pin your plugins, and you have a monitoring stack that is genuinely invisible from the outside.

10. Grafana vs Uptime Kuma vs Netdata

Three tools that get confused with each other, doing genuinely different jobs: | | Uptime Kuma | Netdata | Grafana | |---|---|---|---| | Question it answers | "Is it up?" | "What is this machine doing right now?" | "What does all our telemetry mean together?" | | Model | Black-box probing | Per-node agent + built-in UI | Query layer over any backend | | Setup | Minutes | Minutes | Hours (plus a data source) | | Resource use | Tiny | Light per node | Light itself; backends are heavy | | Best at | Status pages, reachability | Instant per-host troubleshooting | Correlation and long-term trends | They compose rather than compete. Uptime Kuma tells you the site is down, Netdata tells you the box is thrashing, Grafana tells you which of your forty services degraded first and what correlated with it. A serious homelab often runs all three.

11. Who Should Not Self-Host Grafana

Be honest with yourself here:

• You have one service to monitor. Grafana plus Prometheus plus exporters is a lot of machinery to answer "is my blog up?" Uptime Kuma does that in ten minutes.
• You won't maintain it. An unmaintained monitoring stack is worse than none — it fails silently and you discover the gap during an incident.
• You need enterprise features. If SAML-based fine-grained RBAC, audit export, or vendor SLAs are contractual requirements, the proprietary tiers exist for a reason.
• Your time is extremely expensive. If an hour of your week costs more than the SaaS bill, buy the SaaS bill.

12. Getting Started in an Afternoon

A realistic first-day path that doesn't over-reach: 1. Deploy Grafana OSS via Compose with Postgres, behind TLS. 2. Add one data source — Prometheus if you have it, otherwise Postgres or even a CSV plugin. 3. Import one community dashboard matching that source. Don't build from scratch yet. 4. Add node_exporter to one host and import its standard dashboard. 5. Create one alert rule: host down for more than five minutes. Route it to one channel. 6. Export every dashboard you touched to JSON and commit it to Git. Resist the urge to build forty dashboards on day one. The tool rewards patience; the value comes from a small number of dashboards you actually look at.

13. Backups: What Actually Needs Saving

A Grafana deployment has three distinct things worth protecting, and people usually remember only one. The Grafana database — every dashboard, user, folder, alert rule, data source definition, and API key. This is the irreplaceable part. If you're on Postgres, a nightly pg_dump is sufficient. If you're still on SQLite, copy the grafana.db` file — but only when the service is stopped or you're using SQLite's backup API, or you risk capturing a torn file. The provisioning directory — your YAML and JSON files. Ideally this is already in Git, in which case it's backed up by definition. If you've been building dashboards in the UI and exporting them ad hoc, they are not in Git, and a container rebuild will take them. The backend data — your Prometheus TSDB, your Loki chunks, your long-term retention. This is the one people forget because it's large. Decide deliberately how much history you actually need; ninety days of metrics is plenty for most teams and dramatically cheaper than "forever." The backup that matters is the one you've restored. Once a quarter, spin up a fresh container, restore the dump, and confirm a few dashboards render. An untested backup is a hypothesis.

14. The Plugin Ecosystem, and Where It Bites

Grafana's plugin catalog is one of its strengths and one of its maintenance burdens. There are official plugins for major data sources and a long tail of community plugins for everything from internal APIs to Raspberry Pi sensors. The failure mode is version drift. Plugins have independent release cycles, and major Grafana upgrades have historically broken community plugins that used deprecated APIs. The mitigation is boring but effective:

• Pin plugin versions explicitly rather than installing latest.
• Test upgrades in a staging instance before touching production, even if staging is just a second container on your laptop.
• Read the breaking-changes section of release notes before every major version bump.
• Prefer official plugins for anything load-bearing. A community plugin that visualizes your weather station failing is an annoyance; one that renders your business metrics failing during a board meeting is not.

Also worth knowing: installing a plugin requires a container restart, and some plugins need additional libraries in the image. If you're building a custom image, document which plugins you added and why — six months later you will not remember.

15. The Verdict

Grafana is the rare piece of infrastructure that is simultaneously industry-standard and genuinely self-hostable. It doesn't collect your data, it doesn't charge per host, and it doesn't lock you into a storage format — it queries whatever you point it at. The sovereignty argument is unusually clean: run it on your hardware and your operational telemetry never becomes someone else's asset. The cost argument is equally clean: fixed infrastructure cost instead of a bill that grows when you succeed. The caveats are real and manageable. It's a visualization layer that needs a data pipeline behind it, the license is AGPL core with proprietary extensions, and it demands ongoing maintenance. None of those are dealbreakers — they're the normal price of owning infrastructure. If you already run any self-hosted service, Grafana is the piece that turns scattered logs and metrics into something you can reason about. And unlike the SaaS alternative, the reasoning happens on your machine.

Related

• Uptime Kuma: The Self-Hosted Status Page and Monitor That Kills Your SaaS Subscription — the simpler sibling: reachability first, Grafana later.
• Traefik: The Reverse Proxy That Configures Itself While You Sleep — how to put Grafana behind TLS without exposing port 3000.
• Headscale: The Open-Source Tailscale Control Server That Puts Your Mesh VPN Back in Your Hands — reach your dashboards from anywhere without opening a port.