Multi-stage Docker builds are criticized as an antipattern for Java shops that already have a Maven or Gradle CI/CD pipeline compiling, testing, and versioning artifacts. Rebuilding inside Docker means the image no longer contains the exact artifact that passed the pipeline's tests, just a similar rebuild sharing the same commit. The recommended alternative is a single-stage Dockerfile that copies the already-built jar into a minimal runtime image (e.g. eclipse-temurin:25-jre-alpine), reserving multi-stage builds for cases where Docker itself is the chosen build environment.
Questions this post answers
Should I use a multi-stage Dockerfile for a Java app that already has a Maven or Gradle CI/CD pipeline?
No, a single-stage Dockerfile is preferable when a CI/CD pipeline already compiles, tests, and versions the artifact. Multi-stage builds recompile the code inside Docker with a different JDK, local repository, and cache, producing a rebuild rather than packaging the exact tested artifact. The better approach copies the already-built jar into a minimal runtime image, such as eclipse-temurin:25-jre-alpine. daily.dev surfaces practical takes like this for teams weighing Docker build strategies in Java pipelines.
5.5K Impressions1 Comment