I use earthly. I would not use it instead of bazel, but with bazel. You can imagine earthly working by building a DAG of docker commands (RUN, ENV, ...), simila

I use earthly. I would not use it instead of bazel, but with bazel. You can imagine earthly working by building a DAG of docker commands (RUN, ENV, ...), similar to how bazel/make make one on your source files. If A depends on B and B changes, B then A are built, etc. So keep bazel for building and testing, but you can use earthly to run above it so every bazel build is in a fresh docker container. Example: # All image deps RUN apt install -y bazel gcc build: RUN bazel build test: FROM +build RUN bazel test release: FROM +build RUN bazel package SAVE ARTIFACT AS LOCAL ./a.out a.out SAVE IMAGE cool-app:latest Basel build runs before the other two targets, but testing and packaging run in parallel. I do this for elixir projects -- npm install assets and mix deps.get in parallel, then copy both results into the final image. Edit: you can also inject arguments and the dependency graph will fork when needed. So for example, I can specify multiple version targets and earthly will only start running in parallel when it hits the build arg line (since subsequent run lines will have different build arguments)