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.
