Install a specific Elixir version (having a hard time getting it right)

New to elixir and phoenix and was trying to do a full life cycle on a simple crud. I’m having the darndest time getting Elixir to work with distillery/edeliver.

I’m using a 16.04 Ubuntu server. I can build manually and server it from the server via SSH. After some sleuthing. 1.7 and Distillery do not play well together from my understanding.

So I tried to use asdf and kiex for versioning elixir. Every time I attempt it says that ‘mix’ isn’t really a thing (even though it is on the shell when I try it.

So I was just seeing what is a good way to install elixir version 1.6 specifically since I’m having a heck of time tackling the other alternatives I’ve found on the net. Thanks.

1.7 and distillery work great, you just need to use distillery 2.0.

Setting that aside, it sounds like when you installed asdf you didn’t add its paths to your bash profile, OR you didn’t set a global version.

Just asdf should be enough. Follow the installation instructions, then

asdf plugin-add elixir
asdf install elixir 1.6.5

should do the trick. Usually I also add the Erlang plugin and manage OTP the same way (and an even dozen other languages as well, all stashed in my ~/.tool-versions so that a single cd ~; asdf install will sync a new machine with the languages and versions I use at any given time).

1 Like

Just tried 1.7 and Distillery 2.0 I continue to get the same error

“** (Mix.Releases.Config.LoadError) could not load release config rel/config.exs
** (UndefinedFunctionError) function Mix.Config.Agent.start_link/0 is undefined (module Mix.Config.Agent is not available)”

which according to is related to versioning. Unless I’m doing something wrong (very possible still pretty new to Elixir)

If you do elixir --version within that project what do you get? What’s the output of mix deps|grep distillery?

Added asdf per instructions. Added the plugin for elixir and otp. Did the installs and added a global.

On the server it seems to work as I can obtain elixir version (1.6.5) via asdf and I can load the application manually via SSH. So I’m a little thrown for a loop.

Maybe I’ll start a clean build just and try to deploy that and see how it works.

for elixir version:
Erlang/OTP 21 [erts-10.0] [source] [64-bit] [smp:1:1] [ds:1:1:10] [async-threads:1] [hipe]
Elixir 1.6.5 (compiled with OTP 19)

for mix deps|grep distillery:

My local machine has=>

  • distillery 2.0.2 (Hex package) (mix)
    locked at 2.0.2 (distillery) 58e15f67

My server has =>

  • distillery 1.5.3 (Hex package) (mix)
    locked at 1.5.3 (distillery) 58e15f67

So. I re-compiled it and the release worked. So this helped as I have spent a few days of my free time trying to wrap my head around a different form of deployment.

It’s apparent I wasn’t taking into consideration the ‘compile’ piece. Thanks

Now I can can get it to build and release- I’m just receiving a ‘pang’ when I use mix edeliver start production on local shell. So I’ll sleuth to see why I can’t connect.

If you’re building the release locally, your server doesn’t need Distillery or even Elixir FYI.

Based on the output of elixir --version it appears that you aren’t actually using 1.7


You can also choose the OTP major version when you install elixir via asdf.

asdf install elixir 1.7.x-otp-20

This will install elixir 1.7.x but compiled with OTP 20.


Good point, thanks.

I was building it on the server to see if it would run. Which is how it came about but always good to have that confirmation it’s only locally needed.

i dont want to use asdf.
what is the command line instruction to install elixir v.1.8.1?

Why? Is there a specific dreason?

This massively depends on your operating system.


If you’re using Ubuntu like the OP, you can use apt to install a specific version of Elixir in the same way you’d do for any other package: apt-get install PACKAGE=VERSION.

The non-obvious part is that the Elixir apt packages append a “-1” to all their versions, so if you wanted 1.8.1, you’d have to run apt-get install elixir=1.8.1-1. Why this appendage exists, I’m not sure.

1 Like


It’s a practice that’s fairly common to APT, Yum, etc. It’s there to differentiate between “the version of the software being packaged” and “the iterations/version of the packaging approach itself”. For example, if the build pipeline has changed, or a previous iteration accidentally included something it shouldn’t or omitted something it should, the version of the software being packaged hasn’t changed but the artifact itself will be different. It’s useful to be able to indicate which specific historical contents you have, in shorthand, without relying directly on checksums or another content-addressable approach.