Elixir applications in Docker containers?

I have been thinking about setting up continuous delivery and I wonder:

Does running Elixir/OTP within a Docker container put you at a major disadvantage?
Will the application be able to use all the CPU cores and in general benefit from OTP’s design?

Maybe @jeffweiss can shed some light on the topic for us? :smiley:


I found only that there could be problem when you want connect with Erlang Vm with another Erlang VM on different machine.


Thanks for the link! Yes, networking is another friction point and a common problem I have with Docker in general.

1 Like

In a few years Docker will be as good as Solaris zones :slight_smile: (or not)


A common problem I’ve read about is BEAMs hot-code-swap capabilities, which you seem to give up when using docker.


Check this out, that’s the closest setup I’m using in production, but you kinda give up about code-swap, but at least you have a good envelope (deploy way) for you infrastructure.


It seems like edeliver is the way to go; Plataformatec recently published a blog post about it and it looks easy to setup. It seems to me, unless you already have a Capistrano/Jenkins or Docker deployment pipeline setup, then it will be easier just to use edeliver.

Perhaps we can incorporate some of this information back into our deployment wiki thread.


How do you manage files permissions between containers and development environment?

1 Like



Found this in my email this morning:

Dockerizing Elixir and Phoenix Applications
Learn how to make your Elixir workflow more consistent and convenient with Docker and Docker Compose


Thanks guys I’ll read them.


At work I run Elixir releases in Docker containers managed by Kubernetes, with two applications which are clusters of nodes. In my experience this setup works very well. Yes with containers you give up hot upgrades/downgrades, but I’m also of the opinion that unless you have a good reason to be doing hot upgrades, you don’t need the extra complexity, and Kubernetes makes blue/green and a/b style deployments easy to achieve. Without Kubernetes (or something like it), it’s probably much less interesting to use Docker.


Since you’re using Kubernetes I have an other question how do you manage the database connection when destroying and recreating a container?
In the project I’m working on it seems like the db connections are not correctly released when the container is destroyed and I didn’t find any resources on how to do a graceful shutdown of phoenix.

1 Like

@frieden I haven’t had this issue, but I’m running releases in my containers, and when they receive a kill signal, the node is shutdown with :init.stop(), which cleanly shuts down all applications then the node itself.


@bitwalker Did you had this command to your release or is it available through the generated release of exrm?
Do you have an example maybe?
Sorry if my question seems a little bit dumb but I’m new to this.

1 Like

@freiden Apparently I never backported the shell script modifications which trap signals and handle calling :init.stop(), it’s only in Distillery. I could probably backport that easily enough, but it may be worth just switching to Distillery if you have the option :wink:


I’m went the Kubernetes way as well as @bitwalker suggested. Using the endpoints API to connect them together. https://github.com/bitwalker/swarm/blob/master/lib/swarm/cluster/kubernetes.ex

Found an easy to use flynn workflow.


It’s using heroku buildpacks… which gives you the base to put your own logic into the build process…
I found it actually the most straightforward way to deploy an app… so far.

And I really like the git control flow…

  1. commit your changes,
  2. merge it to master,
  3. git push flynn master… and it will handle the rest for you.

As Bonus, it has some really nice dashboard, to check the logs and so on


Flynn is really great, I’m also following that blog post to deploy a Phoenix application, but I get an error when trying to migrate the database (for a new app):

$ flynn run mix ecto.migrate

14:30:03.227 [error] Postgrex.Protocol (#PID<0.210.0>) failed to connect: ** (Postgrex.Error) ssl not available
** (DBConnection.ConnectionError) connection not available because of disconnection
(db_connection) lib/db_connection.ex:718: DBConnection.checkout/2
(db_connection) lib/db_connection.ex:619: DBConnection.run/3
(db_connection) lib/db_connection.ex:921: DBConnection.run_meter/3
(db_connection) lib/db_connection.ex:463: DBConnection.prepare_execute/4
(ecto) lib/ecto/adapters/postgres/connection.ex:82: Ecto.Adapters.Postgres.Connection.execute/4
(ecto) lib/ecto/adapters/sql.ex:228: Ecto.Adapters.SQL.sql_call/6
(ecto) lib/ecto/adapters/sql.ex:178: Ecto.Adapters.SQL.query!/5
(ecto) lib/ecto/adapters/postgres.ex:69: Ecto.Adapters.Postgres.execute_ddl/3

Have you deployed a Phoenix app with Postgres in Flynn?

1 Like

Not yet, I’ll try to test in the next days, when I have some more time.
My first naive tries ended with the same error.