Storing secrets in the environment is an excellent idea. Heroku highly encourages this approach, and it makes it much easier to give different levels of access to code and secure data. It also makes it easier to avoid accidentally copying secrets across environments (i.e. using a production API key in staging or dev).

If you're not familiar with the practice, I'd encourage you to read the "twelve-factor" section on configuration: http://www.12factor.net/config . The advice applies even if you're not using Heroku for hosting.

It did lead to an interesting exploit though - http://titanous.com/posts/vulnerabilities-in-heroku-build-sy...

that vulnerability still would have applied if config directives were stored in files

I like using env vars for everything that might change across environment. Should be able to deploy code to a properly configured environment and have it work with zero changes.

And those can easily be put into their own repo.

Yup, this is our approach. We have a 'config' repo that contains secrets together with automated scripts for applying new settings to a named environment, and checking that an environment matches what is in version control. This repo is separate from source code, and has different permissions. (Disclaimer: we do host our site on Heroku, so this approach is pretty baked in.)

To be honest, not having secrets under some kind of source control seems like a bad idea, as you just know that the reality is that they will be in an untracked spreadsheet somewhere.