Much bigger Docker image size with Elixir 1.17.0 and Erlang/OTP 27.0

I have a small web application here – Lexin Mobi (, GitHub - cr0t/lexin: Swedish Dictionary App) – which I deploy via Docker images. There are a couple of scripts (and Dockerfiles) that help me do that. Basically, I run mix release when building a new image – the approach almost identical to the one from Phoenix documentation.

After yesterday’s release of Elixir, I tried to build it using it and the latest Erlang. The resulting image size surprised me: 127 MB vs. usual ~35 MB. At glance, it appears that the files inside the /app/erts-15.0/bin directory are unusually big (6 MB vs. kilobytes in the previous version).

Here is a screenshot that summaries my findings:

The only thing I changed – versions of Elixir and Erlang – even Alpine’s base image version is the same.

I couldn’t find any related notes in Erlang/OTP’s changelog. Plus, the files seem to have almost the same content, so something is wrong with the file system… I copied erlc from both containers to see what’s the difference, and the one from erts-15.0 contains loads of space inside:

What could be wrong with this? Do you have any ideas where to look? Maybe there are some new default behavior in Erlang/OTP 27? Thanks!

1 Like

Definitely an issue that should be reported in the Erlang repo!

Erlang repo or perhaps downstream packager, depending who’s build you are consuming (asdf or/and kerl?). as a curiosity, this stuff is compiled from the sources:

$ du -sh /opt/erlang/27.0/lib/erlang/erts-15.0/bin/*
43M	/opt/erlang/27.0/lib/erlang/erts-15.0/bin/beam.smp
120K	/opt/erlang/27.0/lib/erlang/erts-15.0/bin/ct_run
116K	/opt/erlang/27.0/lib/erlang/erts-15.0/bin/dialyzer
40K	/opt/erlang/27.0/lib/erlang/erts-15.0/bin/dyn_erl
208K	/opt/erlang/27.0/lib/erlang/erts-15.0/bin/epmd
4.0K	/opt/erlang/27.0/lib/erlang/erts-15.0/bin/erl
500K	/opt/erlang/27.0/lib/erlang/erts-15.0/bin/erlc
444K	/opt/erlang/27.0/lib/erlang/erts-15.0/bin/erl_call
68K	/opt/erlang/27.0/lib/erlang/erts-15.0/bin/erl_child_setup
172K	/opt/erlang/27.0/lib/erlang/erts-15.0/bin/erlexec
4.0K	/opt/erlang/27.0/lib/erlang/erts-15.0/bin/erl.src
124K	/opt/erlang/27.0/lib/erlang/erts-15.0/bin/escript
40K	/opt/erlang/27.0/lib/erlang/erts-15.0/bin/heart
184K	/opt/erlang/27.0/lib/erlang/erts-15.0/bin/inet_gethost
84K	/opt/erlang/27.0/lib/erlang/erts-15.0/bin/run_erl
4.0K	/opt/erlang/27.0/lib/erlang/erts-15.0/bin/start
4.0K	/opt/erlang/27.0/lib/erlang/erts-15.0/bin/start_erl.src
4.0K	/opt/erlang/27.0/lib/erlang/erts-15.0/bin/start.src
44K	/opt/erlang/27.0/lib/erlang/erts-15.0/bin/to_erl
116K	/opt/erlang/27.0/lib/erlang/erts-15.0/bin/typer
1012K	/opt/erlang/27.0/lib/erlang/erts-15.0/bin/yielding_c_fun
1 Like

Can also be seen in the hexpm/elixir images:

docker run --rm -it hexpm/elixir:1.16.2-erlang-26.2.5-debian-bookworm-20240513 ls -lah /usr/local/lib/erlang/erts-14.2.5/bin/


docker run --rm -it hexpm/elixir:1.17.0-erlang-27.0-debian-bookworm-20240513 ls -lah /usr/local/lib/erlang/erts-15.0/bin/

My local asdf install of 27.0 is not affected (macOS).

Submitted this issue to the Erlang/OTP repository.

A status update: the previously linked issue landed at the right place. It has been fixed in the Erlang/OTP codebase.

However, we will need to wait for the release of Erlang/OTP 27.0.1 – this fix will be included there.

Debrief: the root cause of the issue is the LDFLAGS option for compiler that sneaked in the place they didn’t want it to be in, and it makes the compiler pad binaries with zeros in some areas.


honestly taking in consideration how many targets OTP can be built on this is no news, kudos to OTP team for their amazing responsiveness.