The doc covers it well: Why releases?

I really like being able to attach iex to the running app and use tools like recon or observer_cli, personally.

Yeah I missed the mix docs , actually this is probably the biggest thing:

Self-contained. A release does not require the source code to be included in your production artifacts. All of the code is precompiled and packaged. Releases do not even require Erlang or Elixir in your servers, as it includes the Erlang VM and its runtime by default. Furthermore, both Erlang and Elixir standard libraries are stripped to bring only the parts you are actually using.

Meaning your docker image can be even slimmer. Explains why some of the guides I was looking at use a “non-elixir” image after the build stage.

Hi

If you run containerised systems, you do not hot load. Instead you spin up new containers and switch traffic over. Hot loading is for hosts that must stay up without moving traffic but nowadays that is usually the role of the load balancer.

Releases can still be hot loaded if built with Distillery AFAIK. But it is not easy. https://hexdocs.pm/distillery/upgrades-and-downgrades

One more benefit of releases is that you can have artefacts that are independent from the source. Maybe your source contains C code or some other external stuff that needs to be built. After the release is done you can copy it to another machine without bringing the C compiler and development headers with you. This minimises the exposed surface.

Lastly remember to run Docker containers, the images must be loaded to hosts and a smaller image will load faster. This means a rolling deployment that uses a smaller image completes quicker.

Currently I use a slim Debian image as the baseline, install Erlang from either ESL packages or GitHub, and Elixir from either source or precompiled archives from GitHub. Therefore the same Dockerfile can be configured to either build the system based on a stable set of runtimes or the latest versions of everything.