The thinking behind that is expanded on here: http://weblog.rubyonrails.org/2017/2/23/Rails-5-1-beta1/ http://weblog.rubyonrails.org/2017/2/23/Rails-5-1-beta1/

The thinking behind that is expanded on here: http://weblog.rubyonrails.org/2017/2/23/Rails-5-1-beta1/ http://weblog.rubyonrails.org/2017/2/23/Rails-5-1-beta1/ > Encrypted secrets > If you’re checking production passwords, API keys, and other secrets undisguised into your revision control system, you’re doing it wrong. That’s not safe and you should stop it! Now that’s an easy prescription, but without a coherent answer to what you should do instead, it’s also not that helpful. > People have long been loading up the ENV to store these secrets or used a variety of other solutions. There are all sorts of trade-offs and drawbacks to the ENV-model, not least of which that you still need to store those secrets for real somewhere else. > Inspired by Ara T. Howard’s sekrets gem, we’ve built encrypted secrets management into Rails 5.1. You can setup a new encrypted secrets file with bin/rails secrets:setup. That’ll generate a master key you’ll store outside of the repository, but allow you to commit the actual production secrets to your revision control. They’re then decrypted in production either through an injected key file or through RAILS_MASTER_KEY in the ENV.