.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
A fresh Grafana install has one account in it, and the credentials are the same on every install anyone has ever done. That's convenient for about thirty seconds and a liability afterwards. This covers changing it properly, plus the handful of ways the default ends up rejected on an install you were sure was fresh.
The default Grafana login
Open http://localhost:3000 if you're on the machine itself, or http://YOUR_SERVER_IP:3000 from anywhere else. The default Grafana username and default password are both the same word:
username: admin
password: adminThose come from conf/defaults.ini, in the [security] section:
[security]
admin_user = admin
admin_password = admin
admin_email = admin@localhost
disable_initial_admin_creation = falseDon't edit that file. Grafana's own docs say so plainly, and anything you change there is overwritten on the next package upgrade. The file you edit is /etc/grafana/grafana.ini on a deb or rpm install, which is what a standard Grafana install on Ubuntu leaves you with, or conf/custom.ini if you unpacked the tarball. This article assumes the first layout throughout.
If the page doesn't load at all, look at the port and the service before the credentials. Something else owning 3000 is common, and the piece on the Grafana default port and how to change it walks through moving one of them out of the way. Run ss -tlnp | grep 3000 first to see which case you're in.
The password change prompt on first sign-in
Sign in with admin / admin and Grafana immediately asks you to set a new one. The sign-in documentation puts it as "If successful, you will see a prompt to change the password."
You can skip that prompt. On a box with port 3000 open to the internet, skipping it means you're running a login page with published credentials, and automated scanners find those within hours of the port opening. Set the password on the prompt, then go and close port 3000 anyway.
Change the admin password from the UI
After the initial prompt the password belongs to the user account and lives in the database. Click your avatar in the bottom left, go to Profile, then Change password. You need the current password to set a new one.
An admin can also reset any other user from Administration, then Users and access, then Users, pick the person, then Change password. That path works for the admin account too, as long as you're signed in as a different Grafana Admin. So make a second admin user on day one.
Set admin_user and admin_password before the first start
If you're building a server with a config management tool or an image, set the credentials before Grafana ever starts. In /etc/grafana/grafana.ini:
[security]
admin_user = grafana-admin
admin_password = a-long-random-string
admin_email = [email protected]The shipped grafana.ini arrives with a semicolon in front of every line, and one left in place is why a config edit appears to do nothing. Strip it from the keys above. Then start the service:
sudo systemctl start grafana-serverGrafana creates the admin row on that first start, using those values. The password sits in the file as plaintext, so this is only sensible when the file is readable by root and the grafana user alone. Environment variables are tidier on a fresh install and there's a section on them below.
I change admin_user away from admin on anything with a public IP, and not because it's real security. It isn't. The username is guessable in about four attempts. It's that a failed-login line naming admin is a generic scanner, and one naming the username I picked means somebody has looked at this instance specifically. That's a useful distinction to get free out of a file you're going to read anyway.
Why changing admin_password later has no effect
Edit admin_password on a running instance, restart and nothing changes. You still can't get in with the new value.
admin_password is a seed value. Grafana reads it once, when it needs to create the initial admin user, and writes the resulting hash into its database. After that row exists in grafana.db (or in your MySQL or PostgreSQL backend) the config key is ignored entirely. The database is the source of truth from then on.
So on an existing install, use the UI or the CLI reset below. The config key only matters on a database that has no admin user yet, which in practice means a brand new install or a wiped /var/lib/grafana.
disable_initial_admin_creation
Setting disable_initial_admin_creation = true under [security] tells Grafana not to create that first admin at all. The default is false.
You'd use it when every account comes from an external identity provider through OAuth or LDAP, and you don't want a local password account existing as a bypass. Turn it on before the first start, or the admin user is already created and the setting does nothing. Turn it on without a working identity provider and you have a Grafana nobody can sign into, which is a fast way to learn how the CLI reset works.
Reset a lost admin password with grafana cli
There's no password reset email for the local admin. You reset it from a shell on the server:
sudo grafana cli admin reset-admin-password <new password>Note the two-word form. grafana-cli with a hyphen still runs, but it now prints a deprecation warning telling you to use grafana cli instead. The systemd service is a separate thing and keeps its hyphen, so systemctl restart grafana-server is still right.
If the command complains that it can't find its configuration or its database, point it at the install home explicitly:
sudo grafana cli --homepath "/usr/share/grafana" admin reset-admin-password <new password>And when Grafana runs against an external MySQL or PostgreSQL database, the CLI needs your config file too, otherwise it resets the password in a SQLite file nobody is reading:
sudo grafana cli --homepath /usr/share/grafana --config /etc/grafana/grafana.ini admin reset-admin-password <new password>That third form is the one to reach for on any non-trivial install. The Grafana CLI documentation has the full flag list. A reset takes effect immediately with no restart.
Reset the password in a Docker container
Same command, run inside the container. Assuming the container is named grafana:
docker exec -it grafana grafana cli admin reset-admin-password <new password>The image already sets GF_PATHS_HOME=/usr/share/grafana, so the homepath usually resolves on its own. If it doesn't, add it:
docker exec -it grafana grafana cli --homepath /usr/share/grafana admin reset-admin-password <new password>If your compose file sets GF_SECURITY_ADMIN_PASSWORD, the reset still works and the next container recreate does not undo it, because that variable is also only read at admin creation time. Your reset stands. Update the compose file anyway so the two don't disagree with each other, and the Grafana Docker Compose setup has the pattern for keeping that value in a secrets file. Six months later nobody remembers which one is live.
Read the admin password from a Kubernetes secret
Deploy Grafana with Helm and there is no admin/admin to try. The chart generates a password and stores it in a Kubernetes secret named after the release, and Grafana's Helm deployment guide gives one command for reading it back out. Run this:
kubectl get secret --namespace monitoring my-grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echoSwap monitoring for your namespace and my-grafana for your release name. The trailing ; echo is there because the decoded value has no newline and would otherwise run into your shell prompt. The username sits in the same secret under .data.admin-user and is nearly always admin.
The kube-prometheus-stack chart is the case people hit most, and it has history. Older releases of that chart baked in a fixed default of admin / prom-operator, which is why that string is all over Stack Overflow and half the Kubernetes monitoring tutorials on the web. It still turns up in internal runbooks at companies that moved off the chart years ago. The maintainers dropped the hardcoded value at some point and the current values.yaml ships adminUser: admin with adminPassword left commented out.
I have never worked out which release made that change. The chart's changelog is mostly subchart version bumps and I can't find an entry that calls the credential default out, so I gave up looking and read the secret instead:
kubectl get secret -n monitoring kube-prometheus-stack-grafana \
-o jsonpath="{.data.admin-password}" | base64 -d ; echoIf that secret name doesn't exist, kubectl get secrets -n monitoring | grep grafana finds whatever your release named it.
When admin/admin is rejected
You've typed the default, you're certain the install is fresh and Grafana says invalid username or password. Two causes account for nearly all of these.
Brute force lockout after five failed attempts
Grafana blocks login attempts after repeated failures. The relevant [security] defaults are:
disable_brute_force_login_protection = false
brute_force_login_protection_max_attempts = 5Five wrong passwords and the account stops accepting logins for a cooldown period, at which point even the correct password looks wrong. The error comes back instantly on every attempt, including the ones you know are right. Wait it out. If it's a lab instance and you have shell access, run the CLI reset above and the lockout stops mattering.
Leave disable_brute_force_login_protection alone in production. It exists for the case where a load test or a broken automated login is tripping the counter. Turning it off in front of a public IP hands an attacker unlimited attempts, which is the sort of setting Grafana security best practices spends a section on. Five is a reasonable number.
An admin password set by environment variable
Grafana reads GF_<SECTION>_<KEY> environment variables and they sit above your config file in the precedence chain. If someone set GF_SECURITY_ADMIN_PASSWORD when the instance was first created, that value became the admin password and admin was never valid.
On a package install, check the environment file and the unit override:
grep -r GF_SECURITY /etc/default/grafana-server /etc/systemd/system/grafana-server.service.d/ 2>/dev/nullIn Docker, read it back from the running container:
docker exec grafana env | grep GF_SECURITYAlso check GF_SECURITY_ADMIN_USER, since a changed username produces exactly the same error message as a changed password. If neither turns anything up and the CLI reset doesn't help either, the problem sits upstream of credentials, so check the Grafana log next. A locked database file or a failed migration shows up there long before it shows up in the UI, and the common Grafana errors guide works through the ones whose messages don't help. Neither of those is a password problem at all.
Once you're back in, the fix that stops this recurring is to stop using the admin account for anything automated. API tokens and dashboard scripts should run as Grafana service accounts with their own tokens, so rotating the human admin password never breaks a pipeline.
