A non-autoscaling deployment is quite easy to accomplish. Build releases with Distillery[1], and deploy them with Edeliver[2]. You get zero-downtime upgrades and rollbacks for free, as well as nearly automatic server clustering. I gave a talk about this last year in New York[3].

A deployment that can autoscale is harder to accomplish, but still not impossible. AFAICT, most people doing this are building releases with Distillery, wrapping those releases in a Docker image, then using the deployment and orchestration tools of their choice. Monica Hirst gave a talk about doing this with AWS CodeDeploy last year at Empire City Elixir as well[4].

[1] https://github.com/bitwalker/distillery

[2] https://github.com/boldpoker/edeliver

[3] https://www.youtube.com/watch?v=H686MDn4Lo8

[4] https://www.youtube.com/watch?v=mRspOj_sRgo

Deploying releases has been fairly painless in my experience, but I also have had my head in Elixir and releases in general for a long time, so I may not be a great sample. You get a tarball containing everything the app needs to run, and all you do is extract it and run the boot script - other than entirely self-contained binaries like Go produces, I don't think it gets much better. Deploying without releases is probably a lot more painful though, due to the number of dependencies required, particularly web applications (Erlang, Elixir and Node). I recommend anyone deploying Elixir applications look into releases - it makes life much easier (imo).

I'd mostly agree, and the packages you've written (ExRM and Distillery) make releases super easy to build, start, and stop.

The main benefit of Go, I think, is that it can cross-compile builds. Erlang and Elixir don't have any way to do that, so if you develop on Mac and deploy on Linux you'll need to build your release in a VM or on a build server running Linux.

You actually don't have to bundle the runtime, but you can also specify an "alternate ERTS", i.e. one that has been compiled for the target architecture, and bundle that one instead. This is how you "cross-compile" releases.

You can include any erts in your target system, so you can take one built on linux, copy it to your mac and use it only at the time when you construct the release tarball.

I thought BEAM was a bytecode VM so why do you need to cross compile anyway? Is the bytecode different on different architectures?

Some libraries contain native dependencies, and those have to be cross-compiled. You also need a cross-compiled runtime if you are bundling it and not using one already installed on the target.

Releases include the Erlang byte code and the VM as well which needs to be compiled for the platform it will run on.

But why would you want to recompile the VM when you've just changed your program?

And it looks like you can cross compile BEAM anyway. http://erlang.org/faq/implementations.html. It's just a C program isn't it so why wouldn't you be able to?

The ERTS runtime (VM + libraries) are taken from the host and are not built. That said, it is possible to build the runtime for other platforms via cross compilation. [1][2]. I've done this for ARM, but have not tried to generate a release using the cross-platform build.

The beams themselves are cross-platform bytecode, but in practice beam files are not distributed on their own (except for patching). Typically you'll ship them as part of the released package which includes ERTS, your application, and all required dependencies (system libraries, other apps/libraries, and any native dependencies you've introduced). It excludes anything you don't declare as necessary from the final release package

In practice, people will usually use either the official release tooling or third party tooling to create platform-specific releases.

[1] http://erlang.org/doc/installation_guide/INSTALL-CROSS.html [2] http://www2.erlangcentral.org/wiki/?title=Cross_compiling

You're not recompiling the VM, you're just including a copy of it in the release tarball, so that you can copy the tarball to any machine with the same architecture and run it regardless of whether Erlang or Elixir is installed globally on the machine.

The goal of a release is to bundle together everything you need -- your program, the VM that runs it, your config files, and any instructions necessary to upgrade/downgrade from another version of your code.

He means why not just include the apropiate vm as a binary for any given arch.

But why build the VM for every release then? What is it that needs to be cross compiled if you're just copying a VM build into a tarball? Why not copy an existing build of it in?

The VM is not built for every release, it is copied into the release. The fact that it isn't built for each release is why cross-compilation of releases is not possible.

I must be an idiot because I still don't get it. If the VM is just copied into the release, not built, why can't you do that on macOS for deployment on Linux by copying a Linux version in? Why do you need to do it in a VM or Linux build server?

It's probably only that no one's written the tooling for that yet, because it's easy enough to set up a Linux VM or build server.

The tools (relx, exrm) can do that.

I don't think it's common to build and deploy from your laptop once you hit a certain team size -- with builds going through Jenkins &al. -- but maybe this really does a make difference for smaller teams.

Deploying to production is a pain in the ass to setup the first time and has a lot of gotchas. I know, I've done it.

It is getting better but right now the few things I can recommend the most are:

• learn what an "OTP release" actually is and what it means. This alone will save you days of your life.

• do rolling restarts, doing live upgrades is difficult and not necessary for the vast majority of applications.

• read the prod.exs config, there's a commented out setting you'll need to enable. I forget the name of it, but it's on my github "tehprofessor" with the repo "flying with Phoenix" (its probably outdated in many ways but that setting is essential).

• remember the application is compiled and then run, so you really won't get any runtime configuration (likes Rails' environments).

• Docker can alleviate build pain a bit, as it stabilizes your environment-- I don't use it myself but it makes building a bit more pleasant from what others have told me.

• you'll very likely need to include all the applications, including ones listed in your dependencies (it's a pain in the ass), in your mix.exs applications list if you're using exrm.

... it's been a couple months as I've been on a coding hiatus for health reasons (and a broken arm) but I believe most of the above should still be very true.

That said and even with all the bitching I've had about it, I still love Elixir and Erlang. Though I've been moving more to pure Erlang as time goes on (FWIW).

Edit: clarity and note about loving me some elixir/erlang.

edit: my experience has been with Erlang deployments, I don't yet know what the landscape is like for Elixir - at least the first part of my comment below can be disregarded. I would assume it's similar to deploying an erlang application, but I don't know for sure.

I think the second part is still possible, since if it can be done for Erlang it can be done for Elixir.

-- Original post --

I haven't found production deployments to be particularly painful, I'd be interested to hear what kind of troubles you've run into.

Runtime configuration is definitely possible - you can deploy configuration files with your application and determine which one you want to load. It's not built-in, but it's a few lines of code to do it manually. You can also always use environment variables, which is arguably a better approach.

I do not agree that it is a pain in the ass. It's not more or less complex than many other languages. Also, the tooling has improved a lot in the recent months and edeliver + distillery work great, even without much previous experience.

We have Elixir/Phoenix in production on Heroku (with Heroku Pipelines) using a custom buildpack [0]. It's been great. We'll probably look at Docker. We use CircleCI, and this setup script [1] was a great starting point.

0: https://github.com/HashNuke/heroku-buildpack-elixir 1: https://gist.github.com/joakimk/48ed80f1a7adb5f5ea27

Distillery is highly recommended https://github.com/bitwalker/distillery

I totally agree. It takes a bit of trial-and-error for the first time, but works perfectly fine once you have figured it out. I recommend going with edeliver + distillery for the best experience, plus it is the recommended way of deploying Phoenix as of today.

Where do you plan to deploy? Its easy enough to deploy to Heroku, and I imagine dockerizing an Elixir app is also a straightforward process. If, on the other hand, you are taking a more traditional approach and just deploying to a Linux box/vps there are solutions for that too (i.e. Chef, Capistrano).

It should be pretty far down in the list of things that influence your choice, imo, since it's basically a solved problem.

My company's first choice is always Azure since outside of my team we're C# head to toe. Though after skimming through a few deployment articles I might push for a Heroku deploy.

I can honestly say I've not been this excited about a language in quite a while. Working with Go is pretty straightforward... but it's a complete bore. The more I dig into Elixir the more I desire to use it full-time.

I think that with proper deploy automation (e.g. Ansible) and the right approach (avoid hot-code updates unless your REALLY need them) you are going to get a pretty solid deploy experience, no matter what your target deploy platform is. Just throw in an HAProxy for rolling deploys and you are ready to go!

If you need any specific help, feel free to contact me!

You might want to look into edeliver https://github.com/boldpoker/edeliver

Yes, deployment in Elixir is painfull. We use distillery and edeliver, but plan to try move to docker

I build releases with distillery and deploy them with Docker, the combination has worked really nicely for my projects.

Disclaimer: I'm the author of exrm and distillery, so I'm probably biased.

You are are not biased just experienced with the tools. Huge thanx for distillery.

Thank you for distillery, it's a very nice tool

I don't see why it should be painful. What were the issues you were facing?

I found that besides hot-code updates, there is not as much magic as one could think, and once you "grasp" the idea of a build machine, it should be pretty straigt-forward. Throw in an HAProxy for rolling deploys and you have a sweet zero-downtime solution!

Feel free to contact me if you need someone to help out (from some free general tips and tricks to supporting your team as a consultant).

As far as deployment goes, I've had great success with flynn.io and an Elixir buildpack.

Flynn is amazingly easy to deploy. It provisions DO/AWS/Azure then bootstraps a single node or cluster literally at the push of a button. Then you just add it to your repo and push (provided the buildpack is already set up)

Even without exrm (Distillery nowadays), I've had quite a bit of success with using Docker, complete with hot patching. I come from a Linux administration background, though, so I'm a bit more open to abusing Docker's semantics in horrific ways.

I run erlang in production; our deploy is push code, compile, l(foo) from debug shell. (push code and compile driven by Makefile). It doesn't follow the OTP deployment model, but it's easy.