I don't think it misses the point of Erlang/Elixir at all. 1) Docker is a popular project for running applications in containers. This is a familiar deploymen

I don't think it misses the point of Erlang/Elixir at all. 1) Docker is a popular project for running applications in containers. This is a familiar deployment pattern for many devs(ops) people, so it's yet another option someone has. 2) Most people using Phoenix are probably not using bare-metal, which is the only real scenario I can think of that lets you easily say "we don't need anything except for Erlang's hot code reloading". All cloud-y offerings will be potentially transient, hell, so will bare-metal. Most people will have infrastructure/tooling to provision new capacity easily, and to handle capacity being lost to failure. They almost certainly have, already, patterns for replacing containers in and out of their load balancers, etc, to avoid the need for hot code reload. I think Erlang's system for doing it can be great, but if you already have a system to run a single command that replaces your app/web/whatever fleet with a new code version, then you're not inherently ignoring the benefits/features of Erlang/Elixir, you're just doing something else you're already comfortable with. Erlang has its own "docker", but Erlang runs on an OS, not the bare-metal host, so you still have to deal with getting it there and running it.