Mix release or Distillery? Which one when and why?

When looking for options for production deployment of Phoenix applications I came across the two competing (?) alternatives: mix release and Distillery. If I understand correctly the latter one predates mix release and was created to fit into the gap later filled by mix release? Is Distillery still important today? If yes, in which cases / situations would you use one over the other?

mix release does not support hot code reloading so if that’s important to you, then distillery is necessary. Personally, I don’t put a lot of stock in hot code reloading, I think it introduces a lot of complexity and you’re better off with normal rolling deploys. In any case where you don’t need or want hot code reloading, mix release is the thing to use. At least at the time we switched it builds releases a lot faster, and seems easier to configure.

6 Likes

Thank you. Especially for pointing out that mix release and hot code reloading are not roommates. I am not sure if I understand the pros and cons of hot code reloading though. Unless I misunderstood the thing, it looks like a totally cool thing to have. Like - even if you have a minimal infrastructure with only one server you can still get full-zero-downtime updates, right? Sure, with larger infra this is no longer such an important factor. Also - rolling updates are to me part of release strategy rather than deployment technique so I must be still missing/mixing things

While it is a cool feature, it is very hard to implement it correctly and it is still a black box in elixir and erlang communities. The other downside of hot code reloading is the fact it conflicts with containerized environments like docker, that states that a container should be immutable and if you want updates you should use a new one.

In my practice I never used hot code reloading, however I did override modules code at runtime, either to test for a specific bug or to hotfix something while the next release was prepared.

2 Likes