to add on top of Michał’s answer, v1.3.0-rc.0 actually ships with two new tasks [1], so you can do the following:

mix new my_umbrella --umbrella
cd my_umbrella
mix phx.new.ecto myapp
mix phx.new.web myapp_web

and they’ll generate the child apps as if they were generated with mix phx.new --umbrella.

Please note these tasks are still private (no @shortdoc hence they don’t show up in mix help), I think they’re still under development so I wouldn’t count on them being present in the final release just yet.

[1] phoenix/installer/lib/mix/tasks at v1.3.0-rc.0 · phoenixframework/phoenix · GitHub

Single applications and umbrellas both have their own merits and pros/cons. We don’t generate an umbrella by default for Phoenix because it may be overkill and it introduces more decisions and overhead for folks to know. Umbrellas exist to house multiple isolated applications under a single code repo, that can be started and stopped as a whole or independently. This is a great for a number of reasons, but also introduces complexity depending on your needs. For example, for the mix phx.new --umbrella case you now have three places to configure things, three places to add new deps, three mix.exs files, etc. Our goal w/ the new structure for single applications where you are focusing on boundaries and isolation is the moment you need to extract the web interface or other parts of your single app to a separate umbrella app, it’s just a matter of cd apps/ && mix new whatever then moving the code around. Little else should need refactored provided your boundaries are well established. Does that help?

Also, if you want a regular phoenix structure in an umbrella you can do:

mix new my_umbrella --umbrella
cd my_umbrella/apps
mix phx.new web_app