RAILS_MASTER_KEY and per-environment init

rubyonrails-docs
2

This is how I use Rails credentials for a few projects:

  • bin/rails credentials:edit - This contains only the keys for credentials, it’s sort of the template/guide for the rest of the environments. config/master.key and config/credentials.yml.enc are both committed to git as they don’t contain actual secrets. Whenever a new configuration setting is needed it’s always added here first and then once staging and production credentials are ready it’s added to the other credential files.
  • bin/rails credentials:edit -e development - These are credentials specific to the developer’s machine. The reason I started using the default one and development is in the event that developer A has production access to different APIs than developer B. It also just helps with general development and being able to tweak your credentials without having to deal with diffs, diffing credentials is still pretty rough.
  • bin/rails credentials:edit -e staging - Staging only credentials, only config/credentials/staging.yml.enc is committed to git.
  • bin/rails credentials:edit -e production - Production only credentials, only config/credentials/production.yml.enc is committed to git.

.gitignore ends up looking like this:

/config/credentials/development.yml.enc
/config/credentials/*.key

When deploying rails looks for the most specific set of credential files first and then to the most general. In order to not share the your keys across all of your environments you just need to ensure that either ENV['RAILS_MASTER_KEY'] is set in your runtime or config/master.key(or the more specific config/credentials/#{Rails.env}.key) is available and set to that current environment’s key.

You can get an idea of the load order in the PR on this line.

4 Likes