As mentioned above, you eliminate the need for all “global configuration”, which IMO, is less than ideal (ignoring the fact that mix config is global anyways ), by simply creating apps for those “global requirements” - ie. logging and metrics. My umbrella apps usually include both a logging and metrics app. These apps will do all the setup required for their domain. Any app that requires logging or metrics simply has to add [{:logging, in_umbrella: true}, {:metrics, in_umbrella: true}] to their deps. If your requirements for logging or metrics ever expand - you have an easy point in which to work on it. This becomes more pronounced if you ever need to add “sinks” for either logging or metrics that require runtime config. Having an app for these makes it very clear where that code would go.

Keeps things focused. Works for me. Might not for others…

The only upside I see to split up config is that it’s clearer which parts of it are shared and which parts are only needed by a single application. One place where this is beneficial is when you want to move apps into/out of the umbrella. But otherwise I’d agree it’s prone to cause pain, as when running the umbrella there can only ever be one application environment.

I do precise opposite. In apps/*/config.exs I only have:

use Mix.Config
import_config Path.join("..", "..", "..", "config", "config.exs")

and only have one instance of dev.exs, test.exs and prod.exs per whole project, instead of splitting this among multiple files.

It’s easier when the project becomes big to have the configuration consolidated in my opinion.