Always use Releases

I agree. I believe that OTP releases for systems (aka services that need to run continuously), and escripts for CLI tools are the way to go. Maybe there are some special cases, but can’t think of any.

I wouldn’t say that eager loading is the primary value, although it depends on the use case. I suspect that many systems are not that highly loaded for that to make a difference.

I do think that the defaults you mention, which allows remote logging and start the system as the node (so you can remote observe it) are more important.

But above all, I like the self-contained, isolated nature of the release. You won’t pickup some unexpected module from somewhere else (e.g. mix app is not included in OTP release, so less chances of invoking Mix.env at runtime), and you can easily run multiple different systems (services) with different versions of Elixir/Erlang.

I also agree that the cost is marginal. But even if it takes longer to properly setup your own build and deployment, it’s a one-off cost. Pay the price once, reap the benefits many times

I’ve not used releases by now, but from what I’ve read about it in slack or otherwise online it seems to involve a lot of quirks and setup to get it to work properly. Installing elixir and using mix can be done by copy pasting a few (well documented) lines of code in your ssh session and the app is running. Comparing that to potentially fiddling around with building the release, dealing with any issues coming up and having to find solutions to those issues it doesn’t sound so marginal. Especially thinking of someone just coming into the language.

I still feel like releases are the better option long term and if releases are working for someone there’s probably no reason at all for mix run, but for me – coming from the upload-file-and-done php world – it feels nice to also have the option to skip all the ceremony. Even if it might be just for the quick and simple success feeling for novices in elixir.

How does the Elixir release process compare to the erlang release process? I recall while reading Learn you some Erlang for great good that the general vibe of putting together a release was “this is exceptionally complex and you should only do this if you really really need the hotloading capabilities”. I think this picture summed it up nicely.

I’m still a bit of a novice to this side of elixir and erlang, so can anyone speak to how the release process compares between these two languages?

I haven’t done it in a while but what OP says is correct. It’s basically just mix release and you’re done.

The vibe you’re recalling from LYSE if I recall correctly has more to do with appups/hot upgrades - they should be generally avoided unless you really need the functionality and are prepared to deal with the complexity. Releases are very easy to build and use, and I can’t imagine not using them for deployment. Erlang suffered from poor tooling on that front for a long time, but that’s not been the case for probably 5 years or more.

Replying to both of these sentiments, I feel like a lot of the weirdness has been ironed out. Distillery is really easy to use at this point. Even the whole environment variables thing is nice and simple with the support of config :foo, "%{SOME_ENV_VAR}".

I have used releases for one production environment now; a webshop that does not need to be hot-reloaded, but I set up everything so that it is, to ensure that I get a feeling for how it goes.

I agree that using a release seems to be better than the mix run --no-halt. Until now I’ve created every release on my local machine, which meant that moving it to the external server was always somewhat of an issue; a release is a quite large binary file, and as every release is put in its own folder, tools like rsync cannot leverage speedups as you need to move the whole file instead of a diff. So building locally also has a very clear drawback. (Its main advantage is of course that setting up a server to run your app on is trivial, as everything is contained in the release).

What I am wondering: Isn’t the release building a rather heavy procedure (as in, needing a lot of memory and CPU power)? Would this not make the production environment slower during that time?

In my opinion, nobody should be building releases on their production host - they shouldn’t even have build tools installed on that host. You build your releases on your build host, and push those to production and then pull the trigger on rolling it out when you’re ready. This can be entirely automated, automated with some manual intervention, or done entirely manually.

I’ve set up and used different approaches depending on what I’m working on - with Docker/Kubernetes, there were dedicated hosts in the cluster which handled builds, and transfers of those images to the production hosts were super fast because they were colocated. Similarly, with a more traditional setup, we used Jenkins to build releases, and scp them to staging/production hosts and unpack them. My current project, we’re actually shipping virtual machines, so it’s an entirely different situation, but we’re still using releases (which are ultimately installed on the host via rpms).

The release tarballs are certainly a bit fat if you are including ERTS, but if your build and prod hosts are the same, then you don’t need to do that, and can omit ERTS, which is by far the bulk of the baggage the tarball carries.

I agree with you completely, and I think that releases are the path to follow when you have multiple servers and/or you can dedicate time to create your build workflow.

First of all, you need a build environment that suits your needs, which ends up with an extra machine / docker container / something else.

Also, you need to take care of not using Mix.env anywhere inside your production code and including all libraries you are using on the release (i have seen cases of a library that has no application and isn’t included by default on the releases) or your app may crash.

On the other side, you can use docker images with your Erlang version, pre-fetched libraries, pre-compiled application and assets (if you have) for production and just run it using mix, which give you a mostly-accurate snapshot of your software at that point.

Problems of using containers for this? That you will be storing big container images instead of small tarballs. But on the other hand the deployment is easier to maintain and enough for many cases if you don’t run a fail-proof software (no downtimes, only hot code updates) and doing eager loading is not a decisive point.

At the end, I think it depends deeply on each use case: if you have time enough to prepare a build workflow, if your application really needs it, if you like/dislike Dockerized applications…

I have really enjoyed reading the thoughts about this topic, thanks guys!

I suppose one of my main points though is that this is not true. You CAN use a dedicated build environment, but you do not NEED to. If you’re running mix in production, you literally add one command mix release and now you’re using releases, no new build requirements at all.

True, but this isn’t something you should be doing in any project anyway, whether using releases or not.

I do both. I build a docker image containing an erlang release, and then I run that docker image in an ECS cluster. Pushing up the image diff is the same size as pushing up the tarball.