How to upgrade Grafana Helm chart deployments on Kubernetes without losing dashboards
Upgrading a Grafana release installed from the grafana-community/grafana chart is a planned change to three things at once: the Helm release values, the database that holds Grafana's state, and the plugin values that decide what loads at startup. It is not a single helm upgrade command. The chart is community-maintained and provided without warranties, so your team owns the values file, the chart version pin and the test of each change. Persistence is also disabled by default, which means a pod restart loses data unless persistence.enabled is set to true. Check that setting in the live release before you touch anything, because a restart during an upgrade is the most likely way to lose dashboards that were created through the UI.
Plan the upgrade against the Grafana release you are moving to and the Kubernetes version your cluster runs. Grafana's upgrade guidance describes major releases once a year in April or May, minor releases about every other month, and patch releases at least monthly. Each minor release is supported for 9 months, and the last minor release of a major version for 15 months. Use those windows to decide how far behind you can safely stay. Kubernetes has its own support cycle and version skew rules, so confirm which chart version maps to which Grafana image tag, and which Kubernetes minor version your cluster supports, in your own environment before you pick a target. Do not assume the chart's default image tag is the release your plugins were tested against.
Before running helm upgrade, export the database and the release values. If Grafana uses SQLite on a persistent volume, copy grafana.db from the volume. If it uses MySQL or PostgreSQL, take a logical or snapshot backup of that database and record the chart version and values file in version control. The first upgrade step is a staging run against a copy of the database, with the same plugin list and the same secrets, so you can see which plugins fail to load or which dashboards need changes. Keep the previous chart version and values available so you have a documented way back if the new release fails its health checks.
Which Grafana changes need action in a Helm release
This table compares the Grafana and Kubernetes changes that affect a Helm-managed release and the action each one requires before or after helm upgrade. Read each row against the target Grafana version, because the release notes for that version decide which plugin and data source changes apply to your instance.
| Change | Impact on a Helm deployment | Action needed |
|---|---|---|
| Persistence disabled by default | Grafana data is lost on pod restart unless persistence is enabled in the chart values | Confirm persistence.enabled is true in your values file before any upgrade, and check that the volume survives the release |
| SQLite not suited to production | The default SQLite database does not scale for production or high availability | Move to MySQL 8.0 or later or PostgreSQL 12 or later, and back up the database before running helm upgrade |
| 12.0.0 major release (May 5, 2025) | Major releases can change plugin, data source and configuration behavior that the chart values depend on | Read the 12.0.0 release notes and audit plugins and data sources in your values before moving across this boundary |
| 13.1.0 release (July 1, 2026) | A major-line change can require plugin updates and changes to stored dashboards or data source references | Review the 13.1.0 release notes, test the chart with a copy of your database, and confirm plugin versions |
| 13.2.0 release (August 18, 2026) | Later minor releases in the same line can change behavior and carry their own plugin notes | Read the 13.2.0 release notes and repeat the plugin and data source check for the exact version in your values |
| Release cadence and support windows | Minor releases arrive about every other month and each minor is supported for 9 months, so the target version may age quickly | Plan upgrades on a fixed schedule and avoid staying on a minor release beyond its support window |
| Kubernetes version skew policy | The kube-apiserver must be upgraded one minor version at a time, and kubelets may be up to three minor versions older | Confirm the cluster version and upgrade it in steps before raising the Grafana chart to a version that needs newer Kubernetes APIs |
What to back up and inventory before helm upgrade
Helm upgrades replace running pods and can change the database schema, so the work before the upgrade decides whether you can get back to a known state. The cards below cover the data, the configuration, the plugins, the as-code resources and a rehearsal environment, in the order most teams will need them.
Confirm persistence and back up the database
Check first whether the chart is writing to a persistent volume. Persistent storage is disabled by default, so persistence.enabled must be true for data to survive a pod restart, and an upgrade that recreates the pod can otherwise wipe local state. Then back up the database: a MySQL or PostgreSQL dump if you run an external database, or grafana.db if the instance still uses SQLite. Store the backup outside the cluster and confirm it can be restored before you start the upgrade.
Save the values file and rendered manifests
Export the values file that is currently applied, using the release name and namespace you deployed, and keep it in version control. Render the existing release to manifests so you have a record of the ConfigMaps, Secrets references, Services and PersistentVolumeClaims that the chart created. Diff the rendered output of the new chart version against this baseline before running helm upgrade, and review every change to storage, service accounts and ingress.
Inventory the plugin list and plugin values
List every plugin the release installs, including versions, and the values keys that set them. Plugins are the most common source of breakage after a major upgrade, so record which ones are community plugins, which are Grafana Labs plugins, and which have no current maintainer. Note any plugin that was installed at startup from a URL, because that download happens again on each pod start and can pull a different version than the one you tested.
Export provisioning files for data sources, dashboards and alerts
Provisioning files define data sources, dashboards, plugins and alerting resources as YAML or JSON loaded at startup. Confirm that these files live in a ConfigMap or Git repository you control, not only in the running pod, and that they match what the live instance uses. Resources created through the UI and not provisioned will not come back if the release is recreated, so identify them and export them before the upgrade.
Rehearse in a non-production namespace
Restore the database backup into a separate namespace or cluster, deploy the same values file with the target chart version, and run the upgrade there first. Use the same Grafana image tag and plugin set as production so the rehearsal reflects real behavior. Record every warning, failed plugin load, dashboard error and alert rule that does not evaluate. Treat the rehearsal result as the input to the production change window, and keep the production rollback path defined before you start.
The helm upgrade sequence with checks and rollback points
This sequence moves a Grafana release installed from the community Helm chart to a new version in a controlled order, with a check and a rollback point at each stage so that a failed upgrade can be reversed without losing dashboards, data sources or alert configuration. It is written for the team that owns the Grafana release on the cluster.
Confirm the chart repository and refresh the index
Confirm that the Helm repository points to the community-maintained chart by running
helm repo add grafana-community if it is not already present, then runhelm repo update. The chart is provided without warranties and is maintained by the community, so the team should record the repository name and URL in the change record. Check the output withhelm search repo grafana-community/grafana --versions` and confirm the chart version pinned for your target Grafana release against the release notes before continuing. Rollback point: nothing has changed on the cluster yet, so stopping here has no effect on running Grafana.Confirm the cluster version and skew window
If the upgrade also moves the Kubernetes cluster, the cluster change must go first, because the Kubernetes version skew policy requires kube-apiserver to be upgraded one minor version at a time before kubelets and other components. Confirm the current cluster version and the version your chart release requires, and record the planned order of changes. Check that the cluster version is within the supported skew for the Grafana chart and nodes, and do not start the Grafana change until the cluster is in a stable state. Rollback point: the cluster upgrade has its own rollback path, which should be documented before Grafana is touched.
Diff current values against the target chart defaults
Export the values the release is running with, using
helm get values grafana -n <namespace> -o yaml, and compare them with the defaults of the target chart version usinghelm show values grafana-community/grafana --version <chart-version>. Pay particular attention to persistence, because persistent storage is disabled by default in the chart, so data is lost on restart unlesspersistence.enabledis set to true. Also review plugin values, the database settings and any secret references. Keep the exported values file in version control. Done means every changed key has a documented decision, and the persistence setting is confirmed as true for any instance that holds state. Rollback point: the exported values file is the reference for restoring the previous configuration.Take and verify the database backup
Back up the database that holds Grafana configuration before any change to the release. Production instances should use MySQL 8.0 or later or PostgreSQL 12 or later, because SQLite does not scale for production, so take a logical or snapshot backup of that database using your standard database tooling. Also back up the provisioning files, plugin list and the exported values file. Verify the backup by restoring it into a scratch database or confirming the file is readable and complete, and record the backup identifier. Done means a restore has been tested, not only a backup job reporting success. Rollback point: this backup is the only reliable way back across a database schema change, so the team should confirm who can restore it and how long that takes in their environment.
Run the helm upgrade in staging
Run the upgrade in a staging namespace or cluster that mirrors production values, using
helm upgrade grafana grafana-community/grafana --version <chart-version> -n <namespace> -f values.yaml. Use--dry-runfirst and review the rendered manifests for changes to persistent volume claims, services and secrets. Check that the rollout completes and that the release history shows the new revision. Rollback point:helm rollback grafana <previous-revision> -n <namespace>returns the release to the prior chart and values, but it does not undo database schema changes, which is why the backup in the previous step must be verified first.Check pods, logs, data sources and plugins
Confirm that the pod has started and is ready with
kubectl get pods -n <namespace>, then read the Grafana logs withkubectl logsfor errors on database migration, plugin loading and data source connections. Open a sample of dashboards and run queries against each critical data source, and check that plugins installed through values load without errors. Compare the Grafana version reported in the UI or API with the target release. Done means the pod is ready, the logs contain no blocking errors, and each critical data source returns data. Rollback point: if any check fails, roll back the release and restore the database backup only if the migration changed the schema.Promote the change to production
Repeat the same sequence in production during an agreed window, using the values file and chart version that passed staging, and keep the production backup identifier in the change record. Run the same pod, log and data source checks and confirm alerting still routes notifications as expected. Done means the production release shows the new revision, all checks pass, and the team has signed off on the result. Rollback point: keep the previous release revision and the verified backup available until the team has confirmed the upgrade is stable, and document the owner who makes the rollback decision.
Why persistence and the database decide your rollback
A Helm rollback restores the release manifests, not the data. Running helm rollback reverts the Kubernetes objects the chart rendered (Deployments, ConfigMaps, Services and so on), but it does not reverse a database migration that Grafana already applied during the newer version's startup. Persistent storage is disabled by default in the Helm chart, so unless persistence.enabled is set to true, Grafana's local state is lost on restart. In that case the database is the only recovery source, and a chart rollback without a database backup leaves you with an older image pointed at a schema it may not understand. Before you change any value, confirm in your own values file whether persistence is on and where the Grafana database is configured.
The database decision comes first. The Grafana installation docs say SQLite does not scale for production, so production and high availability need MySQL 8.0 or later or PostgreSQL 12 or later. Check which database your release uses by reviewing the grafana.ini database settings in your values file, then confirm the server version against those minimums. Take a logical backup of that database (for MySQL or PostgreSQL, the dump or snapshot your team already trusts) and store it outside the cluster, with a note of the Grafana image tag and chart version it came from. Test that the backup restores into a scratch instance before the upgrade, because an untested backup is not a rollback plan.
If you run more than one replica, the high availability model adds constraints. Grafana's high availability setup uses two or more active-active servers behind a load balancer, all sharing one MySQL or PostgreSQL database, and the docs note that alerting needs additional configuration to avoid duplicate notifications. Confirm how your chart values set the replica count, the shared database connection and the alerting settings, and whether a rolling upgrade will run mixed Grafana versions against the same database during the update. Also confirm the HA limitations for Grafana Live in your version. Treat these as items to verify in your own environment against the Grafana high availability guide, not as settled behavior for your chart release.
What makes a Grafana Helm upgrade take longer
This table lists the factors that expand the work of a Helm-based Grafana upgrade and what to verify for each one. Read each row against your current values file and cluster, because the same chart version can take a day or a week depending on these answers. The main takeaway is that plugin pinning, persistence and the database engine decide most of the risk before the upgrade starts.
| Driver | Why it adds effort | What to check |
|---|---|---|
| Plugin count and pinning | Plugins listed in values are installed at pod start, so an unpinned or abandoned plugin can change behavior or fail to load after a major version change. | List every plugin in values, confirm each version is pinned, and check each one against the target Grafana release. |
| Custom values and templates | Hand-edited values, extra volumes, init containers and chart template overrides must be re-tested against the new chart defaults. | Diff your values file against the chart's default values for the target chart version and record every override. |
| Provisioning as code coverage | Data sources, dashboards and alert rules defined in YAML or JSON, Terraform or Git Sync must be reapplied and checked after the upgrade. | Identify which objects come from provisioning files and which were created in the UI, since UI-only objects need a backup and manual check. |
| Persistence setting | Persistent storage is disabled by default in the chart, so a restart without persistence.enabled set to true loses data, which turns the upgrade into a recovery task if misconfigured. | Confirm persistence.enabled is true in your values and that the volume claim survives a rollout. |
| Database engine and size | SQLite is the default and does not scale for production, while MySQL 8.0 or later and PostgreSQL 12 or later need their own backup, restore and version checks. | Confirm the engine in use, its version, its size, and that a tested backup exists before running helm upgrade. |
| Authentication setup | LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab, Google OAuth, auth proxy and JWT work in all editions, but SAML, team sync and SCIM need Enterprise, so auth settings must be tested after the upgrade. | Document each identity provider setting in values or secrets and test a login with each method on a staging release. |
| Replicas and high availability | Two or more active-active servers sharing one database need consistent upgrade order, and alerting needs extra configuration to avoid duplicate notifications. | Confirm replica count, the shared database, and how alerting is configured before rolling replicas one at a time. |
| Target major versions | Each major release can remove or change behavior, so a jump across several majors means reviewing the notes for each one in order. | Count the major versions between your current and target release and review the upgrade notes for each step. |
Which upgrade path fits your current Helm setup
This is the setup where Grafana's configuration lives in a MySQL or PostgreSQL database outside the pod, and the chart keeps local files on a persistent volume. The database holds the state that matters most, so the upgrade is mainly a database and chart change. Grafana requires MySQL 8.0 or later or PostgreSQL 12 or later for production use.
- Back up the database first: Take a dump or snapshot of the MySQL or PostgreSQL database before you run
helm upgrade, because a chart rollback does not undo changes made to the database. - Snapshot the volume: Confirm
persistence.enabledis set totrueand snapshot the PersistentVolumeClaim that holds plugins and other local files. - Keep the old chart values: Save the current values file so you can reproduce the previous release if you roll back.
- Check plugin settings: Review plugin entries in the values file so plugins match the target Grafana version.
- Plan the rollback around the database: Restoring the database backup is what returns stored state to the old version, so test that restore before the upgrade window.
Before editing anything, confirm the database connection and persistence key names in the values file for your chart version.
Persistence is disabled by default in the Helm chart, and Grafana stores configuration in SQLite 3 unless you point it at MySQL or PostgreSQL. With the defaults, data is lost on restart, so the first task is to find out whether any state exists that you need to keep. SQLite does not scale for production, so this setup is usually a starting point rather than a long-term target.
- Check for state: If
persistence.enabledwas never set totrue, dashboards, users and other changes made in the running pod may already be gone. - Export definitions: Export dashboards and data source definitions through provisioning files or the API so you can recreate them if the pod restarts during the upgrade.
- Copy the SQLite file: If a
grafana.dbfile exists in the pod, copy it out before the upgrade, because it is the only copy of the embedded database. - Enable persistence before upgrading: Turn on persistence and confirm the volume is attached and writable, so the next restart keeps state.
- Plan a database move: Because SQLite is not suited to production, decide whether to migrate to MySQL or PostgreSQL before or after the upgrade.
Confirm the path where your chart version stores grafana.db and whether it mounts a volume at that path.
High availability uses two or more active-active Grafana servers behind a load balancer, all sharing one MySQL or PostgreSQL database. Every replica reads and writes the same state, so the database backup protects all of them, but the upgrade also has to avoid problems that come from replicas running different versions. Grafana's high availability guidance notes that alerting needs extra configuration to avoid duplicate notifications and that Grafana Live has limitations in HA.
- Back up the shared database once: One backup covers every replica, so take it before the first pod restarts.
- Confirm the rollout strategy: Check how the chart rolls out replicas and whether the target version's upgrade notes allow mixed versions during the rollout.
- Verify alerting configuration: Confirm the duplicate-notification settings survive the values change, and test that only one notification is sent after the upgrade.
- Test features with HA limits: Check any dashboards that depend on Grafana Live, since its HA limitations apply after the upgrade as well.
- Account for sessions: Database-backed auth tokens let users reach any node, so include the sessions stored in the database in your rollback plan.
Before the change, confirm the replica count, rollout settings and alerting key names for your chart version.
What do buyers ask before hiring help with a Grafana Helm upgrade?
How much does a Grafana Helm upgrade cost, and what drives the quote?
The cost depends on the written scope, not on a list price. DeployOpen does not publish a price list, and a quote follows from the scope agreed in writing. The main cost drivers are the number of Grafana instances and clusters, whether persistence is already enabled, how many data sources, plugins and dashboards need checking, whether alert rules must be reviewed, and whether the database is MySQL or PostgreSQL or the default SQLite. Ask the provider to separate one-time work (assessment, backup, upgrade, verification, handover) from any recurring retainer for support or later upgrades, and to state which items are excluded.
How long does a Grafana Helm upgrade take?
The schedule is set by the number of environments, the plugin and alerting review, and how quickly your owners can sign off. A single non-production instance with few plugins is the simplest case. Production work adds a change window, a tested backup and restore path, and a rollback plan. Ask the provider to show the sequence of steps and which ones depend on your team, such as approvals, access grants and test sign-off. Confirm the target Grafana version first, since major releases carry different technical notes.
What does our team need to provide during the engagement?
Expect to provide access and people. You need cluster access with rights to read the release, Deployments, Secrets and PersistentVolumeClaims in the Grafana namespace, access to the Grafana database (grafana.db, MySQL or PostgreSQL) for a backup, and access to the Git repository or values files that hold your Helm configuration. You also need named owners for dashboards, data sources and alert rules who can confirm that each one still works after the upgrade. Without those owners, the review stalls at the point where someone must decide what is still needed.
Can our own team run the Grafana Helm upgrade without a partner?
Yes, many teams do, provided they have someone who can run Helm, read the Grafana upgrade notes and test dashboards and alerts. The grafana-community/grafana chart is community-maintained, so the team should read its values and changelog as well as Grafana's own notes. The work that usually needs outside help is the plugin audit, the backup and restore test, and the validation of alert routing across a shared instance. Decide which of these your team has time and skills to own before choosing between doing it in house and hiring help.
Is the Grafana Helm chart supported by Grafana Labs?
The chart is community-maintained and is provided without warranties, according to the Grafana Helm documentation. Support from Grafana Labs for the chart itself should not be assumed. Your support path therefore depends on the chart maintainers, your own team, or a contracted provider. Before you upgrade, confirm with Grafana Labs which support options apply to your edition and deployment method, and check the chart's repository for its release notes and open issues.
Can we roll back a Grafana Helm upgrade without a backup?
A clean rollback is hard to guarantee without a backup. Helm can revert the release to a previous revision, but it does not restore the Grafana database or change data that the newer version has already written. If persistence is disabled, data stored in the pod is lost on restart, so there may be nothing to recover. Take a copy of the database and persistent volume before running helm upgrade, and test restoring it in a non-production environment. The rollback path should be written into the scope before work starts.
How is a fixed-scope Grafana upgrade agreement written?
Most DeployOpen engagements are fixed-scope, which means the scope, deliverables and timelines are agreed in writing before work starts. A useful agreement names the instances and clusters covered, the target Grafana and chart versions, the data sources and plugins in the review, the backup and rollback method, the verification steps and who signs them off, and the handover documents. It should also list exclusions such as custom dashboards, new integrations or unrelated clusters. Any change to that scope is handled as a written change request with its own quote.
How DeployOpen scopes and delivers a Grafana Helm upgrade
DeployOpen plans Grafana Helm chart upgrades as fixed-scope work agreed in writing before any change reaches the cluster. The plan covers the chart source, persistence, plugin values, the database backup taken before helm upgrade, and the post-upgrade checks your team signs off on.
How we scope
- Inventory the running release, chart version, values files and the Grafana image tag in use today.
- Confirm whether persistence.enabled is set and where the Grafana database, SQLite or MySQL or PostgreSQL, actually lives.
- Record every plugin value, data source and dashboard dependency that the target Grafana version must still support.
How we build
- Pull the grafana-community chart and render the target values in a non-production namespace before any live change.
- Take and verify a database backup and copy the current values and plugin configuration before running helm upgrade.
- Test dashboards, data sources, alert rules and login paths against the upgraded release, then document each result.
How we hand over
- Deliver the written values changes, rollback steps and backup location, so your team can repeat the procedure.
- Walk through the post-upgrade checklist with your platform and monitoring owners, including what to watch for in the first days.
- Record open items such as plugins still needing updates, with owners and dates agreed with your team.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial upgrade is complete.
- Retainer scope for future Grafana releases is agreed in writing, so each later upgrade follows the same documented method.
- Ask us to confirm which Kubernetes version and Grafana release your target cluster must support before scoping starts.
