DidactMacros
I’ve been working through Programming Elixir, the second half of Chapter 20 pertains to releases and hotcode reloading.
One of the first errors I experienced was when using mix release --env=prod
Mix could not invoke task “release” : 1 error found
–env :unknown option
When I found that the new mix format to be used for distillery was distillery., I started again (after cleaning) using distillery.init, then distillery.release --env=prod.
Everything was beginning to build then I got a Release Failed error regarding not finding a file at ./config/config.exs, which is a bit odd because it’s my first time using distillery so I’m taking the out of the box approach, and copying files directly into config is not recommended by the distillery guides.
Throwing more at the problem I updated my dep description of distillery to include github: "bitwalker/distillery", in case github was ahead of the pm.
deps do
[
{:distillery, "~> 2.1", runtime: false, github: "bitwalker/distillery"}
]
end
runtime: false was removed, but I understand it is ignored anyway.
After I relented and touched config/config.exs I got to the packaging stage of distillery.release before triggering a Failed to archive release error that no such file or directory was located at the target uri (stipulated in the error log).
Does distillery work on the latest OTP?
I’ve been looking around and haven’t found much info regarding these bugs other than that there was a breaking change in erlang/otp 25. I’m using Erlang/OTP 26. I’ve not seen notice of a rectification.
I downloaded OTP 24 but I am reluctant to switch to it for the sake of completing this example.
Moved to chapter 21 for the time being so this isn’t necessarily urgent, just a request for clarification.
Much appreciated.
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Error tracking, logs, APM, uptime and cron monitoring in one dev-friendly platform. Find and fix problems before your users notice.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #ai
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Bringing learning, work and compliance together since 1987.
Enabling companies to succeed by building software people love.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 9- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
D4no0
Distillery was used back in the day, I am not sure it is still actively supported.
The official way to make releases now is to use releases. You can do that from any elixir project by running release task:
DidactMacros
Thanks a lot. Is the architecture for hotcode reloading now built in or does it require a library?
I don’t yet have plans for using such a feature I’m asking for future reference.
D4no0
No idea to be fair, we don’t dabble with such things in our production systems.
Hermanverschooten
Currently releases do not support hot code upgrades.
LostKobrakai
They do not come with tools to handle hot code updates, but libraries like Castle - Hot-Code Upgrade Support for Elixir can plug that into the release building.
andyleclair
The architecture for hot reloads exists at the erlang level (in the form of AppUps) but it is rarely used in prod (at least in my experience, I’m sure Ericsson would beg to differ) because there are a few annoying caveats.
We used to use them at Appcues, but it ended up being more of a pain than it was worth, so now we just reboot the processes. This gives us a few other useful properties (clearing ETS caches, not needing to coordinate running process version upgrades) and is easier for us to reason about.
To directly answer your question, distillery doesn’t currently support OTP 25 (see also; THIS LIBRARY IS NOT COMPATIBLE WITH ERLANG/OTP 25 · Issue #744 · bitwalker/distillery · GitHub) but there is a fix on a fork, YMMV.
D4no0
Imagine you are talking on the phone and your call stops because someone did a new deploy
. In their case that feature was crucial and maybe once we can create a good abstraction over it, we will harness the full power without these nitty-gritty details.
andyleclair
Yes, and that’s absolutely the case I was thinking of
It’s a nice to have, for sure! The industry I work in (SaaS software), we use Channels, and it’s not a problem for us to just reboot the servers, because the websocket will reconnect to an alive, not-being-deployed server, and I don’t need to worry if whoever wrote the appup remembered to start the new Supervisor or whatever, we just start at the state we want via
application.exand don’t worry about it.The downside is, we need to deploy our service one (or a small few) at a time, because if we deploy, say, all the servers (~50+
m6g.8xlon a heavy day) at once, we would have downtime, as well as the dread thundering herd as millions of websockets reconnect and resume state.We used to use hot upgrades, but the mental burden on the engineers of figuring out “can I do this hot or does it need to be a release” became too much of a headache. Still, it was nice to be able to deploy all of our servers at once (currently takes ~30 mins to deploy the fleet)
D4no0
Damn, that is a lot of computing power.
In this case, I agree that having hot-code reload is pretty neat. I think that once I will have some time to spare, I will start exploring this, as I think it might be a great feature if ironed out properly.