config.exs + prod.exs will be evaluated at built time and at releases startup releases.exs will be evaluated and merged into the app env. Therefore releases.exs trumps config.exs and everything imported from there.
LostKobrakai
0
Exadra37
As I said you add it first in releases.exs and then you just add it in dev.exs if you need to override it.
ALERT: Rant ahead 
The Elixir way of using configuration was never good, and still continues to be far away from being a nice experience for new developers… It’s just not explicit and/or intuitive.
In my opinion would have been much better if the commonly .env file used across so many stacks had been officially adopted in Elixir.
That being said I will play with just using the releases file and configure everything through a .env file, and this is more easy for me because I use Docker.
0
Nicd
In the next version of Elixir, there will be a config/runtime.exs that is like config/releases.exs, but will be evaluated both in release and in dev. This will mean you can finally get unified configs for release and dev. 
More info: elixir/CHANGELOG.md at main · elixir-lang/elixir · GitHub
3
LostKobrakai
To me .env was never a great experience for development. ENV variables are often unnecessarily verbose and type conversion makes handling them even more a pain. Considering in production I only override like a handful of the lines I like having releases.exs be the only place I need to deal with that. Most of the config I have is making libraries work a certain way, which is project specific, maybe mix env specific, but certainly not runtime specific.
1
Exadra37
I am in the opposite side for sure. For me was the best idea across the several stacks I have worked with until now. Cannot be more simple and universal
0