D4no0
How you manage configuration of secrets in elixir projects?
I think it was discussed before not only a single time, however I was unable to find any relevant information using search on elixirforum.
Let’s say we talk about projects containing some kind of secret values, both present for deployed environments and dev. Here are a few ways I’ve usually seen them being set:
- Hardcoded for dev in form of a file that is gitignored, for example:
dev.secrets.exs, for deployed environments just fetched as a env variable; - Similar to 1st approach in terms of structure, but generated semi-automatically using a mix task or something similar;
- Everything set as a environment variable in
runtime.exsand using something likedirenvto manage them per-project.
I specifically would like to know more about third option, as it seems that overall it makes the configuration more homogeneous in theory. I’ve seen it being implemented in a few recent projects I had to work with and I didn’t like it very much, but once again this might be an issue of implementation.
Any thoughts on this, what is your personal preference?
Most Liked
cevado
what I usually do is somewhat the third option but not exactly what you described.
in dev.exs I use the same envvars as runtime.exs but with sensible defaults(like defaulting postgres to localhost, etc). In runtime.exs i check if the apps is compiled for mix env dev or prod, if it’s prod we change to use the envvars but without the defaults, after all we want it to fail if the value is not set.
i’ve never used something like direnv in production settings, just for dev/local. in my last job we used hashicorp’s vault service, it’s quite handy and having versioning in envvars is great. ![]()
but in general i’d go with the thing that fits better your deployment system.
dimitarvp
While the project is small, env vars and System.get_env! in runtime.exs is quite enough. (And $MIX_ENV.secret.exs as you said, that complements this model nicely.)
The moment you find yourself juggling 15+ env vars and having to parse and validate their values is the moment you should drop all of it and just use Vapor. It’s easy to cringe at its “enterprise”-y offering but I used it in two projects and once you get over the initial learning curve (where you declare the exact location of all your configurable pieces) it just vanishes from view and does its job well. We used it to get data from env vars and YAML files. But I know it can do more than that.
fuelen
I use the 3rd option + confispex library. The idea is simple - you describe a schema for the ENV variables and then just use Confispex.get("MY_VAR") instead of System.get_env("MY_VAR") in runtime.exs. I’ve built this library when our configuration was really hard to manage. Currently, our the biggest project has a config schema with ~260 defined ENV variables. Works pretty well and totally manageable.
Vapor was created before runtime.exs was introduced in Elixir, thus it is more complex.
Popular in Discussions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









