There’s few parts to that complexity: There’s native dependencies of ERTS (erlang) and there’s native dependencies you pull in with libraries you use. Both can have built time and runtime dependencies.
By installing erlang on your target system you basically care for the ERTS part. You can build releases, which do not include ERTS, which will then fallback to the one installed on the system the release is started on. Keep in mind though that the erlang versions afaik need to match much more closely than e.g. java versions when running .jars, but it’s in a grand scale what java does as well. You can also build releases including ERTS for other systems than your local one.
All this doesn’t help for whatever you pull in as additional dependencies, which might run or even build native things. Common examples include the appsignal library, most of the comeonin hashing libraries and more. If they have build time dependencies, then those need to be available wherever you build your release. If they have just runtime dependencies, then your target system needs those to be installed.
The last option is not running a release, but using mix to run a project. This basically means all those above dependencies are shifted to the target machine and stuff needs to get built on there. That’s usually exactly what you don’t want to happen on machines running your service. Not having that additional (often quite big) load is one of the reason for CI and building somewhere else in the first place.
