Beyond the Twelve-Factor App

Chapter 5. Configuration, Credentials, and Code

Factor 3 of the original 12 factors only states that you should store configuration in the environment. I believe the configuration guidance should be more explicit.

Configuration Chemistry

Treat configuration, credentials, and code as volatile substances that explode when combined.

That may sound a bit harsh, but failing to follow this rule will likely cause you untold frustration that will only escalate the closer you get to production with your application.

In order to be able to keep configuration separate from code and credentials, we need a very clear definition of configuration. Configuration refers to any value that can vary across deployments (e.g., developer workstation, QA, and production). This could include:

• URLs and other information about backing services, such as web services, and SMTP servers
• Information necessary to locate and connect to databases
• Credentials to third-party services such as Amazon AWS or APIs like Google Maps, Twitter, and Facebook
• Information that might normally be bundled in properties files or configuration XML, or YML

Configuration does not include internal information that is part of the application itself. Again, if the value remains the same across all deployments (it is intentionally part of your immutable build artifact), then it isn’t configuration.

Credentials are extremely sensitive information and have absolutely no business in a codebase. Oftentimes, developers will extract credentials ...