Releases are a self contained package of files for running a beam project in production. Both mix release as well as distillery are tools to build a release based on a mix project (mix release was mostly build by the learnings of the older distillery). Today most people seem to use mix release over distillery for being included in elixir and the consolidation of configuration options, but distillery has better support for hot code updates as it generates appup/relup files, while for mix release you’ll need to create them manually.

Edeliver as you’ve gathered is a more high level tool wanting to handle the whole deployment process, where building a release is just one piece.

As for docker: You can do hot code updates with docker (gigalixir does support that afaik), but it goes kinda against the grain of docker and the idea of immutable images/throwaway instance. Basically you’ll need to modify your docker instance while it’s running.

I guess that you’re right..

Particularly I found this particular chapter in the docs mix release — Mix v1.20.2 where doing so is not encouraged.

So I guess I’ll stick with mix release and docker for generating new images and then use the methods used for green/blue deployment.. I assume it’s a common way to do it after all so I’ll be able to find some resources to read..

The main thing to note here is that, once your release is running inside a container, doing blue green deployments with Elixir is basically the same as doing blue green deployments with any other language. Therefore, don’t limit the material you read to only material that talks about Elixir specifically. Pick one of the various ways to deploy applications with docker and use whatever built in blue green deployment mechanism it has.

Wouldn’t it work without modifying the instance if the release was mounted instead of being kept in the image?

I guess so, but even just mounting the app into the running container is as much against the idea of immutable images as changing the files inside it would be.

Well, technically the image remains immutable but I agree that it goes against the grain of how docker images are typically used.

Yeah, it’s for sure no longer an immutable image of your application, but at best an immutable image of your apps running os.

5 years later …

I’ve opened this post in a tab while thinking of trying out a hot code deployment without the normal release/appup/distillery approach, and take it to an extreme - continue an animation while crashing (and restarting) the process behind it, and later, tolerating a node failure (making the demo a bit chattier to support that). I’ve been reading the Elixir docs saying: “don’t do the usual thing, try other mechanisms”, and this is my answer to this with some patterns that are well-known (I don’t think there’s anything new apart from trying it out for real): GitHub - d-led/ssr-robust-live-svg: Sometimes you just have to externalize the thoughts by implementing them. Zero downtime upgrade of a server-side rendered animation of svg. No k8s, extra databases or message brokers needed (trade-offs may apply) · GitHub

I wished there were more (automated) demos on that subject with all the different trade-offs and idea combinations