1

I have a few projects that use various webservices e.g. DropBox, AWS. For managing private information I use bash_profile which works great with heroku that uses env variables to manages secret informations. The problem is my bash_profile is growing significantly (HEROKU_ADD_ON_1 HEROKU_ADD_ON_2 etc.) and it bit me today.

What's the better way?

  • Please elaborate. How did it bite you? What metric would you like to optimize so that your workflow works for you again? – Kilian Foth Apr 28 '14 at 13:35
  • Basically, I used the wrong key, because there were too many from a single provider in my bash_profile. I'd like to remove the global state and single per computer config of bash_profile, but don't want to check-in anything to source control. In other words something virtualenv for secret information. – Lukasz Madon Apr 28 '14 at 13:49
1

I've typically managed all kinds of project secrets via configuration files (often environment-specific) and then never commit these to source control. The format of these files can be whatever you want / whatever works well: xml, yaml, json, etc. Then the code is responsible for reading the values out of the config file.

Sometimes it is annoying that these values aren't in source control (makes deployment a little more difficult, for example), but it sounds like you are managing the values separately anyway, so that shouldn't add much overhead.

Edit: I'm not very familiar with Heroku, so I just answered the question generally. But after looking into it more, I can see where this could be a pain to manage.

It sounds like you already manage the config vars via the bash_profile -- that's good because you'll want to have a "source of record" document where you can look at and change these values.

Beyond that, it sounds like naming is going to be the next most important thing. HEROKU_ADD_ON_1 isn't very descriptive. But DROPBOX_API_KEY or AWS_S3_BUCKET_KEY give a better idea of what the variable is. And you can distinguish between keys from the same provider through good naming too: FEATURE_A_AWS_KEY vs FEATURE_B_AWS_KEY.

  • That's the problem with heroku. Everything goes through git. – Lukasz Madon Apr 29 '14 at 8:50
  • If everything goes through git, then how are you managing the existing bash_profile? Is it also in git or are you doing something outside that process? If the latter, why not manage configuration outside as well? – Allan Apr 29 '14 at 19:31
  • In my local machine I got everything in bash_profile. For heroku I use heroku config:set API_KEY=123231... – Lukasz Madon Apr 30 '14 at 8:47
0

If you are using ruby or a ruby based framework, you could look at using a project such as dotenv which allows you to manage these environment variables inside of a single .env file (which you need to git ignore) within your code repository instead of using your system wide files.

If you like the way it handles it for local development, there is a sister project that handles it for production or staging environments also.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.