Multi-stage Docker builds in Spring Boot - Step-by-Step Execution

Concept Flow - Multi-stage Docker builds

Start: Base Build Stage

↓

Compile & Package App

↓

Create Smaller Runtime Stage

↓

Copy Artifacts from Build Stage

↓

Set Runtime Environment

↓

Build Final Image

↓

Run Container with Final Image

The Dockerfile first builds the app in one stage, then copies only the needed files to a smaller image for running.

Execution Sample

Spring Boot

FROM maven:3.8.7-openjdk-17 AS build
WORKDIR /app
COPY pom.xml .
COPY src ./src
RUN mvn clean package -DskipTests

FROM openjdk:17-jdk-slim
COPY --from=build /app/target/*.jar /app/app.jar
ENTRYPOINT ["java", "-jar", "/app/app.jar"]

This Dockerfile builds a Spring Boot app with Maven, then creates a smaller image with just the jar to run.

Execution Table

Step	Action	Stage	Files Present	Result
1	Start build stage with Maven image	build		Base image ready
2	Copy pom.xml	build	pom.xml	pom.xml copied
3	Copy src directory	build	pom.xml, src/	Source code copied
4	Run mvn clean package	build	pom.xml, src/, target/app.jar	Jar file created
5	Start runtime stage with OpenJDK slim	runtime		Clean runtime image
6	Copy jar from build stage	runtime	app.jar	Jar copied to runtime
7	Set ENTRYPOINT to run jar	runtime	app.jar	Runtime ready to start app
8	Build final image	final	app.jar	Final image built with only runtime files
9	Run container from final image	final	app.jar	App runs with minimal image

💡 All build steps complete; final image contains only runtime essentials.

Variable Tracker

Variable	Start	After Step 4	After Step 6	Final
pom.xml	absent	present	absent	absent
src/	absent	present	absent	absent
target/app.jar	absent	present	absent	absent
app.jar in runtime	absent	absent	present	present

Key Moments - 3 Insights

Why is the source code not present in the final image?

Because the source code is copied only in the build stage (see step 3) and not copied to the runtime stage (step 6 copies only the jar). This keeps the final image small.

How does the final image get the jar file without rebuilding?

The final image copies the jar from the build stage using the --from=build syntax (step 6), so it reuses the built artifact without recompiling.

Why use two different base images?

The build stage uses a Maven image with tools to compile the app, while the runtime stage uses a smaller OpenJDK image to run the app efficiently (steps 1 and 5).

Visual Quiz - 3 Questions

Look at the execution table, at which step is the jar file created?

A Step 2

B Step 6

C Step 4

D Step 8

💡 Hint

Check the 'Result' column for when 'Jar file created' appears.

At which step does the runtime stage start?

A Step 1

B Step 5

C Step 7

D Step 9

💡 Hint

Look for the step mentioning 'Start runtime stage with OpenJDK slim'.

If we copied the src folder to the runtime stage, what would happen?

A The final image size would increase

B The jar file would be rebuilt automatically

C The app would run faster

D The build stage would fail

💡 Hint

Refer to variable_tracker showing src/ presence only in build stage.

Concept Snapshot

Multi-stage Docker builds use multiple FROM lines.
First stage builds the app with all tools.
Second stage copies only needed files (like jar).
Final image is smaller and cleaner.
Use --from=stage to copy artifacts.
Improves build efficiency and image size.

Full Transcript

Multi-stage Docker builds start by using a base image with build tools to compile the Spring Boot app. The source code and pom.xml are copied into this build stage. Then the app is compiled with Maven, producing a jar file. Next, a second stage uses a smaller runtime image. It copies only the jar file from the build stage. This keeps the final image small and efficient. The ENTRYPOINT is set to run the jar. The container runs the app with minimal files. This process separates building and running, improving speed and size.