Guide Databases & MySQL

How to reset a database user password

Resetting the password is the easy part — updating every application that still has the old one saved is the part people forget.

Updated 5 min read Beginner

You cannot recover a MySQL user's existing password from your control panel — it is never stored anywhere in a form that can be read back, only checked against. If you have forgotten it, or you are rotating it as routine security practice, the only option is to set a new one. That part takes seconds. The part that actually causes problems is everything that was already using the old password and now cannot connect until you tell it about the new one.

Step 1: reset the password

In the databases section of your control panel, find the user and choose the option to change its password. Use a generated password if the panel offers one, and copy it immediately into a password manager — this is the only moment you will see it in plain text.

This takes effect immediately, for every application using that user

The moment you save the new password, anything still configured with the old one loses its connection to the database. On a live site, that means the site goes down the instant you click save, and it stays down until you update its configuration. Have the next step ready before you reset the password, not after.

Step 2: update every application that uses this user

A single database user is often used by exactly one application, but not always — some setups share a user across a staging copy and a live site, or across more than one application on the same account. Update the password everywhere it appears.

For WordPress

Open wp-config.php in the root of the site and find this line:

define( 'DB_PASSWORD', 'your_old_password' );

Replace the value with the new password, exactly as copied from the control panel, and save the file. The file manager in your control panel can edit this directly if you do not have FTP access set up.

For other applications

The equivalent setting is usually in a file named something like config.php, .env, or a database connection class, and the constant or variable is usually named something close to DB_PASS, DB_PASSWORD or database.password. If you are not sure where an application stores this, its documentation or installation guide will say.

Check for more than one copy

A site migrated at some point, or with a staging copy, sometimes has the old password saved in more than one configuration file. If the live site works after the update but a staging environment suddenly cannot connect, that is usually why.

Choosing the replacement password

A database password is never typed by a human at login time the way an email or control panel password is — it is pasted once into a configuration file and left there. That makes a long, random, generated password strictly better than a memorable one: nothing is gained by making it easy to recall, and a generated password is harder to guess or brute-force. Most control panels offer a "generate" option next to the password field; use it rather than composing your own.

If you are not sure what else uses this user

On an account that has grown over several years, it is easy to lose track of every place a database user's credentials ended up — an old staging copy, a script written by a previous developer, a backup tool configured once and forgotten. Before resetting a password on a database you know is shared or has an uncertain history, it is worth searching the site's files for the current password string, which will usually turn up every configuration file that references it. Doing this before the reset, while the old password still works, is far easier than discovering a missed copy afterwards by way of a second outage.

Step 3: confirm it actually connects

Load the site, or run the application, and confirm it works before considering the job done. If you see a database connection error rather than the working site, walk through fixing a database connection error — in the context of a password you just changed, the most likely causes are a typo introduced while pasting the new password, or a second configuration file still holding the old one.

If you were resetting the password because of a security concern

A password reset on its own does not remove access an attacker may already have through some other route — a compromised application, a leaked configuration file, or a vulnerable plugin. If you are rotating this password because you suspect the old one was exposed, also check who else the user is attached to and consider whether the privileges granted are wider than the application actually needs. Granting a user access to a database covers scoping privileges down to what is actually required, which limits the damage if a credential is compromised again in future.

If you have updated every configuration you can find and the connection still fails, contact us with the database and user names and we can check the account side directly.

Related reading