A general approach in situations like this is to split the work that’s done in the layer into pieces that can be individually invalidated.

When I saw a similar issue with a Rails project (gems with native extensions take a long time to install), the solution was to have a separate step that only installed those gems before the main bundle install. That was simpler to implement because the gems were going to the system location (versus building in a Mix project).

Instead of a single mix deps.get and mix deps.compile, you could have a “mix-foundation.exs” (with lockfile set to mix-foundation.lock) then use MIX_EXS=mix-foundation.exs mix deps.get etc

That should produce a rarely-invalidated layer that pre-populates the _build directory and speeds up the plain mix deps.compile later.

One thing to watch out for: if the versions in the main file drift away from the ones in the foundation, nothing will fail but build times will go up when the correct versions have to also be installed. (the Ruby version had been in place for years and had this exact drift)

Just to narrow the list of suspects first: you’re using a multi-stage Dockerfile, right? And mix deps.get and mix deps.compile are both separate commands, not mixed with others on the same line, correct?

Oh, and this: are you cross-compiling for another CPU architecture?

If you have the time to invest into learning Nix, you can build Docker containers with Nix.

EDIT: Updated to a higher quality video

Thanks ! Look promising. Plus I always wanted to have a try at grasping nix (it is on my machine but I don’t use it much yet). I’ll make some experiment and post result here.

PR : for those who want to spare time, the meat of the talk starts at 25:07.