I’m pretty sure this is the correct advice:

As a thought experiment, there might be a convoluted and risky way. I’m not remotely suggesting you actually do this, but I’d be interested to hear from knowledgeable folk here about what I have right here (& not).

You can add dependencies at runtime using Mix.install (as commonly used in LiveBook).

But Mix.install can’t be used within a Mix project (it works by dynamically creating a new one). So you’d need to do something like host and run elixir scripts, maybe similarly to LiveBook (I don’t know how that works). But the packages installed within those scripts wouldn’t be available to regular Phoenix projects, which obviates the point. You could perhaps work around that by running scripts which each set up their own Phoenix-like pipeline (eg. as a starting point example phoenix.exs · GitHub). Or (more realistically perhaps) create a custom plugin API allowing the CMS’s Phoenix process to call on these added scripts functionality via message passing.

[sorry @dimitarvp , didn’t mean to step on your toes]

The beam has means to load code at runtime. But that’s all it does: Load arbitrary code.

All the additional requirements like replacing running processes, dependency management and such are afaik still handled at compile time when building the release to update to. That’s the data in the appup file mentioned in places.

These points may not matter for plugins on a CMS. At best files loaded are completely independent of each other and have no compile time dependencies to each other, but there’s nothing in elixir or on the beam to enforce that at runtime.

You might have security problems if You allow users to load random modules.