Because there is no agreed upon way to properly do it yet. I tried using Elixir 2 years ago in production, and while the language is great, deploying (and runtime configuration) was a nightmare.

It was 2 years ago, I know the community tried to improve things, but it's still not there. I read some excerpt of the upcoming book "Phoenix in Action", and in chapter 1, the author himself mentions "deployment" as a drawback of using Phoenix since it's still painful.

Distillery is pretty much “the way” right now and the core team hired the guy that built it to flesh out the long term built in solution. He’s explained the various moving parts but the short version is that he’s aiming for portable binary style deployment.

Except, it's really not. Boring "MIX_ENV=production mix phx.server" works just as well, and you can trivially add the stuff to make logging into a node easier.

Everybody wants this tooling for deploying appliances when frankly we are almost all just doing boring webshit.

I'm curious as to what was a nightmare about the deployment and runtime configuration. Would you mind sharing your experience? Even better, post your concerns on one of the following sites and link back here. Sounds like it could be an interesting issue and I might be able to contribute.

https://github.com/elixir-lang/elixir/issues

https://github.com/phoenixframework/phoenix/issues

The general issues people have are around Application env, compiled System variables from build box in their configs, people forgetting that module attributes are compiled, and those sorts of issues. Libraries have begun moving away from Application env per library guidelines, and have begin moving to init/2 callbacks instead, which alleviates a lot of those issues, but there are a lot of straggler libraries that will not change for a while. So you have to do funky things like play with your Application env in your application.ex file. You had that weird system tuple thing that some libraries supported, and some that didn't, and then things like Confex coming up to meet in the middle. There isn't a nice story for getting secrets from something like Vault, for example.

Releases are not mainline yet (soon!) and are kind of off to the side in a semi-officially supported way (bitwalker is amazing!). There are guides for this, but not the same type of guides as would exist if it were in the core repos. Then you have hot code reloading, which exists, but is usually said to be shied away from generally, so there's even fewer guides about all the gotchas that come with those sorts of systems. Some people even run mix phx.server on their prod boxes!

I LOVE this language, and all these problems have solutions and workarounds, but one can't tell the story without being honest about the current release/deployment quirks. Things are definitely better than they were a few months ago, and much better than a few months before that. But they're not quite at the level they need to be for something that's supposed to be so fundamental to your application as its configuration and release. They'll get there.

Oh I ran into some of those issues too. Getting runtime configuration variables can be a bit of a pain. But on the plus side, I added a tuple (MFA) option in a PR for a lib and Jose Valim merged it a few days later. Really helpful core team!

My experience has been painful at first (~1 week time to get setup), now takes 15 minutes to get a service deployed.

Using Heroku (not good practice and I wouldn't use in prod), it would be really quick.

Heroku works fine in prod up to the scale of most pre-series A startups. There are a few limitations you have to accept but for us the easy deployment strategy (and existing suite of addons) makes it very easy.

This is true, probably fine for smaller use cases. I cannot imagine doing a production Elixir app without node networking (I do quite a few things with it), and that is a deal-breaker for me on Heroku.

That's really the only deal-breaker though. Docker for Heroku makes it really easy to ship artifacts rather than source which I think is important as well.