Poll: Anyone using another E-node as boot-server and file-server?

In Erlang/OTP there is support for loading modules via another Erlang node acting as boot-server and file-server.
This feature has been there for a very long time and it complicates the startup, the file module and the code server (erl_prim_loader).
This functionality might have been very useful and motivated 20 years ago when running on small memory restricted and disk less systems, but I suspect that there in no usage or interest for this functionality now.

The boot server (and remote file server) is activated with the -loader inet and -hosts Hosts flags to the erl command.
I have been working with Erlang for +20 years and have never used this.

We in the OTP team want to remove this functionality , but first I want to ask if someone really is using this. I would be really surprised if that is the case.

Are you using another E-node as boot-server and file-server?
  • Yes (or you intend to)
  • No (or you don’t intend to or don’t mind it being removed)

0 voters


We have been using it and would continue to do so if its there: its useful for small embedded nodes without local storage: We can run the GRiSP executable directly in NOR flash (which is usually too small for storing all the BEAM files) and load the modules from a neighbor node. It would be cool if we can keep using that or have it built in optionally



This code here phoenix_pubsub/cluster.ex at master · phoenixframework/phoenix_pubsub · GitHub uses erl_boot_server. I just want to understand better which part of erl_boot_server might be impacted. For the such code, if OTP team decides to remove erl_boot_server, code like that will stop to work right ?

1 Like