At Aircloak we’ve been using Docker for a few years now, and I personally find it very helpful in a couple of ways.

First of all, Docker made it simple for us to describe our entire production through code. The complete production setup is defined in dockerfiles which is a part of our main repo. One great benefit of this is that it’s very easy to start and troubleshoot the production environment locally, regardless of the OS the developer is using. Going further, this paves way for running tests in the production-like environment. We didn’t use to test through Docker, but more recently we’re shifting toward that approach, at least for integration tests.

Relying on docker images also helped us simplify the installation. Our system is hosted by the end users. We ship them the docker image which already has everything installed and configured, so the clients don’t need to care about our installation details.

Since we deal with multiple clients, we need to be able to easily debug and test different versions of our system. Again, this is where having docker images really makes things simple for us. Want to quickly verify something on some previous version? Start the container for the desired image version, and you’re good to go. Need to develop and work with the previous version? Checkout the related branch, make your changes, build the image, and start the container.

While Docker is certainly not perfect, I still think in most cases it’s a saner choice than bare installation, because it makes many things more predictable, and helps keeping a lot of production setup in the code (which is always a good thing IMO). Personally, after working with and without Docker, I definitely prefer a docker based production setup.

Well for me it is easy to keep it separate from the main OS so it can easily be migrated around without needing to setup erlang and such all over the place, it is a ‘container’.

Re-using my own previous answer to this sort of question with minimal changes:

The strongest case in my eyes for containerizing your BEAM apps is if you must integrate gracefully into a larger ecosystem containing multiple other languages, runtimes, etc. within your org. If you are already deploying other code with Docker, it’s probably a foregone conclusion that your BEAM projects would too. If you are greenfield BEAM languages all the way, it’d be harder to make a strong case for Docker, rkt, etc.

I’ll also reiterate from another related thread - CPU/memory overhead of Docker are usually minimal to the point of statistical insignificance, its the networking implications that can have much more serious performance impact. Raw disk I/O can be hurt too, if you’re not using volumes when it’s appropriate.