As defined per the Twelve-Factor App methodology, the configuration of an application should live in a different place than the code itself.

Since configuration usually varies substantially across the different deployment environments (e.g. test, development, production, etc.), storing configuration as constants in the code is usually considered as bad practice.

Indeed, having to manually change per-deploy hard-coded values, such as canonical hostnames, every time the application needs to be re-deployed in a different environment would introduce an unmanageable overhead for developers and also prevent the implementation of an automated release pipeline.

Moreover, declaring sensitive information, such as database or third-party services credentials, in clear text within the code potentially constitutes a severe security breach.

💡 Tip: The easiest way to verify that an application has all of its configuration correctly factored out of the code is to ask yourself the following question: "Can the codebase be made open source at any moment without compromising any credentials?".

Creating configuration files

A configuration file is a plain text file that contains a list of key-value pairs used to configure the parameters and initial settings of computer programs in order to customize their behaviour.

Naming configuration files

The configuration files of the project will follow the Dotenv naming convention, which is a convention derived from the NPM package of the same name, where each file is pre-fixed with the ".env." expression, followed by the name of the deployment environment it's intended for.

For example:

.env.development.env.staging.env.production

Naming configuration variables

Since the variables the configuration files contain will be loaded in the environment of the process upon startup, we can follow the Unix naming standard for environment variables, which is the Screaming Snake Case, where each space is replaced by an underscore and all characters are written in uppercase.

For example: