Applications needs configuration depends on the environment, e.g. the credentials of a database. Lets have a look at different approaches solving this requirement, their pros and cons.

All Configuration files in the repository


In this approach we define an application configuration file default.json, which will be always used, and one for every environment dev.json, stage.json and prod.json, which will be only used in the actual environment.


  • Easier to installing multiple times the same environment and ensure the consistence
  • Code changes and new needed configuration can be done in the same step
  • Version control give the overview about configuration changes


  • Have access to the code means have access to all configuration, also the critical ones like database credentials
  • Add or modify environment configuration need changes in the repository and new code deploy

Write configuration file during deploy


In this approach we define an application configuration file default.json. During the deploy we create another configuration file env.json which is filled by the actual environment configuration.


  • The repository doesn’t care about the different environments
  • Having only access to the code doesn’t result in having access to the critical configuration


  • Deploy needs to care about create the env.json file
  • There must be a separated history available about the changes of the environment configuration

Use environment variables

process.env in JavaScript
getenv() in PHP

They are a common way to give an application variables from the environment. In Node.js they can be set by the CLI command starting the application. In PHP they can be set by php.ini, vhost or .htaccess.

The large pros comes with the support by the hosting service. Heroku offers a web UI to set/modify the environment variables, show a history of all changes and allow to revert them.


  • Its a common way for all languages and supported by all cloud providers
  • Environment configuration is separated from the code and can easily changed
  • Changes are tracked and revertable
  • Its possible to create new apps with another environment configuration without code changes
  • Access to the code and access to the environments can separately given


Use environment variables is the most flexible, secure and maintainable approach, but needs some support if the tracking and reverting is needed.