Thanks for the clarification.

My view is that if you need multiple apps that have to be started independently with different environments, then an umbrella app is probably not the right idea

I think there are different use cases for umbrella apps, but to me the typical one is when you have a number of apps depending on each other and that have to be started as a whole. In this case it makes sense and it’s more convenient to have a single configuration and a single environment to start the whole application bundle (by a similar token, when you install a hex package the application in the package also shares the same configuration with your main app).

Creating an umbrella app and then splitting the start-up and configuration logic feels like an anti-pattern to me - probably better to split the apps into multiple stand-alone ones which you can then start independently.

I get what you mean, maybe some background:

In my case the apps are closely coupled in the sense that, code wise, they are all using one central “core”-app that is also in the umbrella. I want to ensure that all apps are kept aligned with each other, running their tests on the same “core” app code.

Originally, I had only one app that managed everything (-> one single supervision tree). But I want the API app, for example, to run really stable, and be completely independent of data aggregators that harvest external resource over the net and are more prone to errors.

So I moved to an umbrella project (-> API has now its own supervision tree).

I could of course move further and split everything up into separate repositories, but then I have more hassle keeping everything aligned and tested. I’d rather have one separate runtime configuration for the time being.