Now, anywhere in your application, you can access APP_CONFIG[:admin_password], along with all your other data. (Note that since the initializer includes ERB.new, your YAML file can contain ERB markup.)

Well, I'm using Heroku and they allow you to set some ENV variables for things like passwords that you don't want checked into source control. I'm trying to figure out the best thing to do on my dev machine. And yes, I am trying to use the data inside my app.
–
LanFeb 6 '11 at 12:44

The answer has been updated to match your new details.
–
BinaryMuseFeb 6 '11 at 18:54

exactly what i was looking for! (and more :) thanks!
–
LanFeb 7 '11 at 2:35

Glad to hear it! If you feel an answer is correct, you should mark it by checking the check mark next to the question. It will earn you and the answerer reputation and also help people who find this question in the future locate the correct answer.
–
BinaryMuseFeb 7 '11 at 17:48

Oh yeah, I'm a new user so it's making me wait 19 hours before I can check it. Still 3 more hours to go :) But thank you for all your help! Actually, if you would edit your answer in removing the dev_environment.rb code and replacing it with mine, i'd gladly mark your answer which is much more thorough.
–
LanFeb 8 '11 at 0:56

As well, add the following lines to /config/environment.rb, between the require line, and the Application.initialize line:

# Load the app's custom environment variables here, so that they are loaded before environments/*.rb
app_environment_variables = File.join(Rails.root, 'config', 'app_environment_variables.rb')
load(app_environment_variables) if File.exists?(app_environment_variables)

That's it!

As the comment above says, by doing this you will be loading your environment variables before environments/*.rb, which means that you will be able to refer to your variables inside those files (e.g. environments/production.rb). This is a great advantage over putting your environment variables file inside /config/initializers/.

Inside app_environment_variables.rb there's no need to distinguish environments as far as development or production because you will never commit this file into your source code management system, hence it is for the development context by default. But if you need to set something special for the test environment (or for occasions when you test production mode locally), just add a conditional block below all the other variables:

Note that inside app_environment_variables.rb you must specify booleans and numbers as strings (e.g. ENV['SEND_MAIL'] = 'false' not just false, and ENV['TIMEOUT'] = '30' not just 30), otherwise you will get the errors can't convert false into String and can't convert Fixnum into String, respectively.

Storing and sharing sensitive information

The final knot to tie is: how to share this sensitive information with your clients and/or partners? For the purpose of business continuity (i.e. when you get hit by a falling star, how will your clients and/or partners resume full operations of the site?), your clients and/or partners need to know all the credentials required by your app. Emailing/Skyping these things around is insecure and leads to disarray. Storing it in shared Google Docs is not bad (if everyone uses https), but I prefer a dedicated cloud-based solution for this, called Strongbox (https://www.strongbox.io/). With it, I create a new "box" for every app I am responsible for, and within each box, a new "item" for each service I sign up for (Heroku, Amazon, Google/Gmail, Google Apps etc.). As well, I create an "item" called "app environment variables", in which I create just one field and paste all the environment variables into it - I just copy/paste them in. Then I share the box with my clients and/or dev partners. Note that it is possible for you to start the box, set it all up, and then change box ownership (normally to your clients, who will pay for it).

Hence, I use Foreman to run my apps locally, but I don't use its .env file for loading environment variables; rather I use Foreman in conjunction with the /config/app_environment_variables.rb approach described above.

I like this solution as I wanted to be sure that sensitive settings (API keys etc) are adequately protected in a keystore, instead of in clear text and not bundled with the Git repository. Thanks.
–
Rori StumpfOct 4 '12 at 17:14

Glad you found out why it wasn't working! I personally like to save config/application.rb and config/environments/*.rb for setting up the Rails environment and using other methods to set up my application environment, but that certainly doesn't mean it's the only way (or even the "right" way :)
–
BinaryMuseFeb 8 '11 at 17:09

I was thrown off a little because I was trying to set things differently between production and development. But now I completely agree with you! Thanks for not only answering my original question but helping me understand the rails app structure better!
–
LanFeb 9 '11 at 1:39

The system environment and rails' environment are different things. ENV let's you work with the rails' environment, but if what you want to do is to change the system's environment in runtime you can just surround the command with backticks.

This doesn't work since backticks spawn a subshell and variables you set in the subshell can't affect the environment of the parent.
–
AndrewFAug 5 '13 at 0:41

Nope, it does work. The answer, as clearly explained, is not targeted at the environment of the parent. There are perfectly good answers which instruct on how to do that.
–
goncalossilvaAug 5 '13 at 7:35