← Back to Upcase

How do you handle secret credentials in Ruby On Rails?

(Mihhail Sidorin) #1

There is many ways how to store secret credentials like password to S3 bucket or credentials to secret API. What is your best practice?

(Geoff Harcourt) #2

If you’re using Rails 4.1, you can store these items in environment variables and then reference them in secrets.yml.

In any other version of Rails (this also works in 4.1), the best way to do it is to have the credentials stored in a .env file, and then have the dotenv and dotenv-rails gems in your development and test environments. Those gems load the configured variables in your local file just for your application, which is great if you hack on more than one app. Environment variables can be useful for other parts of your configuration that aren’t passwords as well.

Heroku has a great config part of the toolbelt for pushing up and pulling down environment variables.

The most important part of whatever solution you use here is to NEVER CHECK THE ACTUAL PASSWORDS IN TO VERSION CONTROL. Your git history should never contain passwords or other sensitive credentials. If you accidentally do check passwords or other credentials into git, if you do a little Googling you can find instructions for how to comb through your history and remove the passwords. The procedure does completely rewrite your commit history in the process, so any collaborators of yours will have to force-pull to get their repositories back in sync.

Rails 4.1 secrets.yml on Heroku
(Geoff Harcourt) #3

One more point I forgot: the formats of secrets.yml (Yaml) and .env (text, key=value on each line) are different!

(Samnang Chhun) #4

I got excited for secrets.yml in Rails 4.1, but so far I use https://github.com/laserlemon/figaro for most of my apps to manage configuration. On their Readme page, they also lists their similarities and differences to other options secrets.yml and dotenv.

(Geoff Harcourt) #5

Figaro seems like a nicer option than dotenv prior to Rails 4.1 if you want Yaml configuration. It looks like Rails sort of stole a lot of Figaro’s thunder with 4.1.

Despite its uglier syntax, one last dotenv advantage is that you can copy environment configuration up and down using heroku config:push and heroku config:pull. I’m sure someone will write a mechanism to do this with Yaml in the future, but I haven’t found it yet.

(Aaron Mc Adam) #6

@geoffharcourt funnily enough, I’ve moved to dotenv from Figaro as the YAML format was just adding noise

(Geoff Harcourt) #7

@aaronmcadam, I’d also rather use dotenv, but being able to have separate variables for dev and test looks like a major plus of both FIigaro and the Rails 4.1 secrets.yml approaches.

(Lenart Rudel) #8

Using separate variables for different (rails) environments in dotenv was possible in 0.10.0 but was since moved to a separate gem dotenv-deployment. See gem’s documentation for details.

(Dan Weaver) #9

Some good notes comparing Figaro, dotenv, and secrets.yml are available on the Figaro repo page: