Skip to main content
Qovery creates it as a Helm release on the environment’s own cluster, as a Blueprint service in one of your environments.
New to this? You don’t need to know Kubernetes or Helm. Qovery installs Grafana on your cluster with Helm and runs it for you: you fill in a form, or paste the prompt below into your coding agent. The values it publishes, listed under Outputs, reach your other services as environment variables. Qovery tells you when a newer version of the Blueprint is available. Check the requirements in the Reference section before you start, and try it first in a development environment.

Create it

  1. Open the environment, then New service › Blueprint.
  2. Find Grafana in the catalog and pick the major version.
  3. Fill in the variables. Required ones are marked; the others use their defaults.
  4. Create the service, and deploy it now or later.
You don’t add any file to your repository. Qovery creates the Blueprint from the Console or the API.

Variables and outputs

Generated from qbm.yml at HELM/grafana/13/1.1.1, the manifest the Console form is built from.
Outputs become environment variables that other services in the environment can use. By default Qovery also creates an alias for each output, prefixed with the Blueprint’s name; see Aliases Qovery creates for outputs for the naming rules and the cases where no alias is created.

Reference

From the Blueprint’s README. Deploys Grafana 13 with the community grafana-community/grafana Helm chart (13.2.5), already connected to the observability stack Qovery installs on the cluster: With kubernetes_dashboards=true (the default), a folder (dashboards_folder, default Kubernetes) is preloaded with the Kubernetes Views dashboards (global, namespaces, nodes, pods) and Node Exporter Full, plus a Loki logs dashboard when enable_loki_datasource=true. All of them read the metrics kube-prometheus-stack exposes, so they work on any Qovery cluster with metrics enabled.

Credentials

The admin login is admin_user (default admin) and the sensitive admin_password, both entered in the Qovery console when creating the service.
  • Changing admin_password and redeploying resets the admin password: an init container runs grafana cli admin reset-admin-password on every start, because Grafana otherwise reads the password only on its very first start.
  • admin_user is set once. Grafana creates the admin account on first start and never renames it; changing the variable later has no effect. Rename the user in Grafana (Administration → Users) instead.

Variables

Required

Optional

Outputs

Accessing Grafana

The Grafana UI is published on the URL Qovery generates for the service (Helm service → Overview → Links), over HTTPS. Log in with admin_user and admin_password. Set root_url to that URL, or to your custom domain, so links in alert notifications point to it. On a Qovery engine older than the one that added blueprint ports (QOV-2335), the service is created without a public URL. Reach it with a port-forward instead:

Notes

  • Turning things off removes them. A datasource switched off is deleted from Grafana (deleteDatasources), and a dashboard dropped from the form, or a renamed folder, has its downloaded file removed by the blueprint-maintenance init container, so Grafana stops provisioning it. A renamed folder leaves the old one behind, empty: Grafana never deletes folders. That container uses the plain grafana/grafana:13.2.2 image, pinned to the chart’s appVersion.
  • Volume settings are creation-time. Kubernetes forbids changing a bound volume’s class, so an update that changes storage_class fails with spec is immutable after creation, and Helm’s automatic rollback fails for the same reason. Grafana keeps running on the previous release; set storage_class back to its original value and redeploy. storage_size can only grow.
  • Data sources depend on the cluster. Thanos, Prometheus, Loki and Alertmanager exist only when metrics and logs are enabled on the Qovery cluster. Without them Grafana starts normally and the datasources report a connection error.
  • GKE and AKS host the metrics stack in the qovery namespace rather than prometheus; set metrics_url, prometheus_url and alertmanager_url accordingly. Loki lives in logging on every provider.
  • Dashboards and plugins are downloaded from grafana.com at each pod start, so the pod needs outbound HTTPS. On clusters without egress set kubernetes_dashboards=false and leave extra_dashboards and plugins unset.
  • deploymentStrategy: Recreate: the data volume is ReadWriteOnce, so a rolling update would leave the new pod waiting on a multi-attach error.
  • fullnameOverride: grafana gives a stable Service name. Deploy one Grafana blueprint per environment.
  • One replica, no replica variable: Grafana’s embedded SQLite database sits on a ReadWriteOnce volume, which one pod at a time can mount.
  • extra_dashboards entries are id:revision; the revision must exist on grafana.com (the dashboard page lists them). A dashboard that cannot be downloaded, for a bad revision or because grafana.com is unreachable, does not block Grafana: it is skipped and logged as invalid, the others load.
  • Sign-up is disabled and usage reporting to grafana.com is off.
  • The rendered values, admin password included, are stored in the Helm service’s values override, like every Helm blueprint’s inputs.
  • Chart pinned to 13.2.5 (Grafana 13.2.2). The grafana/grafana chart is deprecated upstream; this is its community successor, not Bitnami.