Using the Environment for Runtime Configuration

The runtime configuration is information Rails cannot properly determine on its own, but that is critical for our app to be able to start up and run. This information also tends to be different in development, testing, and production. Database credentials are a great example.

Rails provides three mechanisms that all work together to manage runtime configuration:

• The UNIX environment

• The config/database.yml

• An encrypted YAML file

The last one is also called config/credentials.yml.enc (encrypted with config/master.key).

This creates a lot of confusion and makes scripting a consistent environment difficult. We value consistency, so we want one way to manage runtime configuration, not three.

Managing files in production is becoming increasingly difficult (due to ephemeral, containerized deployment systems) and risky since runtime configuration is often secret information like credentials and API keys.

Which architecture to follow?

We’ll follow the architecture of a 12-factor appTwelve-factor app is a methodology for building distributed applications that run in the cloud and are delivered as a service. and standardize it on the UNIX environment. The UNIX environment is a set of key/value pairs provided by the operating system to the application. In a Ruby application, we can access it via the ENV hash. For example, if our API key to our payment processor is “abcdefg1234,” we would arrange to have that value set in the UNIX environment under a key, such as PAYMENTS_API_KEY. We can then access it at runtime via ENV["_PAYMENTS_API_KEY_"].

Rails already uses this mechanism for database credentials (looking at the key DATABASE_URL) as well as the general secret key used for encrypting cookies (under the key SECRET_KEY_BASE). Because of this, there’s nothing special we need to do in our app about this—we just need to use ENV to access runtime credentials. The existence of the other mechanisms in our app will be confusing, so we should delete those files now: