Prod.secret.exs or env. variables?

Questions / Help
1

What do you use among those 2 for storing your secret keys and passwords? Are they more or less equal?

2 Likes
2

I think it depends on how you deploy your app. We use Heroku so env variables are the best solution for us.

1 Like
3

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.

2 Likes
4

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.

4 Likes
5

Deleting prod.secret.exs is always the first thing I do when starting a Elixir + Phoenix project :stuck_out_tongue: the env variables approach is more standard, and you can reuse it for your frontend if you use e.g. webpack’s EnvironmentPlugin.

1 Like
6

This is a huge thing to notice about mix config! Always keep this in mind!

2 Likes
8

I prefer env variables, so you don’t have to make another release just for some changes in prod.secret.exs.

1 Like
9

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.

10

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.

11

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:

12

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 :FILE, :ENV or :VAULT.

1 Like