Spring Boot Dockerfile Best Practices: Smaller, Faster, Safer Images

#docker #springboot #devops #java

Published 2026-05-21 by Shubham Bhati — Backend Engineer (Java 17, Spring Boot, Microservices).

We've all been there - stuck with a bloated Spring Boot Dockerfile that's slowing down our development cycle and increasing the risk of security vulnerabilities. A well-crafted spring boot dockerfile is essential for ensuring our applications are efficient, scalable, and secure. In our production environment, we've seen firsthand the impact of poorly optimized Docker images, with deployment times increasing by up to 50% due to unnecessary layers and dependencies.

Introduction to Spring Boot Dockerfile Best Practices
Understanding Docker Layers
Multi-Stage Build for Smaller Images
Optimizing Dependencies for Faster Builds
Security Considerations for Spring Boot Docker Images
Common Mistakes to Avoid
Frequently Asked Questions
Conclusion and Next Steps

Introduction to Spring Boot Dockerfile Best Practices

When building a Spring Boot application, it's essential to follow best practices for creating efficient and secure Docker images. One of the key concepts to understand is the use of docker layers, which allows us to break down our image into smaller, reusable components. By doing so, we can reduce the overall size of our image and improve build times. For example, we can use the following Dockerfile to create a basic Spring Boot image:

FROM openjdk:21-jdk-alpine
ARG JAR_FILE=target/myapp.jar
COPY ${JAR_FILE} app.jar
ENTRYPOINT ["java","-jar","/app.jar"]

This Dockerfile uses the openjdk:21-jdk-alpine base image and copies our Spring Boot application jar file into the container.

Understanding Docker Layers

Docker layers are a fundamental concept in Docker, allowing us to build images in a modular and efficient way. Each layer represents a set of changes to the previous layer, and by using docker layers, we can avoid duplicating effort and reduce the overall size of our image. For example, if we have a Dockerfile that installs dependencies, copies our application code, and sets environment variables, each of these steps will create a new layer. We can use the docker history command to view the layers in our image:

docker history -H myapp

This will show us the layers in our image, along with the size of each layer and the command that created it.

Multi-Stage Build for Smaller Images

One of the most effective ways to reduce the size of our Docker image is to use a multi-stage build. This involves creating a separate stage for building our application, and then copying the resulting artifact into a smaller runtime stage. For example:

# Stage 1: Build
FROM maven:3.8.6-jdk-21 as build
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline
COPY src src
RUN mvn package

# Stage 2: Runtime
FROM openjdk:21-jdk-alpine
ARG JAR_FILE=target/myapp.jar
COPY --from=build ${JAR_FILE} app.jar
ENTRYPOINT ["java","-jar","/app.jar"]

This Dockerfile uses two stages: one for building our application using Maven, and another for creating the runtime image. By doing so, we can avoid including unnecessary build dependencies in our runtime image.

Optimizing Dependencies for Faster Builds

When building a Spring Boot application, it's essential to optimize our dependencies to reduce build times. One way to do this is to use the spring-boot-starter dependencies, which include only the necessary dependencies for our application. For example:

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web:3.2.0'
}

This will include only the necessary dependencies for a basic Spring Boot web application. We can also use tools like Baeldung's Dependency Analyzer to identify and remove unnecessary dependencies.

Security Considerations for Spring Boot Docker Images

When creating a Spring Boot Docker image, it's essential to consider security best practices. One way to do this is to use a non-root user to run our application, which can help prevent privilege escalation attacks. For example:

RUN groupadd -r spring && useradd -r -g spring spring
USER spring:spring

This will create a new user and group called spring, and then switch to that user to run our application. We can also use tools like OWASP's Docker Security Cheat Sheet to identify and mitigate security vulnerabilities.

Common Mistakes

Here are some common mistakes to avoid when creating a Spring Boot Dockerfile:

Using an unnecessary base image
Including unnecessary dependencies
Not using a non-root user to run the application
Not optimizing Docker layers
Not using a multi-stage build

Frequently Asked Questions

What is the best base image to use for a Spring Boot application?

The best base image to use for a Spring Boot application is openjdk:21-jdk-alpine, which includes the OpenJDK 21 runtime and the Alpine Linux distribution.

How can I optimize my Docker layers for better performance?

To optimize your Docker layers, use the docker history command to view the layers in your image, and then use the --squash flag to combine unnecessary layers.

What is the difference between a single-stage and multi-stage build?

A single-stage build involves creating a single stage for building and running our application, while a multi-stage build involves creating separate stages for building and running our application.

How can I ensure my Spring Boot Docker image is secure?

To ensure your Spring Boot Docker image is secure, use a non-root user to run your application, and follow security best practices like those outlined in the Spring Security documentation.

Conclusion and Next Steps

In conclusion, creating an efficient and secure Spring Boot Dockerfile requires careful consideration of several factors, including Docker layers, dependencies, and security best practices. By following the tips and best practices outlined in this article, we can create smaller, faster, and safer images that improve our development cycle and reduce the risk of security vulnerabilities. To learn more about Spring Boot and Docker, check out the official Spring Boot documentation and the Docker documentation.