2026.09.13

Grafana Operator: Manage Grafana with Kubernetes resources

Grafana Operator brings Grafana instances, dashboards, and data sources into declarative Kubernetes and GitOps workflows. Check versions, permissions, storage, and external-instance requirements before adopting it.

What it is for

Grafana Operator is a Kubernetes Operator for installing and managing Grafana instances, dashboards, and data sources through custom resources. It is designed for Kubernetes and OpenShift environments, and it can also manage Grafana instances outside the cluster. Its role is not to replace Grafana, but to place Grafana configuration and resource reconciliation inside Kubernetes’ declarative management model.

Who it suits

The project is aimed at teams already operating Kubernetes or OpenShift that want monitoring configuration stored and delivered as code. Platform teams can use it to manage one or many Grafana instances. Infrastructure-as-code teams can represent instances, dashboards, and data sources as custom resources, while ArgoCD or Flux CD users can include them in GitOps workflows. For a single standalone Grafana deployment, or for teams without Kubernetes control-plane and CRD operational experience, the added abstraction may not be worthwhile.

Known capabilities

The README demonstrates declaring a Grafana resource and a GrafanaDashboard resource to create an instance and dashboard. The official documentation also covers external Grafana instances, persistence, administrator credentials, single sign-on, ingress, plugins, folders, dashboard sources, data sources, alerting, notification policies, and service accounts. Exact fields and behavior should be checked against the API documentation for the selected version.

The v5.25.0 release specifically announces public dashboard support, a scale subresource for Grafana instances, and the ability to set default values for dashboard template variables. The same release notes state that support for Kubernetes 1.33 and Grafana 10 was deprecated. This is an adoption checkpoint for that release, not a compatibility statement for every historical version.

Limits and deployment considerations

Before adoption, verify the target Kubernetes or OpenShift version, Grafana version, Operator version, and CRD version together. The supplied sources do not provide a universal minimum hardware profile, performance figures, or a complete compatibility matrix, so resource requirements and scale limits cannot be inferred.

Deployment also involves more than installing the Operator. Teams need to choose namespace scope, decide whether Grafana requires persistence, manage administrator credentials through Secrets, and define access for data sources, authentication, and external Grafana instances. Public dashboards and GitOps synchronization require clear ownership of who may publish or change content; the supplied sources do not support a broad security guarantee.

For upgrades, follow the official release instructions and check both the Operator deployment and CRDs. Helm, Kustomize, and OpenShift OLM are among the documented installation paths, and their upgrade procedures differ. GitHub metadata identifies the project as Apache License 2.0 and not archived, but organizations should still review dependencies, change approval, and rollback procedures for their environment.

Sources

Sources checked: 2026-09-13