Yup, config handling is different because of how it is generated. It’s nothing inherent, though, if you look at the config files (and the config_path: "../../config" setting in mix.exs), you’ll see you can easily change how it works to have a per-app config.

Biggest difference lies in how the umbrella apps are generated, and in fact their configs. So in umbrella project all the relevant config files from all the apps will be loaded, i.e. config is shared by default.

When you build the project from multiple independent apps, you can either do that, or not. For example, I can have separate config/test.exs for each app, so I can test those in isolation (and even in parallel), mock some stuff in ui app and hit the database in db app (or other way around, as I please).

So the biggest advantage of not having umbrella project is that you don’t share the same config across all apps and it’s up to you how you configure it all.

@hubertlepicki Can you elaborate a bit on how umbrella project is making it harder to deploy your applications separately?

In my experience there’s no much difference between keeping the applications as an umbrella or as completely different projects. If you keep respect the boundaries between the applications, I think the only difference in that umbrella project lets you run mix tasks for everything at once which is really convenient for running tests.

One problem we had with umbrellas is that because they are compiled into one directory, they allow you to call functions from other applications without explicitly declaring dependencies in the mix.exs file. This is a big problem because you may even create a circular dependencies if you aren’t careful. To prevent this, we decided to build and test every application separately. Fortunately, we can do this on CI.

I guess the key is to keep the applications separated and decoupled. The way you do it - may it be an umbrella project or a set of independent applications in separate repositories - is not much of a difference.