Packaging and Container Images — Spring Boot: From Basics to Production

Spring Boot builds an executable fat JAR. For containers, either use Cloud Native Buildpacks (./mvnw spring-boot:build-image) — no Dockerfile, sensible JVM memory settings — or a multi-stage Dockerfile that extracts the JAR into layers (dependencies change less than application code) for faster rebuilds and pulls. Run as non-root, give the JVM container-aware memory settings, and support graceful shutdown (server.shutdown=graceful, the default in recent versions).

FROM eclipse-temurin:21-jdk AS build
WORKDIR /app
COPY . .
RUN ./mvnw -q package -DskipTests && \
    java -Djarmode=tools -jar target/*.jar extract --layers --launcher --destination extracted

FROM eclipse-temurin:21-jre
RUN useradd --system spring
USER spring
WORKDIR /app
COPY --from=build /app/extracted/dependencies/ ./
COPY --from=build /app/extracted/spring-boot-loader/ ./
COPY --from=build /app/extracted/snapshot-dependencies/ ./
COPY --from=build /app/extracted/application/ ./
ENV JAVA_TOOL_OPTIONS="-XX:MaxRAMPercentage=75"
ENTRYPOINT ["java", "org.springframework.boot.loader.launch.JarLauncher"]

Common pitfalls

Copying the fat JAR as one layer (every code change re-uploads all dependencies).
Fixed -Xmx larger than the container memory limit.
No graceful shutdown, dropping in-flight requests during deploys.

Key points

Buildpacks or layered Dockerfiles
Container-aware JVM memory
Graceful shutdown

Further reading: Spring Boot: Dockerfiles

Practice questions

Why extract the Spring Boot JAR into layers?

Answer

Dependencies rarely change, so their layers are cached and reused; only the small application layer changes per build, speeding builds and deployments.

What does -XX:MaxRAMPercentage=75 do?

Answer

It sizes the JVM heap relative to the container's memory limit, leaving room for metaspace, threads and native memory.