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?
2
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.
3
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.