Fork me on GitHub

System environment variables at Seravo

In all Seravo’s environments (production, staging/testing shadow, local development etc) there are many environment variables defined. Examples include:


The environment variable WP_ENV always contains the environment name. When code is running on the live production site it always sees a WP_ENV with the value production. Different testing environments have different names, e.g. staging and development.


This is the name of a particular environment instance. For example example_1ab2c3. This may change over time. Don’t write any logic in your WordPress code based on this.


This is the internal domain name given to a live production site given by Seravo. An example could be It is used in cases when the real external domain (e.g. has not yet been registered, does not point to the site or might have some other issue and does not work.


These always contain the Redis server address and port.


These always contain the database credentials. Please rely on these and the database connection will always work even when you have different passwords in production and in testing. Avoid from hardcoding any passwords or server addresses in your code.


Each of these contain a unique key (e.g. xifablhk84nimz4k6p71b5b2hvuq0js66m9db7vcfthdxa4bvtumfykirwfq342q) which is different from environment to environment, but always the same inside the same environment. Using these constants makes the source code of your WordPress site more secure, since it will be void of any secrets. Below is an example of how the wp-config.php at any site at Seravo looks like:

 * Authentication Unique Keys and Salts
 * You can find them by running $ wp-list-env
define('AUTH_KEY',         getenv('AUTH_KEY'));
define('SECURE_AUTH_KEY',  getenv('SECURE_AUTH_KEY'));
define('LOGGED_IN_KEY',    getenv('LOGGED_IN_KEY'));
define('NONCE_KEY',        getenv('NONCE_KEY'));
define('AUTH_SALT',        getenv('AUTH_SALT'));
define('LOGGED_IN_SALT',   getenv('LOGGED_IN_SALT'));
define('NONCE_SALT',       getenv('NONCE_SALT'));

Using Dotenv

The wp-config.php file uses Dotenv by default which enables you to create a file called .env in the root of your project to override default environment variables.


$ cat .env.development
# Run 'ln -s .env.development .env' in project root to activate this

$ ll .env
lrwxrwxrwx 1 otto otto .env -> .env.development

You can have template files like .env.development tracked in version control, and then make a location-specific symbolic link from .env to the correct file. By default the .env file is and should be ignored by git via gitignore.

Note on Dotenv version 5.0.0

With the latest version 5.0.0 the syntax of Dotenv changed again. In new instances of wp-config.php you will find lines like:

$dotenv = Dotenv\Dotenv::createUnsafeImmutable($root_dir);

The Unsafe in the function name looks bad, but indeed necessary for getenv('NAME') to work in WordPress/PHP.

Note on Dotenv version 2.4.0

In the version 2.4.0 the syntax of Dotenv changed. In new instances of wp-config.php you will find lines like:

$dotenv = new Dotenv\Dotenv($root_dir);

The older syntax was:


The version of Dotenv on your site (and syntax in your wp-config.php) is what was at the time when the site was created. If you later run composer update and thus update Dotenv to version > 2.4.0, you need to update the lines in your wp-config.php manually, otherwise your WordPress will just display a blank page and your /data/log/php-error.log will have fatal error messages about Dotenv.

For more information, see the Dotenv UPGRADING documentation that lists major changes across all versions.