I’d think that having 2+ BEAM VMs live on the same physical server is going to demonstrate some lags and struggles in parallel workflows because each VM will try to utilize X processor cores (where X equals System.schedulers_online() which can be modified at startup). If each of the VMs is started with schedulers equal to all processor cores, and in loaded parallel workflows, then you’re going to see contention.

But then that applies to each and every other runtime out there.

If you want to split a single VPS or physical server to several BEAM VMs, you better divide the CPU cores fairly between them and utilize OS tools to allocate the right cores to the right BEAM VM.

…Or, as others said, just use a single BEAM VM for all your apps at once – assuming none of them is aggressively modifying other processes’ state or in general being a bad citizen.

Hmm not sure I have heard that. Do you have a link regarding a VM per app? Maybe If the apps are entirely unrelated and this is a data isolation mechanism, sure.

Think many of us would agree the BEAM is more similar to an operating system than a language runtime…

Erlang has the concept of apps. A single Erlang cluster or VM can run probably thousands if not millions of ‘apps’ all effectively sharing system resources. Apps I believe are considered stateful in that BEAM processes are included. This state is what separates an Erlang app, from just module with functions…

For example, you could have n many phoenix endpoints in the same VM as long as they are bound to different OS ports.

I’m sure that’s not 100% accurate but is probably close enough…

Please people smarter than me correct, if I am wrong

If you have BEAM installed on your VPS you can run all your application with this local installation.

But that does not mean that those apps will run in the same runtime, just like if you run two elixir app on two terminal windows on your computer. They do not communicate by default.

So my bet is that that would not change CPU/RAM consumption.

That being said, if you do releases that package their own Erlang runtime, you can have different versions of it, your app is portable so you can change hosting easily once you are set up, etc.