What do you use among those 2 for storing your secret keys and passwords? Are they more or less equal?
I think it depends on how you deploy your app. We use Heroku so env variables are the best solution for us.
The prod.secret.exs files do have the problem that they’re compile time only. So you cannot change the values after compilation / creating a release.
I find that
prod.secret.exs is a real anti-pattern. Putting configuration that is specific to a particular environment/deployment in your code is generally not a good idea.
Deleting prod.secret.exs is always the first thing I do when starting a Elixir + Phoenix project the env variables approach is more standard, and you can reuse it for your frontend if you use e.g. webpack’s EnvironmentPlugin.
This is a huge thing to notice about mix config! Always keep this in mind!
I prefer env variables, so you don’t have to make another release just for some changes in
What I wish is if there was an easy way to, say, get database connection inform from a database (easy) then use information in the database to populate the rest of the values (easy with shell script, but that is not… right… ^.^;) before things like the endpoint load.
If you’re deploying on EC2 you can give your EC2 instance a role, then use role based security to protect environmental secrets and other bootstrapping information in S3.
As part of your app, have it take an env.props at startup. Point this to a local file during development and a remote url in formal environments.
I’ve found this works pretty well.
If you’re deploying on EC2 you can give your EC2 instance a role, then use
role based security to protect environmental secrets and other bootstrapping
information in S3.
Or use AWS Parameter Store:
We ended up using Vault (which the new version has cloud auto-unseal) and we forked VaultEx https://github.com/brixen/vaultex
I don’t have the code anymore, but we treated the application config like a write-through cache. If a value didn’t already exist, we could look it up in