vkryukov
Hi,
I would appreciate advice on the best practice for organizing several interconnected Elixir apps. I suspect that what I need is an umbrella project, but I would like to confirm this with the community.
I have three apps (1 is in active development, 3 I’m just starting, 2 is planned):
- A command-line app with a database that I plan to distribute in binary form to customers
- A premium app that implements additional functionality and a web UI
- An internal app (development and debugging tools, also with a web UI)
Based on my understanding of umbrella projects, this would be the right solution if implemented like this:
my_umbrella
apps/my_app # command-line app
apps/my_app_web # web UI + premium features
apps/my_dev_app # internal development tools
In this scenario, my_app_web and my_dev_app will both have my_app as a dependency, giving them access to all the core functionality, Ash resources, and database access. At the same time, I can distribute the first two apps separately, while the third internal app will never be distributed outside our team.
Is this the right approach? Are there any things I should be aware of, or is everything fairly straightforward as described in the official docs?
Many thanks!
Victor
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Master modern tools, write cleaner code, and tackle real-world challenges with Manning books, videos, and courses. Start building today.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #ai
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
al2o3cr
Seems like a good use case - the compiler will ensure that no references to code in
my_dev_appsneak into the other two.jeremy.owensboggs
Umbrella apps are intended to be distributed as a unit. I would not recommend an umbrella app for this purpose. I’m under the impression that umbrella apps get loaded all together, and that references can creep into apps under the same umbrella in ways that those references can’t if they are in independent projects.
If my_dev_app is not intended to be distributed with my_app & my_app_web, then I would strongly recommend that it is kept separate.
I have been a part of several large umbrella projects, and In general I have found over time that all of these projects generally get flattened - and if not fully turned into individual projects, that the core components get merged into a single project, and that only other apps in the umbrella are custom libraries that are under active development.
gregvaughn
I wish we could remove this misunderstanding about umbrella projects (not apps). One umbrella project can map to N releases. Releases are the deployment unit. The umbrella represents a way to organize the code “at rest” on the filesystem before releases are built.
If they’re not intended to be distributed together then the two (or more) release definitions should not include them both.