Revert the change in variable. You should only be rotating credentials via the Database > Config tab, not manually with variables.

Thanks for the quick response, much appreciated.

Unfortunately I don't have the old password anymore — I overwrote it in my password manager when I rotated to the new one (the rotation was done because the old password had been accidentally exposed in a chat log earlier today).

Given this constraint, I have two questions:

1. Is there a way to update mysql.user grant tables server-side to match the current MYSQL_ROOT_PASSWORD env var? (e.g. via Railway internal admin access)

2. Alternatively, would restarting the MySQL service container cause the Docker entrypoint to re-apply MYSQL_ROOT_PASSWORD to the grant tables? If yes, this would be the safer path. If not, I'd need server-side intervention.

For context: production app is currently serving via stale container with cached connection (deploy from 17h ago). No customer outage yet, but ~30 failed deploys accumulated today.

Also noted for the future: I'll use Database > Config tab for credential rotation going forward. Apologies for the manual Variables approach.

Thank you again.

Try this:

1. Remember the current Custom Start Command
2. Change the Custom Start Command to docker-entrypoint.sh mysqld --skip-grant-tables --skip-networking and redeploy
3. SSH into your MySQL service (Right click the service and Copy SSH Command) (You'll need Railway CLI installed for this to work)
4. In the terminal, paste the SSH command and run mysql -u root
5. Run the following commands:

ALTER USER 'root'@'localhost' IDENTIFIED BY '<PASSWD>';
ALTER USER 'root'@'%' IDENTIFIED BY '<PASSWD>';
FLUSH PRIVILEGES;

Where <PASSWD> is replaced with the new password (From the variable MYSQL_ROOT_PASSWORD)

1. Revert the custom start command and redeploy MySQL
2. Make sure to restart other services that depend on your MySQL database

Thank you for the detailed steps — I appreciate the thoroughness.

Given this involves production downtime, SSH operations I haven't performed on Railway before, and the risk of further corrupting grant tables if executed incorrectly, would it be possible for a Railway engineer to execute these steps on my behalf via internal access?

Production customers depending on this service: UNIMED Porto Alegre (9-year client), Centauro/SBF, IMC Pimenta Verde Alimentos, plus PagBank pipeline negotiation.

If self-service is the only option available, I'll proceed carefully but would appreciate confirmation on these specifics before I start:

1. With --skip-grant-tables enabled, does mysql -u root -p still prompt for a password, or is authentication bypassed entirely (just press Enter)?

2. Are the three ALTER USER statements sufficient on their own, or should I include FLUSH PRIVILEGES; as a separate fourth command after them?

3. When I revert the Custom Start Command back to the original value, will Railway auto-deploy the change, or do I need to manually trigger a redeploy?

4. What is the expected downtime window for services with active connections to this MySQL during the procedure (steps 2-6)?

5. Are there any state-preserving steps I should take before changing the Custom Start Command (e.g. ensuring InnoDB buffer flush)?

Happy to do this during a coordinated maintenance window if Railway team prefers a scheduled async approach. Available all afternoon BRT today, or any time the team prefers.

Thanks again.