Technically you can. The escript api takes an archive of files where you can include priv directories. This is how rebar3 works and rebar3 escriptize supports this as an option, escript_incl_extra.

Also, one thing not mention that releases provide over escripts is the ability to bundle ERTS. You can not create a self-contained escript but must have Erlang installed on the system you are deploying to.

Oh, one last thing. If you don’t have to compile the code for your escript on the same arch as where you are running it then you don’t for a release either.

Releases do not have to contain ERTS, so a user who is fine with having the Erlang runtime installed on the target host only has to compile any other potential native code for that host. There must be no native code in the project so no need to build the release on a particular architecture and set of system libraries, simply leave out ERTS.

All that to say, nothing about a release is unique in requiring compilation on the target host that doesn’t also apply to running the project any other way because you do not have to bundle ERTS into the release.

A release doesn’t require neither erlang nor elixir to be installed on the target machine as long as you either pack ERTS (the default) or the machine has ERTS accessible, it does require that the release be assembled on the same target architecture indeed and to assemble the release you do need erlang and elixir, but you can do that with docker easily mimicking wtv targets you wish.

This would be simple to implement if restricted to only fetching OTP for that architecture. The issue is what is done for NIFs, ports, etc that are in the project? That is outside the scope of a release task and would require all the different compiler tasks, like zigler, rustler, and general makefiles and rebar3’s pc plugin have a common interface for assigning the architecture and each to support cross compiling.

But I’d also point out that for many people it doesn’t require docker/vm – except for those who have a hard requirement on deploying local code directly to a target and don’t run on the same env as the target – because usually CI is involved before deploying were the release can be built and either directly deployed or pushed to some storage to be deployed later.

A mix release that doesn’t include the Erlang VM will have the exact same properties as an escript. You only need the target compilation if you are bundling the VM and if you need to bundle NIFs (not supported by escripts IIRC).

I mean, we also include them, but IIRC it is not easy to read them. You would need to use an special API for so?