Here’s what I’ve got:
docker run -it gmile/ritm:0.0.10 du /app/erts-9.0.1 -h -d 1
19.3M /app/erts-9.0.1/bin
872.0K /app/erts-9.0.1/include
4.0K /app/erts-9.0.1/doc
852.0K /app/erts-9.0.1/lib
12.0K /app/erts-9.0.1/src
4.0K /app/erts-9.0.1/man
21.1M /app/erts-9.0.1
Looking closer, looks like it’s erts binary that takes the majority of that space:
docker run -it gmile/ritm:0.0.10 du /app/erts-9.0.1/bin -h
19.3M /app/erts-9.0.1/bin
Interesting, so maybe on Alpine it’s statically linked? I’ll have to review how I’m compiling Erlang in the base image, maybe I have some options set that aren’t needed.
If that’s a lot to you 
Most images I usually deploy are +500MB… (not my fault, but many people tend to just take Ubuntu as a base image and add a lot of unneeded crap to it…)
Congrats for trying out multi-stage, it’s a really nice feature I’ll start to use once our CI is running the latest Docker version.
My own alpine image built through edib with a bit of tweaking are around 23 to 40 MB depending on js and assets most of the time. With few assets, 23 MB is a classic.
~20 MB will be the lower boundary I think (without stripping or zipping the source code; empty hello world project).
But I also think this is okay enough and mostly better than 500MB to 1GB sized images I currently see floating around in Docker based setups of some companies.
If I understand correctly, there are at least some libs that erts is linked dynamically against:
docker run -it gmile/ritm:0.0.10 ldd /app/erts-9.0.1/bin/beam.smp
/lib/ld-musl-x86_64.so.1 (0x5556a11bd000)
libz.so.1 => /lib/libz.so.1 (0x7f6fda905000)
libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x7f6fda6b0000)
libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x5556a11bd000)
I still need to push some PR, and tbh, the new docker multi stage support nearly kill the need for edib.
Yeah I dug around in my alpine-erlang build today, it looks like the bulk of the extra space in beam.smp is in the .debug_loc and .debug_info sections of the binary (~11mb) - so I assume one could strip those easily enough, but whether that’s ideal or not is a different question I suppose.
Even if I strip 11 Mb, that’d make it 48 - 11 = 37, which is still 2x times than what people here are reporting, e.g. 20 Mb.
I’ll investigate further.