Elixir v1.9.0-rc.0 released

I really like that the config situation is starting to get cleared up :slight_smile: I do wonder if this still means that it is necessary to create a custom command to run migrations? I’ve always kind of hated having to do stuff like this https://github.com/bitwalker/distillery/blob/master/docs/guides/running_migrations.md in release images, instead of using the standard mix ecto.migrate which seems perfectly suited for the job.


There seems to be more than only Code.load_file/2:

$ git describe --tags
$ git grep -n 'TODO: Deprecate' '*.ex' | grep v1.9
lib/elixir/lib/code.ex:57:  # TODO: Deprecate on v1.9
lib/elixir/lib/code.ex:89:  # TODO: Deprecate on v1.9
lib/elixir/lib/code.ex:762:  # TODO: Deprecate on v1.9
lib/elixir/lib/supervisor/spec.ex:112:  # TODO: Deprecate all functions in this module on Elixir v1.9.
lib/logger/lib/logger.ex:841:  # TODO: Deprecate compile_time_purge_level on v1.9
lib/mix/lib/mix/task.compiler.ex:113:  # TODO: Deprecate :ok and :noop on v1.9

I’m curious, what does mix release mean to distillery+edeliver combo? I’m asking, because I’ve used it so far, and I don’t know what are potential steps to replace distillery. I know, it’s early to ask it, but maybe someone has thought about it already :smiley:

Elixir’s releases are basically a subset of what distillery does (it doesn’t include anything for hot code updates for example). Distillery already seems to have moved it’s mix tasks to a distillery.* namespace and should continue working there.

1 Like

If anyone is looking for the documentation on releases:



Those are the minimum versions to deprecate them. In this case, we have postponed them as we are increasing the gap between soft-deprecation and hard-deprecation, but they will be eventually deprecated.

1 Like

We’ve published a blog post Updating Hex.pm to use Elixir Releases about exactly that, hope you’ll find it helpful.


Woah! mix release is quite exciting! Congratulations to the Elixir team and thank you for all the hard work. You make our lives easier.


Are config providers only available to releases or is it possible to use them when running in dev?

1 Like

All of my projects compile and test with no errors on 1.9. I haven’t tried releases yet. Is there a migration guide from distillery?

1 Like

Try out


Is there more detailed documentation of config/releases.exs available somewhere?

The docs linked above talk about it: https://hexdocs.pm/mix/1.9.0-rc.0/Mix.Tasks.Release.html#module-runtime-configuration


Once a release is assembled, it can be packaged and deployed to a target as long as the target runs on the same operating system (OS) distribution and version as the machine running the mix release command.

Are there plans to remove those limitations in the future?

I’ve never seen the BEAM have any sort of cross-compilation to date, in addition the NIF’s would have to be cross-compiled in whatever language they are written and so forth as well. I.E. it’s not possible in any easy timeframe.


Really glad to see releases included as part of the language – hats off to you guys!

1 Like


Quite a few products that I know of uses the cross compilation support to build Erlang/OTP.

However as you say, cross compiling nifs is a problem as many nifs writers have not done what needs to be done in order to make cross compilation work. I put together syslogger as an example/experiment of how one could achieve cross-compilation for nifs (if you ignore cross compiling to windows).


Can anyone comment on how much the new release process and configuration tools have improved in terms of deploying Phoenix?

A while ago I wrote up a guide for myself since the previous process was pretty complicated and it was the Distillery docs that were the only ones that even had the setup for Phoenix.

The pain points for me were:

  1. Having to go through the Distillery docs in order to deploy a Phoenix application (they were pretty good but lacking in some areas and had bugs in others). There was also a general lack of guidance on how to do more advanced things.
  2. Having to figure out how to use environment variables for configuration at runtime in a release or figure out how to properly set the configuration with environment variables when building a release.
  3. Having to create special code and special release tasks just to run migrations when those could already be run from the command line with mix. This included having to setup shell scripts.
  4. Figuring out how to load the secret key from an environment variable at runtime.
  5. Little to no information regarding Postgres/Ecto in general (the new version of the docs has almost no information at all).
1 Like

Regarding documentation, those concerns aren’t solved right now (it is too soon) but I believe it will be solved in the short term as, by being part of core, more people will use it, battle test it, document it, write guides, etc. For example, [latest Ecto ships with functions(https://github.com/elixir-ecto/ecto_sql/pull/113) that make running Ecto tasks inside a release very straightforward]. Phoenix guides will also be updated to cover it.

In particular:

Phoenix will ship with guides for this (it also does for distillery though).

There is a well-documented path for this in Elixir releases (TL;DR - there is a config/releases.exs that runs on release boot).

Custom code is still necessary for Elixir but you don’t need shell scripts. Only a module with functions you will invoke. See the Ecto link above and the official guides. The Hex migration (which is a Phoenix app) covered this too: http://blog.plataformatec.com.br/2019/05/updating-hex-pm-to-use-elixir-releases/

Same as above other environments variables: just put it in config/releases.exs. In fact, for Phoenix v1.4 projects, getting it to work is a matter of renaming config/prod.secret.exs to config/releases.exs.


Thanks for the quick response! This makes me feel much more comfortable with the new process. I think in particular the runtime release configuration support will be a huge improvement and will alleviate a big reason why releases were confusing in the past.

I think I remember that it is a future goal to unify the experience of using mix and releases so that there isn’t the “I did this easily in mix why is it so different in a release” reaction. That, in my opinion, will mark the resolution of the final difficulty with deployment for Elixir apps now that runtime configuration has been improved and release generation brought to core.

Cheers to a bright future :slight_smile: