WordPress Environment Config: How to Set Up Dev/Staging/Production wp-config.php

Add wp-config-local.php to your .gitignore immediately. Developers clone the repo, copy the example file, fill in their local values, and never touch the shared file. New developer onboarding becomes: clone, copy example, fill in database credentials, done.

Handling WP_SITEURL and WP_HOME Per Environment

Two constants that must change per environment are WP_SITEURL and WP_HOME. When defined in wp-config.php, they override the database values. This is exactly what you want: it means a database sync from production to local will not redirect you back to the live URL as soon as you boot the site.

Without this override, pulling production data to a local environment requires running a database search-replace on the URL. With these constants set in wp-config-local.php, the local machine just works immediately after a database pull.

// wp-config-local.php on development
define( 'WP_SITEURL', 'http://mysite.local' );
define( 'WP_HOME',    'http://mysite.local' );

// wp-config-local.php on staging
define( 'WP_SITEURL', 'https://staging.mysite.com' );
define( 'WP_HOME',    'https://staging.mysite.com' );

Verify they are loading from config rather than the database with WP-CLI:

wp option get siteurl
wp option get home

Integrating .env Files

Some teams prefer storing credentials in a .env file and loading them into PHP. This aligns with the Twelve-Factor App methodology and works well when your deployment pipeline already handles .env injection. CI/CD tools, container orchestration platforms, and many hosting providers inject environment variables at the OS level, which PHP can read through getenv() or $_ENV.

Option 1: Use php-dotenv (Composer)

composer require vlucas/phpdotenv

// wp-config.php, before any defines
require_once __DIR__ . '/vendor/autoload.php';

$dotenv = Dotenv\Dotenv::createImmutable( __DIR__ );
$dotenv->load();
$dotenv->required( [ 'DB_NAME', 'DB_USER', 'DB_PASSWORD' ] );

define( 'WP_ENVIRONMENT_TYPE', $_ENV['WP_ENVIRONMENT_TYPE'] ?? 'production' );
define( 'DB_NAME',             $_ENV['DB_NAME'] );
define( 'DB_USER',             $_ENV['DB_USER'] );
define( 'DB_PASSWORD',         $_ENV['DB_PASSWORD'] );
define( 'DB_HOST',             $_ENV['DB_HOST'] ?? '127.0.0.1' );

The required() call causes a hard exception if any listed variable is missing from the .env file. That is useful: it fails early and loudly on a misconfigured environment rather than silently connecting to the wrong database.

Option 2: Native getenv() Without Composer

If you need to avoid Composer (some hosting environments have restrictions, or you simply want zero dependencies), you can parse a .env file with a small loader function:

// Minimal .env loader, no Composer required
function load_env_file( string $path ): void {
    if ( ! file_exists( $path ) ) {
        return;
    }
    $lines = file( $path, FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES );
    foreach ( $lines as $line ) {
        if ( str_starts_with( trim( $line ), '#' ) ) {
            continue; // skip comments
        }
        [ $name, $value ] = array_pad( explode( '=', $line, 2 ), 2, '' );
        $name  = trim( $name );
        $value = trim( $value, " \t\n\r\0\x0B'\"" );
        if ( '' !== $name ) {
            putenv( "{$name}={$value}" );
            $_ENV[ $name ]    = $value;
            $_SERVER[ $name ] = $value;
        }
    }
}

load_env_file( __DIR__ . '/.env' );

define( 'DB_NAME',             getenv( 'DB_NAME' ) );
define( 'DB_USER',             getenv( 'DB_USER' ) );
define( 'DB_PASSWORD',         getenv( 'DB_PASSWORD' ) );
define( 'DB_HOST',             getenv( 'DB_HOST' ) ?: '127.0.0.1' );
define( 'WP_ENVIRONMENT_TYPE', getenv( 'WP_ENVIRONMENT_TYPE' ) ?: 'production' );

Your .env file structure:

WP_ENVIRONMENT_TYPE=development
DB_NAME=wp_local
DB_USER=root
DB_PASSWORD=
DB_HOST=localhost
WP_SITEURL=http://mysite.local
WP_HOME=http://mysite.local

Always add .env to .gitignore. Keep a .env.example with blank or placeholder values committed. When someone joins the team, they copy the example and fill in their local values.

Using WP-CLI to Verify Config Values

Once your config is in place, verify constants are loaded correctly using WP-CLI without touching the browser. This is especially useful after a deployment to confirm the right values are in effect.

# Check all defined constants from wp-config.php
wp config list

# Check a specific constant
wp config get WP_ENVIRONMENT_TYPE
wp config get WP_DEBUG

# Get the environment type via WP function
wp eval 'echo wp_get_environment_type();'

The wp config list command outputs every constant defined in wp-config.php along with its value and whether it is a constant or a variable. Run it on each environment after deployment to confirm values loaded as expected. If a value is wrong, you catch it before users do.

Per-Environment Constants Reference

Controlling File Upload and Memory Limits

PHP memory limits and upload sizes often differ across environments. Development machines typically have more generous limits; shared hosting production servers might be tighter. You can control the WordPress-level limits directly in wp-config.php without touching PHP ini files, as long as you stay at or below the PHP ceiling.

// wp-config-local.php on development
define( 'WP_MEMORY_LIMIT',      '512M' );
define( 'WP_MAX_MEMORY_LIMIT',  '512M' ); // admin processes

@ini_set( 'upload_max_filesize', '128M' );
@ini_set( 'post_max_size',       '128M' );

Verify the actual limit with:

wp eval 'echo WP_MEMORY_LIMIT;'
wp eval 'echo ini_get("memory_limit");'

Disabling Automatic Updates Per Environment

Automatic core updates on staging should be off so you control what version you are testing against. On production, minor version auto-updates are generally safe and keep you current on security patches.

// Development and staging: no auto-updates
define( 'WP_AUTO_UPDATE_CORE', false );
define( 'AUTOMATIC_UPDATER_DISABLED', true );

// Production: allow minor version auto-updates only
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Cron and Scheduled Tasks Across Environments

WordPress uses pseudo-cron: scheduled tasks only fire when a page request comes in. On development, where traffic is minimal or non-existent, scheduled events may go unfired for long stretches. Two solutions work well depending on your setup.

First option: disable WordPress pseudo-cron and run a real server crontab. This gives you predictable task timing and avoids tasks firing on a slow-loading request from a real user.

// Disable WordPress pseudo-cron
define( 'DISABLE_WP_CRON', true );

// In your server crontab:
// */5 * * * * /usr/bin/php /path/to/wordpress/wp-cron.php

Second option: use WP-CLI to trigger events manually during development when you need to test a scheduled workflow:

# Run all due cron events
wp cron event run --due-now

# Run a specific hook manually
wp cron event run my_scheduled_hook

# List all scheduled events
wp cron event list

Staging-Specific Hardening

Staging is often forgotten when it comes to security and operational hygiene. It should mirror production as closely as possible while having a few important safeguards.

Suppress outbound email on staging. You do not want automated order confirmation emails or password reset links going to real users from a staging environment. Add a mail intercept plugin, or drop a small mu-plugin that intercepts all outbound mail and either discards it or redirects it to a development inbox.

Block search engine indexing. Even if your staging URL is not publicly known, it is good practice to keep staging out of search indexes. The Settings > Reading > Search Engine Visibility setting handles this for most cases.

Use different auth salts than production. If staging and production share auth salts, a session cookie generated on staging will authenticate on production. This creates a path for privilege escalation if staging is less controlled than production.

// wp-config-local.php on staging
define( 'WP_ENVIRONMENT_TYPE', 'staging' );
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'DISALLOW_FILE_EDIT', true );

// Staging-specific salts, different from production
define( 'AUTH_KEY',        'staging-unique-auth-key-here' );
define( 'SECURE_AUTH_KEY', 'staging-unique-secure-auth-key-here' );

Security Keys Per Environment

Security keys and salts sign session cookies and nonces. If dev, staging, and production all share the same keys, a session created on staging remains valid on production. That is a privilege escalation risk. The WordPress security hardening guide covers the full set of server-level and wp-config protections worth applying to production.

Generate a unique set for each environment:

# Generate fresh salts and output as PHP constants
wp config shuffle-salts

# Or fetch directly from the WordPress API
curl https://api.wordpress.org/secret-key/1.1/salt/

Store the production keys in your production wp-config-local.php or inject via .env on the server. They should never appear in a committed file. Regenerate them any time you suspect a breach or after a developer leaves the team.

CI/CD Integration

In automated pipelines (GitHub Actions, Bitbucket Pipelines, DeployHQ), you typically inject config via environment variables rather than committing any config file. The platform injects them into the process environment at deploy time, and your wp-config.php reads them via getenv() exactly like it would read from a .env file.

# GitHub Actions workflow snippet
env:
  DB_NAME: ${{ secrets.STAGING_DB_NAME }}
  DB_USER: ${{ secrets.STAGING_DB_USER }}
  DB_PASSWORD: ${{ secrets.STAGING_DB_PASSWORD }}
  WP_ENVIRONMENT_TYPE: staging

The deploy step pulls these from GitHub Secrets and injects them. Your wp-config.php does not change between deployments; only the environment variables change. This pattern works identically for Bitbucket Pipelines, GitLab CI, CircleCI, or any other pipeline tool that supports secret injection.

Multisite and Subdirectory Installations

For WordPress Multisite, the domain constants change per environment. With the wp-config-local.php pattern, each machine sets its own DOMAIN_CURRENT_SITE without touching the shared file, which prevents Multisite redirect loops when syncing databases across environments.

// Development multisite config in wp-config-local.php
define( 'DOMAIN_CURRENT_SITE', 'mynetwork.local' );
define( 'WP_ALLOW_MULTISITE', true );
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

Common Mistakes and How to Fix Them

• WP_DEBUG left on in production: Move all debug constants to wp-config-local.php where they can never reach production. The shared file should not contain any debug constants at all.
• Committing wp-config-local.php accidentally: Add a pre-commit hook that checks for the file. A one-line check in .git/hooks/pre-commit will catch it: git diff --cached --name-only | grep -i wp-config-local && exit 1
• Staging and production sharing auth salts: Run wp config shuffle-salts on each new environment immediately after setup. Make it part of your environment provisioning script.
• Missing wp-config-local-example.php: Every constant you add to the local config needs to appear in the example file with a placeholder value. Otherwise new developers have no idea what fields are expected.
• Forgetting to set WP_SITEURL on local after a database pull: If your wp-config-local.php defines WP_SITEURL and WP_HOME, this handles itself. If not, you need a wp search-replace after every database sync.

Choosing the Right Approach for Your Team

For most WordPress projects, the wp-config-local.php split is the pragmatic choice. It keeps the shared file lean, plays nicely with Git, and requires no build tooling. The conditional hostname approach is fine for solo projects where you are the only developer. The .env approach pays off when you already have a pipeline that injects secrets and you want consistency with how other apps in your stack are configured.

A Production-Ready Shared Template

Here is a complete shared wp-config.php template that pulls together all the patterns from this guide. It is designed to be committed to version control with no credentials and to fail safely to production defaults when no local file is present: