How's everyone handling overrides with Rails credentials?

In the situation where you’re sharing credentials with Rails credentials and you want to override or layer credentials, how do you typically set that up?

To be more specific, when working locally and you want to set your specific airtable_api_key(example credential) that belongs to you within a sandbox API environment how are you setting that? Developer A needs airtable_api_key: abc and developer B needs airtable_api_key: xyz. Normally you’d just store these credentials in either the default set of credentials or a development set of credentials but this is going to update your git history for that encrypted credentials file with each developer needing their specific API key and then you have to ditch those changes before committing. You can’t configure the default credentials and development, Rails will just pick the more specific one which would be development unless you’re running tests.

For example:

Shared:

host_url: localhost:3000

Developer A:

airtable_api_key: abc

Developer B:

host_url: app.test:3000
airtable_api_key: xyz

To workaround this I typically use dotenv locally but just wanted to see how others are handling this. dotenv allows you to layer your configuration so you can set your specific local development credentials in .env.development.local and then .env.development has the rest of the defaults.

You could of course have an initializer that loads .env or some git ignored file and then sets Rails.application.credentials.airtable_api_key but I figured there’s a cleaner way to do that.

Rails credentials do support separate environments, but apparently intentionally there is no “merging” feature.

Supposing developers have local DBs, could they store their specific credentials in DB (encrypted)?

@sdubois Yep, definitely supports multiple environments. I typically have a development, staging, and production set of credentials but yes I’m referring to merging/inheritance/layering, etc. Insightful thread on credentials, thank you for pointing me to that. Which I suppose leaves everyone that has a use case for that to utilize dotenv or some other initialization approach locally.

Sorry for the late reply; not sure if you are still around.

For us, we have

-include development.local.mk

in our main Makefile. And

/development.local.mk

in .gitignore.

Each dev can export any variables there, and we merge them with the rest of the credentials when used.