How to Handle Environment Variables in Rails

So you are ready to use your secret credentials for your awesome project but have no idea how to hide them from the world? You’re in the perfect place, then, let’s dive in and see what steps you need to follow to add your environment variables in Rails by using dotenv and, to be more precise dotenv-rails.

Installing dotenv-rails

In your Gemfile add the following line

  gem 'dotenv-rails'

Remember, you need to activate this for your development and test environment, so if you have used the Rails generator, you will see the development/test group near the bottom of your Gemfile. That’s where you need to add your new dotenv-rails gem.

group :development, :test do  
  gem 'dotenv-rails' # add this line
end

Otherwise, you could also add the following code:

gem 'dotenv-rails', groups: [:development, :test]

Adding a .env file

You need to create an .env file now in which you’ll be adding all your environment variables. In your terminal type:

touch .env

Installing dotenv-rails

Let’s now install the new gem that we added to our Gemfile:

bundle install

Using env variables

Suppose we have the following env variable in our .env file

MY_VARIABLE="cool-password-here"

Depending on where you are, you might see the following ways to access your environment variable

value = ENV["MY_VARIABLE"]

or in a YAML file, for example database.yml

<%= ENV.fetch("MY_VARIABLE") %>

Different .env files per environment

There could be cases in which you’ll need to use different .env files per environment. Some common combinations:

.env for all environments

or distinction of .env files per environment

• .env.development
• .env.production
• .env.local

Generate .env template file

Regardless of the names you’ve assigned to your .env files, sharing them in a team environment can pose challenges because you typically can’t include them directly in your repository, correct?

After all, if you did that, then what’s the point, since all your private credentials will be shared?

To avoid similar cases you can use a template .env file that shows your variable keys but NOT their values. To do show type in your terminal

# where .env is an example of a file name, yours maybe different.

dotenv -t .env

By doing so you will see a newly generated env file which will have the same keys as in the .env, but only placeholders as their respective values.

So suppose we have the following .env

MY_DB_PASSWORD="my-actual-db-password"
MY_AUTH_PASSWORD="my-actual-auth-password"

by executing the template command we’ll get the following .env.template file

MY_DB_PASSWORD=MY_DB_PASSWORD
MY_AUTH_PASSWORD=MY_AUTH_PASSWORD

The .env.template file can be shared with your team members with no fear. Afterward, you’ll just need to find a secure way to share the actual env values so they can replace the placeholders and use them instead.

Add .env files to .gitignore

Some combinations for ignoring the sensitive .env files

Sensitive data on .env – .env.template for placeholder variables

.env

We are just ignoring .env file here

Sensitive data on .env.* files – .env.template for placeholder variables

In case we have more than one .env files, e.g .env.local and .env.test and we want to ignore these but not the template file we can type:

.env*
!.env.template

Try it out and see how it goes before committing, it’s always better to validate your scenarios.

⚠️ Remember to add your sensitive files on .gitignore and not commit them! ⚠️

For more configuration settings check the dotenv GitHub page.