Managing environment configuration in PHP projects can be achieved in a variety of ways. First, use the .env file of the Dotenv library to create configuration files for different environments such as .env.development and .env.production, and load them through vlucas/phpdotenv, and submit the sample files and ignore the real files; second, store non-sensitive metadata in the extra part of composer.json, such as cache time and log levels for script reading; third, maintain independent configuration files such as config/development.php for different environments, and load the corresponding files according to the APP_ENV variable at runtime; finally, automate configuration settings through CI/CD deployment, such as GitHub Actions to copy the corresponding configuration files, and obtain sensitive information from security services to ensure that the production key is not leaked.

Managing environment-specific configurations in PHP projects can be a bit tricky, especially when you're using Composer as your dependency manager. But the good news is, you don't need to reinvent the wheel—Composer itself doesn't directly handle config files, but it plays nicely with other tools and practices that let you manage configs per environment effectively.

Here are a few practical approaches most developers use:

Use .env Files with a Dotenv Library

One of the most popular ways to manage environment-specific settings is by using .env files. These files hold key-value pairs for configuration values ??like database credentials, API keys, or debug settings.

• How it works : You create different .env files for each environment (like .env.development , .env.production ) and load the right one based on where the app is running.
• Tooling help : Libraries like vlucas/phpdotenv integrate well with most frameworks and vanilla PHP apps. Composer can install these easily.

Example:

 # .env.development
DB_HOST=localhost
DB_USER=root
APP_DEBUG=true

You can commit a .env.example file to show the structure, but keep real .env files out of version control using .gitignore .

Leverage Composer's extra Section for Custom Config

If you want to store some basic environment-related metadata inside composer.json , you can use the extra section.

• Use case : It's helpful if you need to pass project-specific config to scripts or deployment tools.
• Not for secrets : Don't store sensitive data here—it's public in your repo.

Example:

 {
  "extra": {
    "branch-alias": {
    },
    "app-config": {
      "cache-ttl": 3600,
      "log-level": "debug"
    }
  }
}

Then, in custom Composer scripts or deployment steps, you can read this data programmatically using Composer's internal APIs or simple JSON parsing.

Use Different Configuration Files per Environment

Sometimes you might have more complex setup needs, like different service providers, cache backends, or logging levels depending on the environment.

• Approach : Keep separate config files like config/development.php , config/production.php , etc.
• Loading logic : At runtime, determine which environment you're in (via an env var like APP_ENV ) and include the correct config file.

This method gives you full control without relying too much on third-party libraries, though it requires writing a bit of bootstrap logic yourself.

A few tips:

• Set APP_ENV in your server environment or .env file.
• Fallback to a default environment if none is set.
• Avoid duplicating shared config—pull common parts into a base config.

Automate Configuration Setup During Deployment

When deploying via CI/CD pipelines or scripts, automatic setting up the correct config for each environment.

• Common practice : Use deploy scripts to copy or symlink the right config file into place.
• Secrets management : Pull sensitive values ??from secure sources like HashiCorp Vault, AWS Secrets Manager, or CI environment variables.

For example, in a GitHub Actions workflow:

 Steps:
  - name: Set up config
    run: |
      cp config/${{ env.APP_ENV }}.php config/app.php

This keeps your codebase clean and avoids accidental exposure of production secrets during development.

So, while Composer doesn't manage environment-specific configs directly, combining it with dotenv, smart config structures, and automated deployment makes it totally manageable. Just pick the approach that fits your project size and team workflow best.

Basically that's it.

The above is the detailed content of How do I manage environment-specific configurations with Composer?. For more information, please follow other related articles on the PHP Chinese website!