You can load extensions in real-time without issue. What I’ve always done is just add the compiled applications to the same library release (so they get loaded, or you can explicitly load from a path too, I’ve done that before as well), then just set the module entrypoint for it in a configuration (application environment), or if it’s a running system then just tell it to load it straight and it can register itself in and is immediately loaded and doing its work.

As long as it’s in the load module path (which you can alter) and ‘something’ loads the entry module for the plugin (configuration files are great! or a database or whatever to get the names) then it all just works. You could even scan all beam files in the module paths for what implements a certain behaviour and load those as well (dynamic loading! I’ve done that before as well, though I like configs a bit more in ‘most’ cases, more control).

Just have to make sure the plugin is compiled with the same version as everything else, a simple build API fixes that up.

Or you can even load plugins as their own nodes that connect to the main system and register themselves in too, that’s fully under the plugin control then, no dynamic system needed.

You can of course compile on demand, but you need to be sure to include the compiler libraries, and you wn’t have mix available unless you include that as well, which will generate how code can be generated as it won’t think it’s a full release then.

But yeah, compiled beam file’s are platform independent, but they are dependent on the OTP version (and to a lesser extent the Elixir version) that they are compiled with.