LiveChat 
Support 
Changing a MySQL User Password (Application User) the Right Way
Changing a MySQL user password is one of the most routine database administration tasks, but it is also one of the easiest to get half-wrong. When you rotate the password for an application database user, such as the account your WordPress site or custom app uses to connect, the database change itself takes a single SQL statement. The part that catches most people out is everything that has to happen *immediately after*.
This guide focuses on the everyday scenario: you need to change the password of a non-root application user, the account that powers a live website or service. We will cover the SQL command, the cPanel and phpMyAdmin routes, and the critical follow-up step that prevents your site from going dark.
Key Takeaways
• Use `ALTER USER ‘appuser’@’host’ IDENTIFIED BY ‘newpassword’;` to change an application user’s password in modern MySQL and MariaDB.
• The change is not finished at the database level. You must update the application’s connection string (`wp-config.php`, `.env`, or app config) with the new password, or the app will instantly fail to connect.
• Update the database and the application config together, ideally within seconds, to avoid downtime.
• Rotate passwords on a schedule and after any staff change, suspected leak, or contractor offboarding.
• For a forgotten root password or a full reset, see the sibling guides linked below; this article is about routine app-user rotation.
Why would you change an application user’s password?
A non-root MySQL user is the dedicated account an application uses to read and write its own database. Rotating its password is a healthy security habit, and sometimes a necessity. Common triggers include:
- Scheduled rotation as part of a security policy (quarterly or biannually is typical for production systems).
- Offboarding a developer, contractor, or agency that had access to the credentials.
- Suspected compromise, such as credentials found in a public repository, log file, or leaked backup.
- Migration cleanup, where an old shared password needs to be replaced with a unique one.
- Compliance requirements that mandate periodic credential changes.
The guiding principle is simple: the fewer people and systems that know a given password, and the shorter its lifespan, the smaller your exposure if it ever leaks.
How do you change a MySQL user password with SQL?
For an application user, the modern and correct command is `ALTER USER`. Connect to MySQL or MariaDB as a privileged account (usually `root` or an admin user with the right grants), then run:
“`sql — Change the password for an application user bound to localhost ALTER USER ‘appuser’@’localhost’ IDENTIFIED BY ‘N3w-Str0ng-P@ssw0rd!’; “`
The `’appuser’@’localhost’` part matters. A MySQL user is defined by both its username and the host it connects from. If your app connects over the network rather than a local socket, the host portion may be an IP, a hostname, or a wildcard:
“`sql — If the app connects from a specific application server ALTER USER ‘appuser’@’10.0.0.25’ IDENTIFIED BY ‘N3w-Str0ng-P@ssw0rd!’;
— If the user is defined with a wildcard host ALTER USER ‘appuser’@’%’ IDENTIFIED BY ‘N3w-Str0ng-P@ssw0rd!’; “`
If you are not sure which host your user is bound to, list the accounts first:
“`sql SELECT User, Host FROM mysql.user WHERE User = ‘appuser’; “`
Do you need FLUSH PRIVILEGES?
When you use `ALTER USER`, you generally do not need `FLUSH PRIVILEGES`. That command reloads grant tables and is only required when you modify the privilege tables directly with `INSERT`, `UPDATE`, or `DELETE` statements. Since `ALTER USER` is a proper account-management statement, MySQL applies it immediately.
You only need this fallback if you edited the `mysql.user` table by hand:
“`sql FLUSH PRIVILEGES; “`
On older MySQL 5.6 or earlier installations you may encounter `SET PASSWORD` syntax instead, but for any currently supported MySQL 5.7+, MySQL 8.x, or MariaDB 10.x release, `ALTER USER … IDENTIFIED BY` is the recommended approach.
The trap nobody warns you about: changing a database user’s password without updating the application’s connection string instantly breaks the application. The moment `ALTER USER` runs, the old password stored in `wp-config.php` or your `.env` file is wrong. The very next request the app makes to the database is rejected, and your visitors see the dreaded “Error establishing a database connection” on WordPress, or a generic 500 error on a custom app. The database is healthy and the data is intact, but the app can no longer log in. This is why the SQL command is only half the job: always treat the password change and the config update as a single, inseparable operation.
How do you update the application config after changing the password?
This is the step that separates a clean rotation from an outage. After the SQL command succeeds, immediately update wherever the application stores its database password.
WordPress stores it in `wp-config.php`:
“`php // wp-config.php define( ‘DB_USER’, ‘appuser’ ); define( ‘DB_PASSWORD’, ‘N3w-Str0ng-P@ssw0rd!’ ); // <-- update this line define( 'DB_HOST', 'localhost' ); ```
Laravel, Node, and many modern frameworks use a `.env` file:
“`bash
DB_USERNAME=appuser DB_PASSWORD=N3w-Str0ng-P@ssw0rd! “`
After editing `.env`, some frameworks cache config and need a refresh (for example, `php artisan config:clear` in Laravel, or a service restart for a Node process manager). The rule across every stack is the same: the password in the app config must match the password in the database, exactly.
Here is the correct order of operations for a low-downtime change:
| Step | Action | Where |
|---|---|---|
| 1 | Confirm the user’s exact username and host | MySQL (`SELECT User, Host …`) |
| 2 | Generate a strong new password | Password manager / generator |
| 3 | Run `ALTER USER … IDENTIFIED BY …` | MySQL CLI, phpMyAdmin, or cPanel |
| 4 | Immediately update `wp-config.php` / `.env` | Application config file |
| 5 | Clear any config cache / restart the service if needed | App layer |
| 6 | Load the site and confirm it connects | Browser / health check |
The window between steps 3 and 4 is the only time the app is broken. Keep it to seconds. For larger or higher-traffic systems, perform the change inside a brief maintenance window so a momentary connection error is never visible to real users.
How do you change the password in cPanel or phpMyAdmin?
Not everyone has command-line access, and shared hosting users typically work through a control panel. The good news is the result is identical.
Using cPanel’s MySQL Databases tool:
- Log in to cPanel and open MySQL Databases.
- Scroll to Current Users.
- Find your application user and click the password / set-password option.
- Enter the new strong password and save.
- Then open the File Manager (or your editor) and update `wp-config.php` or `.env` with the same password.
Using phpMyAdmin:
- Open phpMyAdmin from cPanel or your host’s dashboard.
- Click the User accounts tab.
- Find the application user, then choose Edit privileges.
- Open the Change password section, enter the new password, and click Go.
- Then update the application config file with the matching password.
Notice that every route ends with the same final instruction: update the app config. The interface changes; the rule does not.
DarazHost: database management without the guesswork
Rotating database credentials should be a two-minute task, not a source of downtime anxiety. DarazHost hosting plans include intuitive cPanel and phpMyAdmin tools for managing MySQL and MariaDB users, so you can change an application user’s password through a clean interface, no command line required. You also get full File Manager and SSH access to update `wp-config.php`, `.env`, and other app config files in the same session, keeping your database and your application perfectly in sync.
For teams that need command-line control, our VPS plans provide full root access for `ALTER USER` operations, scripted credential rotation, and automation. And whenever a password change does not go to plan, our 24/7 expert support is available to help you restore a connection fast. keep your databases and your applications working together.
How do you choose a strong password and rotate safely?
A rotated password is only an improvement if the new one is genuinely strong. For database users:
- Use at least 16 characters, mixing upper and lower case, numbers, and symbols.
- Make it random, not a dictionary word or a predictable pattern.
- Use a unique password per user and per environment (staging and production should differ).
- Store it in a password manager, never in plain text on a desktop or in a shared chat.
- Avoid shell-breaking characters in passwords used on the command line, or quote them carefully, since characters like `$`, “ ` “, and `!` can be interpreted by the shell.
For ongoing hygiene, build rotation into a routine: rotate on a calendar schedule, and always rotate immediately after anyone who held the credential leaves the project.
What if you are locked out or forgot the root password?
This guide deliberately covers the routine app-user case. Two related scenarios need a different approach:
- If you have forgotten the MySQL root password, you cannot simply `ALTER USER` because you cannot log in. That requires starting MySQL in safe mode and resetting it. See .
- If you are changing the root or admin password as a deliberate security step, the mechanics differ slightly and carry more risk. See .
For everything that connects an application to its database, the `ALTER USER` plus config-update workflow above is the one you want.
Frequently asked questions
Do I need to restart MySQL after changing a user’s password? No. `ALTER USER` takes effect immediately. Existing open connections are not dropped, but every new connection must use the new password. You only need to restart or reconfigure the *application* so it picks up the new credential.
Why does my site show “Error establishing a database connection” after the change? Almost always because the application config still has the old password. The database accepted the change, but `wp-config.php` or `.env` was not updated to match. Update the config file with the exact new password and reload.
Is FLUSH PRIVILEGES required when changing a password? Not with `ALTER USER`. `FLUSH PRIVILEGES` is only needed when you modify the grant tables directly with raw `INSERT`/`UPDATE`/`DELETE` statements. Account-management commands like `ALTER USER` apply automatically.
Will changing the password drop existing database connections? No. Active sessions stay connected. The new password is enforced on the *next* authentication attempt, which is exactly why you should update your app config promptly before it has to reconnect.
How often should I rotate an application database password? A common production cadence is every three to six months, plus an immediate rotation after any suspected leak, repository exposure, or team member departure. Match the frequency to your security policy and risk tolerance.
Conclusion
Changing a MySQL or MariaDB application user’s password is a one-line SQL command, `ALTER USER ‘appuser’@’host’ IDENTIFIED BY ‘newpassword’;`, but the task is not done until the application config is updated to match. Treat the database change and the `wp-config.php` or `.env` update as a single operation, keep the gap between them to seconds, and verify the connection afterward. Do that, and a routine credential rotation stays exactly that: routine, with zero visible downtime.
