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.

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.

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.