Best Practices for MySQL Environment Variables

Setting up environment variables for MySQL is crucial for securing database credentials, simplifying command-line access, and streamlining application deployment. This guide covers the best practices for configuring these variables, focusing on security, system path integration, and automation across different operating systems.

1. Add MySQL to the System PATH for Easy Access

To run MySQL commands from any terminal window without typing the full directory path, add the MySQL bin directory to your system’s PATH variable.

• On Windows: Add the path (typically C:\Program Files\MySQL\MySQL Server X.Y\bin) to the system’s “Environment Variables” under the PATH variable.
• On macOS/Linux: Add export PATH=$PATH:/usr/local/mysql/bin (or your specific installation path) to your shell configuration file, such as ~/.bashrc, ~/.bash_profile, or ~/.zshrc.

2. Avoid Using the MYSQL_PWD Variable

While MySQL supports the MYSQL_PWD environment variable to automatically log you in, using it is highly discouraged.

On Unix-like systems, environment variables can be viewed by other users running command-line utilities like ps. Storing your database password in MYSQL_PWD exposes your credentials to anyone with access to the server command line.

The Secure Alternative: mysql_config_editor

Instead of using variables for passwords, use the built-in mysql_config_editor tool. This utility creates an obfuscated login path file (.mylogin.cnf) that allows secure passwordless logins.

mysql_config_editor set --login-path=local --host=localhost --user=root --password

You can then log in securely using:

mysql --login-path=local

3. Use Standardized Naming Conventions for Applications

When connecting applications to your MySQL database, use standardized, uppercase environment variable names. This maintains consistency across development, staging, and production environments. Recommended names include:

• DB_HOST (e.g., 127.0.0.1 or the database container name)
• DB_PORT (default is 3306)
• DB_USER (the specific database user, not the root user in production)
• DB_PASSWORD (the database user’s password)
• DB_NAME (the specific schema name)

4. Secure .env Files in Development

In local development environments, developer tools often read environment variables from a .env file. To keep this file secure:

• Never commit .env files to version control: Add .env to your .gitignore file.

• Use template files: Commit a .env.example file that contains the variable names but leaves the actual values blank (e.g., DB_PASSWORD=your_password_here).

• Restrict file permissions: On Linux/macOS, restrict read access to the .env file to only the owner:

  chmod 600 .env

5. Leverage Secrets Managers in Production

In production environments, avoid storing MySQL connection details in plain-text OS environment files. Instead, inject variables dynamically using a cloud-native secret manager or container orchestration tool:

• Docker/Kubernetes: Use Kubernetes Secrets or Docker Secrets to securely inject MYSQL_ROOT_PASSWORD or application database credentials as environment variables at runtime.
• Cloud Providers: Use services like AWS Secrets Manager, HashiCorp Vault, or Google Cloud Secret Manager to retrieve and load MySQL credentials directly into your application’s environment memory.