Resetting a lost Grafana admin password

Resetting a lost Grafana admin password without rebuilding the instance

Locked out of a shared Grafana with no working admin login? The grafana CLI can reset a local user's password when you run it on the server with access to Grafana's database. The command changes the stored credential directly, so you do not need to rebuild the instance, re-import dashboards or reconfigure data sources. It is a recovery tool, not a daily admin path. Anyone who can run it on the host already has full control of the data behind the login, so it belongs in your break-glass procedure, with the host access to use it limited to a small group and every use recorded in your change process.

Teams usually need this in three situations. The first is a forgotten password on a local admin account in a single-instance deployment. The second is an instance that stores its configuration in an external MySQL or PostgreSQL database, where the CLI must be pointed at that same database rather than a local file, so confirm which database the running process actually uses before you start. The third is an instance where most users sign in through SSO and the only local account is the emergency admin. In that case the local password may have been set years ago and never used, which is exactly when it gets lost. Check these things before an incident: which account is your break-glass admin, where its password is recorded, and who can reach the host.

Two checks reduce the chance of needing this at all. Map at least one SSO group to the Grafana Admin role so that an identity provider administrator can always get in, and confirm that this mapping still works after any change to the identity provider. Note that SAML, team sync and active sync are available only in Grafana Enterprise and Grafana Cloud, according to the Grafana authentication docs, so confirm which options your edition supports before you rely on them. Confirm the exact CLI syntax and user ID lookup against the documentation for your installed version, since the steps differ between packaging methods such as Docker, Helm and package installs.

How to run the reset-admin-password command safely

This sequence restores sign-in to a self-hosted Grafana admin account without changing dashboards, data sources or other users. It resets the password through the Grafana CLI against the same configuration and database the running server uses, and it ends with a verified login.

Confirm shell access to the Grafana host
An engineer with root or sudo access on the Grafana server, virtual machine or container runs the work. Locate the Grafana binary and the configuration file that the running service loads, for example with which grafana or which grafana-cli depending on how you installed it, and check the service's startup arguments or unit file for the configuration path. Done means you can run the CLI from the same host, with the same user context, and you have written down the configuration path and the database type the server reports at startup.
Back up the database before changing anything
The engineer who owns the Grafana database takes a backup while the instance is stopped or quiesced, so the copy is consistent. For the default SQLite database, copy the database file and its companion files. For MySQL or PostgreSQL, create a logical dump with the vendor's standard tool. Also copy the configuration file and any custom plugin or provisioning folders. Done means each backup file exists, has a non-zero size, and is stored somewhere the reset cannot overwrite. Confirm the restore procedure with your database team before you proceed.
Match the configuration and database settings
The reset command must read the same configuration file and database connection that the running server uses. If the server points at MySQL or PostgreSQL, the CLI must use the same host, database name and credentials, typically through the same configuration file or environment variables. Otherwise the command can succeed against an empty or outdated database and change nothing that users see. Done means the database type and connection target reported by the CLI match what you recorded from the server's startup log or configuration.
Identify the correct admin user ID
The engineer queries the Grafana user table in the same database to list accounts with administrator rights, including login, email and the numeric ID. Run a read-only query such as SELECT id, login, email, is_admin FROM user; and confirm which row is the account you intend to recover. Accounts created through single sign-on can carry different logins or emails, so check the mapping before choosing. Done means you have one numeric ID tied to one administrator account, and you have noted which ID the CLI will target based on the version's help output.
Run the reset with the new password
The engineer runs grafana cli admin reset-admin-password with the new password, after checking the version's help output for the exact syntax and any user ID option. Avoid typing the password directly into a shared shell history. Use a prompt, a protected environment variable or a password manager entry where your policy allows. Done means the CLI reports that the password was updated and returns without database connection or permission errors. Record the change in your operations log, without the password itself.
Restart if required and verify sign-in
Confirm in the Grafana documentation for your version whether the server must restart after a password reset, and restart the service only if it does. Then sign in as the recovered administrator with the new password, open the administration area and confirm that the user list and data source settings load. Sign out, and store the new password in your secrets manager. Done means the login succeeds, administrator pages render, and other users can still sign in as before.

Pointing the CLI at SQLite, MySQL or PostgreSQL

SQLite is the default backend, so a Grafana instance without a [database] override keeps its configuration in a file on local disk. The CLI finds that file through the same grafana.ini the server reads, so the path only matches when the CLI runs with the same config and homepath. The Grafana installation docs state that SQLite does not scale for production, so this path is most often found on test or evaluation instances.

Config and homepath: Pass the same --config and --homepath values the service uses. A package install and an unpacked archive can point at different data directories.
File ownership: Run the command as the account that owns the database file. A write made as root can leave ownership wrong, and the service may then fail to start.
Service state: Stop Grafana before writing to the file so the server does not overwrite the change from its own state.
Stray copies: Backup copies of the database on the same host are easy to edit by mistake. Confirm the path points to the live file.

Before you write, confirm that the file the CLI targets is the one the running service uses, and confirm its modification time changes after the reset.

With MySQL 8.0 or later, the CLI connects over the network using the [database] settings the server uses, so the host, database name and credentials must match the running instance. Production and high availability deployments keep their configuration in an external database, which makes MySQL a common case for the readers of this page. A CLI that reads a stale or different block will reset a password in a database no user logs into.

Matching keys: Compare type, host, name and user under [database] with the service configuration. The password may come from the file or from an override, so check both.
Environment overrides: Variables with the GF_DATABASE_ prefix can override file settings. If the service unit sets them and your shell does not, the CLI reads a different target.
Network path: The host running the CLI must reach the database endpoint the server uses. A load balancer or proxy address may route to a node other than the writer.
Write rights: The database user needs write access to the Grafana schema. A read-only replica will reject the update, and the error may be unclear.
Config drift: A file in /etc/grafana and a configuration baked into a container image can differ. Identify which one the running process loads.

Before the reset, query the users table with the same client settings to confirm the admin row exists in the target database.

PostgreSQL 12 or later works like MySQL from the CLI's side: it reads the [database] block, connects over the network and writes to the Grafana schema. The difference lies in how teams usually run it. Connection poolers, managed endpoints and non-default schemas make the target easier to misread, so the mismatch risk is higher even when the settings look correct.

Version floor: Confirm the server runs PostgreSQL 12 or later, the minimum listed in the installation docs, before you troubleshoot anything else.
Schema and search path: If your deployment uses a non-default schema or search path, the CLI must use the same connection settings. Otherwise it may update a table the server never reads.
Pooler endpoints: A pooler address can route to a different backend than the one the service uses. Connect through the same endpoint the service uses, and ask the database team which endpoint is the primary.
SSL mode: Match the ssl_mode setting used by the service. A mismatch fails at connection time, and relaxing the mode only to make the CLI connect is a change to review, not a workaround.
Role grants: Use a database role that has write access to the Grafana tables and that your database team can audit.

Before the reset, ask the database owner to confirm the primary endpoint and the schema in use, and record both in the change ticket.

The CLI does not ask which database it should change. It applies whatever configuration it loads, so a short check before writing guards against editing a copy, a stale file or a test instance. These steps apply to all three backends and produce evidence that the change reached the database the server reads, which matters for later audit or incident review.

Identify the active config: Record the config path and homepath the running service uses, taken from its unit file or container command, and use those same values in the CLI call.
Read the database settings: Note the type and target under [database] and any environment overrides, then compare them with the CLI invocation.
Confirm the user exists: Look up the admin login in the users table of the target database and record its user ID before the reset.
Test through the server: After the reset, sign in through the browser with the new password. The CLI succeeding does not prove the server reads that database.
Record the target: Keep the backend type, host and config path in the change record so a reviewer can see which database was changed.

If the change record and the running server disagree about the target, stop and resolve the mismatch before writing anything.

Recovery options compared and when each fits

This table compares the four ways to regain control of a Grafana instance, from a local CLI reset to rebuilding from provisioning files. Read each row against your own situation: what you still have, what access you hold on the host, and what you can afford to lose. The main takeaway is that the fastest fix is not always the safest, because some options roll back data created after the last good copy.

Option	Fits when	Host access needed	What it changes and main risk
CLI reset of a local admin	The instance uses its own database, you still have shell access to the server, and only the admin password is lost	Shell as the user running Grafana, with access to the grafana CLI and its configuration	Sets a new password for one local user. Dashboards and users remain, but the change is made directly in the database, so back up that database first.
Restore from a recent database backup	The admin account or its password was damaged, or a recent dump is known to be good and the newer changes can be recreated	Access to the database server, the backup store and a maintenance window to stop Grafana	Rolls the whole database back to the backup point. Dashboards, users, folders and settings created after that point are lost unless recovered from elsewhere.
New admin through an identity provider login	Single sign-on is configured, a user in the identity provider should hold the Grafana Admin or Org Admin role, and role mapping was set up in advance	Access to the identity provider console and the Grafana configuration file to confirm role mapping	Changes no stored data if the mapping already works. Fails if no mapped user exists, and the role must be correct before you rely on it.
Rebuild from provisioning files and backups	Data sources, dashboards and alerting are defined as code in Git or on disk, and a current backup of configuration and database exists	Access to the source repository, backup storage, a new or cleared Grafana install and the database	Creates a fresh instance and reloads defined resources. Users, manual dashboard edits, and anything not provisioned are lost or need recreation, which takes longer to complete.
Confirm local admin login is enabled	Local login is the path you plan to rely on for recovery	Read access to the Grafana configuration file	If local login is disabled, the CLI reset will not help you sign in. Check this before you need it, and record where the configuration lives.
Confirm which user ID to target	You will use the CLI reset and need to identify the correct account	Read access to the database or the user list through the API as an existing admin	A reset applied to the wrong user ID changes the wrong account. Confirm the ID and login name before running the command.

Finding the right user ID before you reset

Confirm the exact account before you run any reset. The grafana cli admin reset-admin-password command takes a new password and works on a single user, so the reset only helps if you point it at the correct record. The most reliable way to find that record is to query the user table in Grafana's database, where each account has an id, a login, an email, a name, and an is_admin flag. Match on the login or email you expect the admin to use, then note the numeric id and the login value side by side. If your instance uses SQLite, the default, you can run the query against the grafana.db file while Grafana is stopped. If you use MySQL or PostgreSQL, run it against that database with a read-only account so you cannot change anything by accident.

Resetting the wrong ID silently changes a different person's password. A shared login, such as a generic admin account used by several operators, makes this more likely because the password you reset may be the one that other people still use, and the team will lose access without understanding why. Renamed users create a similar risk: an old login may now belong to someone else, or the person you think is the admin may have changed their login but kept the same id. Always confirm that the id you plan to use matches the login you are trying to recover, and that the email on the record belongs to the person who will sign in. Record the before and after state of the account so you can explain the change later in your access review.

Check that the account is a server admin rather than an organization admin. The is_admin flag marks server-wide administrators, while organization roles such as Admin or Editor are stored separately in the org membership data. An account can be an org admin in one organization and have no server-wide rights, so resetting its password will not restore access to server settings. Also check accounts created through SSO, such as Entra ID, Okta or generic OAuth, that have no local password. Resetting a password for these accounts gives them a local login they may not need and does not change how they authenticate, so confirm with your identity team whether the correct fix is in the identity provider. Ask whether your Grafana edition supports the SSO method you use, since the Grafana authentication docs list which providers each edition supports.

Preventing lockouts with SSO admin mapping

Recovering the admin password with the CLI is a last resort. The controls below reduce how often you need it by making sure admin access survives identity provider changes, staff turnover and database moves. Confirm which login methods your chosen edition supports before you design around them.

Map an identity group to admin roles

Map a specific identity provider group to the Grafana Server Admin role and to organization admin roles, so admin rights follow group membership instead of a hand-edited local account. Check the mapping against the login method your edition supports: the open-source authentication options are listed in the docs, while SAML and team sync are Enterprise features. Confirm this before you rely on group-based admin roles.

Keep two break-glass admins

Keep at least two named local admin accounts that work without the identity provider, so one forgotten password or one broken SSO mapping does not block every administrator. Store their credentials in a vault with access logging, and rotate them when staff with vault access change. Test the local login at a set interval, because a break-glass account that has never been used is often the one that fails.

Limit access to the CLI host

The CLI reset works only for someone who can run the grafana cli command on the server or container that holds the Grafana configuration. Restrict shell and container exec access to a small, named group, and log those sessions. This turns password recovery into a controlled, auditable step rather than an open path to the database.

Document database credential holders

The CLI reset writes to the database Grafana uses, and an external MySQL or PostgreSQL database is the production default for high availability. Record who holds the database credentials, where they are stored, and how they are rotated. Without this list, a lockout can turn into a database access problem that takes longer to solve than the password itself.

Test admin login after provider changes

Before and after any change to the identity provider, such as a new tenant, a renamed group or a certificate rotation, have a mapped admin sign in and confirm the admin role is applied. Keep a short written test script listing each admin path. A change that breaks mapping is much easier to roll back when it is caught in the same change window.

Keep provisioning files in Git

Store configuration files, including authentication settings and any provisioned data sources, in version control with review before merge. A reviewed Git history shows who changed the admin mapping and when, and it lets you restore a known-good file after a bad edit. Confirm which provisioning options your Grafana version supports and how they interact with the authentication settings you use.

Security risks of recovery access

A password reset is an administrative action that bypasses the normal login path, so the risks sit in who can reach the host, the database and the logs. The cards below cover the access, the traces, the secrets and the follow-up work that keep a recovery from becoming a quiet compromise.

Host access equals account access

Anyone who can run the Grafana CLI on the server, or connect to its database with the right credentials, can reset the password of any local account, including other admins. Treat shell access to the Grafana host as equivalent to administrator access in Grafana. Confirm who holds root or sudo on each instance, and whether those accounts are individually named and reviewed. Local accounts are the ones this reset affects, so SSO-only users are not reset this way.

Thin audit trail by default

A CLI reset run from a shell does not necessarily produce an entry inside Grafana's own user activity views. What you can see depends on your shell auditing, system logs and database audit settings. Before relying on the reset as a controlled event, confirm which of these your environment records and where they are retained. The depth of your audit trail depends on your own logging configuration, not on Grafana alone.

Passwords in shell history and tickets

A new password typed as a command argument can land in shell history, terminal session recordings, monitoring output or a support ticket where the steps were pasted. Prefer an interactive prompt or a password manager entry, and clear any history lines that captured a value. Ask your team to avoid pasting raw command output into tickets, and to redact the user ID and password fields before sharing logs.

Database credentials as high-value secrets

When Grafana runs on an external database, the CLI needs connection details that can read and write the whole Grafana configuration, including user records and API tokens. Those credentials carry more risk than the admin password they recover. Store them in a secrets manager or a restricted file readable only by the service account, rotate them after recovery work, and limit which hosts can reach the database port.

Session review after recovery

A reset does not end existing sessions or tokens on its own in every case, so the work is not finished when the new password works. Review active sessions and API keys for the affected account, revoke any you do not recognize, and check whether other admins were changed during the same window. Confirm the exact behavior of your Grafana version against the docs before assuming old sessions are invalid.

Documented change record

Each recovery should leave a change record naming the requester, the approver, the host, the target user ID, the time and the reason. Store it in your change management system, not in the shell history or a chat thread. The record gives auditors and incident responders a single place to match against logs and session reviews. Ask your compliance lead which fields your change policy requires.

Questions teams ask before recovering a Grafana admin

How long does recovering a lost Grafana admin password take?

The reset itself is a short command run on the Grafana server, so the elapsed time is driven by everything around it. The main factors are how quickly someone with shell access to the host can be reached, whether the database is a local SQLite file or a shared MySQL or PostgreSQL instance, how many Grafana nodes sit behind the load balancer, and whether change approval is needed before anyone touches production. Teams with a documented runbook, a known database location and a named approver usually finish in a single change window. Ask any partner for a written scope that lists each step, the systems touched and the approvals required, rather than a single duration.

Can our own team recover the admin password without outside help?

Usually yes, if someone on the team has root or equivalent access to the Grafana host, knows how Grafana was installed, and can identify the correct user in the database. The grafana cli admin reset-admin-password command is run on the server where Grafana is installed and sets a new password for the admin account. Where Grafana runs in containers or on Kubernetes, the same command is run inside the Grafana pod or container, with the same configuration file and database in scope. Outside help is most useful when the install was done long ago, the configuration is undocumented, or the only people who knew it have left.

What access and information does a recovery need?

Plan to gather four things before the work starts:

Shell access to every Grafana node, with sudo or the equivalent, and the container runtime or Kubernetes access if Grafana runs there.
The grafana.ini configuration file, including the [database] section and any environment variables that override it.
Database credentials and network access to the external database, if one is used.
A decision on who approves the change and where the new credential will be stored, such as a password manager or a secrets vault.

Record who performed the reset, when, and on which node, so the change can be traced afterward.

Is restoring a database backup safer than resetting the password?

A database restore is only safer when the reset itself is risky or when the database has been damaged, because restoring rolls back everything written since the backup, including dashboards, users, teams and data source changes. A password reset changes one credential and leaves other data untouched, so it is usually the smaller change. Restoring makes sense when the admin account was deleted or corrupted, or when an unauthorized change needs to be reversed. Before choosing either path, confirm that a recent, tested backup exists and check the Grafana backup and restore guidance on your own setup. Test any restore on a separate instance first.

What does adding SSO admin mapping and break-glass accounts cost?

Cost depends on the identity provider, the edition of Grafana, and the number of teams whose access must be mapped. The Grafana authentication documentation lists SAML, team sync, active sync and SCIM provisioning as available only in Grafana Enterprise and Grafana Cloud, so an open-source instance may need a different method, such as generic OAuth, to map admin roles. The one-time work covers identity provider configuration, role mapping rules, and testing. Recurring work covers reviewing who holds admin rights and rotating the break-glass credential, which should be stored offline and tested on a schedule. Ask for each item to be priced separately in a written scope.

How do we avoid getting locked out again?

Lockouts usually happen when the only admin is a local account nobody remembers, or when an SSO mapping removes admin rights from everyone. Keep at least one break-glass admin account with a credential held in a secure store, confirm that at least two people know how to reset it, and make sure the configuration and database locations are written down. Where SSO is used, map an admin group from the identity provider so that an administrator can still sign in after the local account is disabled. Test both paths periodically, because an untested break-glass account is often unusable when it is needed.

When should we bring in a partner for an admin recovery?

Bring in a partner when the recovery touches production data you cannot afford to lose, when the database is shared across several Grafana nodes, or when no one on the team can confirm the install method or configuration. A partner can also help when an audit or compliance review needs documented evidence of the change and the access controls around it. DeployOpen implements, hardens, backs up and documents self-hosted open-source platforms in your own infrastructure, and works from a fixed scope agreed in writing before work starts. Ask for the scope, deliverables, and the approval steps before any access is granted.

How DeployOpen works on this

DeployOpen approaches a lost Grafana admin password as an access recovery job on a platform you run in your own infrastructure. We start by confirming how Grafana is deployed and where its configuration database lives, then restore access through a controlled, documented procedure and put guardrails in place so the lockout does not repeat.

How we scope

Engagements are fixed-scope, with recovery steps, deliverables and timelines agreed in writing before work starts.
We confirm the Grafana version, install method and whether the instance uses SQLite, MySQL or PostgreSQL before any change.
We identify which login methods are in use, including whether SSO admin mapping exists, so the written scope covers the right accounts.

How we build

We run the admin reset from the Grafana CLI on the host or container, with the database connection pointed at the external store.
We confirm the correct user ID with a read-only lookup so the intended account is changed and no other user is affected.
We design SSO admin role mapping and a break-glass admin path so an identity provider outage cannot lock every administrator out.

How we hand over

You receive a written runbook covering the reset steps, the commands used, the database target and the verification checks performed.
We document the admin mapping and fallback account decisions, with the owner and location of the recovery credentials recorded.
We walk your platform and security staff through the procedure so the next recovery does not depend on a single person.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so access procedures are reviewed as Grafana releases change.
Access recovery steps can be re-tested on a schedule against a restored copy, with results recorded for your audit trail.
Retainer scope, response expectations and review cadence are agreed in writing alongside the original recovery scope.

Resetting a lost Grafana admin password