Managing environment variables

Our applications will often need access to various credentials in the form of API tokens, usernames, and passwords for integrations with third-party services. We can store this information in our Git repository, but then, anyone with access to our code will also have a copy of our production credentials. We should instead use environment variables to store any configuration information for our application. Configuration information should be separate from our application's code and instead be tied to the specific deployment of the application.

Changing our application to use environment variables is simple. Let's look at an example in Ruby; let's assume that we currently have secret_api_token defined in our application's code:

secret_api_token = '123abc'

We can remove the token and replace it with an environment variable:

secret_api_token = ENV['SECRET_TOKEN']

In addition to protecting our credentials, using environment variables makes our application more configurable. We'll be able to quickly make configuration changes without having to change code and redeploy.

Note

The terms "configuration variable" and "environment variable" are interchangeable. Heroku usually uses "configuration" due to how tightly the variables are coupled with the state of the application.

How to do it...

Heroku makes it easy to set our application's environment variables through the config command. Let's launch a terminal and navigate to an existing Heroku project to try it out, using the following steps:

1. We can use the config command to see a list of all our existing environment variables:

   $ heroku config
   

2. To view only the value of a specific variable, we can use get:

   $ heroku config:get DATABASE_URL
   

3. To set a new variable, we can use set:

   $ heroku config:set VAR_NAME=var_value
   Setting config vars and restarting load-tester-rails... done, v28
   VAR_NAME: var_value
   

4. Each time we set a config variable, Heroku will restart our application. We can set multiple values at once to avoid multiple restarts:

   $ heroku config:set SECRET=value SECRET2=value
   Setting config vars and restarting load-tester-rails... done, v29
   SECRET: value
   SECRET2: value
   

5. To delete a variable, we use unset:

   $ heroku config:unset SECRET
   Unsetting SECRET and restarting load-tester-rails... done, v30
   

6. If we want, we can delete multiple variables with a single command:

   $ heroku config:unset VAR_NAME SECRET2
   Unsetting VAR_NAME and restarting load-tester-rails... done, v31
   Unsetting SECRET2 and restarting load-tester-rails... done, v32
   

   Note

   Heroku tracks each configuration change as a release. This makes it easy for us to roll back changes if we make a mistake.

How it works…

Environment variables are used on Unix-based operating systems to manage and share configuration information between applications. As they are so common, changing our application to use them does not lock us into deploying only to Heroku.

Heroku stores all of our configuration variables in one central location. Each change to these variables is tracked, and we can view the history by looking through our past releases. When Heroku spins up a new dyno, part of the process is taking all of our configuration settings and setting them as environment variables on the dyno. This is why whenever we make a configuration change, Heroku restarts our dynos.

Note

As configuration variables are such a key part of our Heroku application, any change to them will also be included in our Heroku logs.

See also

• Read about the Twelve-Factor app's rule on configuration at http://12factor.net/config