Grafana Helm Chart per Customer: A Multi-Tenant Deployment Blueprint
A Grafana Kubernetes deployment can be much more than an internal dashboard. SaaS vendors and managed-service teams often need a branded observability portal for every customer, with different datasources, credentials, plugins, dashboards, domains, and maintenance windows. A dedicated Grafana release per tenant creates those boundaries; OpenTenant automates their lifecycle around the existing Helm chart.
What the Grafana Helm chart handles
Grafana's Helm deployment guide covers installation into Kubernetes, namespace selection, values-based configuration, access, persistence, plugins, and private certificate authorities. Grafana recommends using a separate namespace rather than the default namespace to reduce conflicts and improve resource organization.
The chart is the right unit for expressing one Grafana installation. It does not maintain a customer registry or decide which release, domain, datasource Secret, dashboard bundle, and upgrade policy belong to each customer.
The use case: customer-specific observability portals
A release-per-customer model is useful when Grafana is part of the product experience rather than a shared internal tool. Each customer receives an environment with its own:
- hostname, TLS, and white-label settings;
- datasource endpoints and credentials;
- dashboard provisioning configuration;
- plugins and private CA trust;
- persistence and backup policy;
- compute limits and availability settings;
- chart version and maintenance window.
This boundary makes it easier to answer operational questions. Which customers use a particular plugin? Which release still trusts an old CA? Which datasource credential needs rotation? Which tenants are ready for the next Grafana version? Those answers can come from tenant declarations and release state instead of an inventory spreadsheet.
Reference architecture
customer observability profile
→ validate domain, datasource, and plugin policy
→ resolve tenant-scoped credentials
→ render Grafana values for one release
→ install into the tenant namespace
→ verify persistence, datasource health, and public route
→ promote or roll back independently
OpenTenant references the upstream chart and compiles only the per-tenant differences. Shared dashboard bundles can remain versioned templates; tenant-specific datasource URLs, secrets, branding, and resource settings remain overlays.
Persistence and configuration are part of the boundary
Grafana's documentation notes that persistent storage is disabled by default in the documented Helm flow and recommends enabling it when data must survive restarts or failures. For a customer-facing service, decide what is persisted in Grafana, what is provisioned from Git, and what can be rebuilt.
A strongly declarative model keeps dashboards, folders, alerting configuration, and datasource definitions in versioned sources where practical. Sensitive datasource credentials should be supplied through Secret references, not committed into values files. If a tenant uses a private certificate authority, its trust material should be scoped and reviewed with the same care as credentials.
Illustrative tenant declaration
tenant: acme
userspace:
namespace: tenant-acme-observability
domain: metrics.acme.example
deployment:
engine: helm
template: grafana
release: grafana-acme
config:
dashboardBundle: customer-portal-v4
persistence: enabled
secretScope: tenants/acme/grafana
The field names are illustrative. The design principle is stable: chart version, tenant overlay, secret ownership, hostname, and release status are represented separately.
Upgrade strategy for many Grafana releases
Do not upgrade every customer simultaneously. Pin a chart and application version, validate it against a representative datasource and dashboard set, then promote through cohorts. Record the rendered configuration hash and Helm revision for each tenant.
A rollback plan must consider both Kubernetes resources and Grafana's stored state. If a release changes plugins, database state, or provisioning behavior, restoring the previous chart revision alone may not restore service. Backups and compatibility checks belong in the rollout policy.
When shared Grafana is enough
A single shared Grafana instance is usually simpler and cheaper for internal teams or customers who can be safely separated with Grafana organizations, folders, and datasource permissions. Dedicated releases make sense when customers require custom domains, stronger credential and plugin boundaries, independent availability or maintenance windows, or contractual separation that a shared instance cannot satisfy cleanly.
Evaluation checklist
- Does every tenant have an explicit namespace and release owner?
- Are datasource credentials isolated and rotatable without touching other tenants?
- Are dashboards and alerting rules provisioned from a versioned source?
- Is persistent state backed up, or can the release be rebuilt deterministically?
- Can plugins and private CA bundles vary without creating uncontrolled drift?
- Can one tenant be upgraded and verified before the next cohort begins?
OpenTenant turns those repeated decisions into one reviewable tenant lifecycle while Grafana remains responsible for the observability application itself.