Building Docker images with Spring Boot Maven Plugin

Original name

Tvorba docker image pomocí Spring Boot Maven Pluginu


Jiří Pinkas






Czech 🇨🇿



  • ✅ Detailed and comprehensible overview of how to build Docker images using buildpacks. Jib mentioned and offered a simple alternative.

  • ⛔ I still love to write Dockerfiles, it’s fun. Buildpacks are confusing in terms of underlying Java versions (compatibility matrix) and this was not explained.

"Jib is simple and helps for transition to Buildpacks."


  • 2011 - Heroku initiated buildpacks (dynos)

  • 2013 - Docker, Cloud Factory adopted Buildpacks

  • 2014 - Spotify Docker Maven Plugin

  • 2015 - Kubernetes, Cloud Native Computing Foundation (CNCF) established

  • 2018 - Jib 1.0, Cloud Native Buildpacks, CNCF Sandbox

  • 2019 - Podman 1.0.0

  • 2020 - Cloud Native Buildpacks → CNCF Incubation

Dockerfiles are no longer written by hand (though it is good to know how they work), nowadays it is mostly used the Spotify Docker Maven Plugin though there are more advanced tools: Jib plugin is the best choice for a corporate and Native (Spring Boot Maven Plugin) for hipsters.

Spring Boot Maven Plugin is simple to use, the command mvn spring-boot:build-image downloads a builder image where the application is built and the result is a Docker image (it is required to have Docker installed and Docker daemon run) - the resulting image is layered.

It is required to include the plugin:


There is Bellsoft Liberica JDK inside out-of-the-box for an unknown reason, though there are better JDK distributions.

Layered images

Examples from infrequently to frequently changed parts: spring-boot-loader, dependencies, snapshot-dependencies, application Layers enable only the changed parts can be replaced: in case we change the dependencies, then at least the spring-boot-loader can remain the same. If we change the application part, only the application part is sent to the Docker registry or Kubernetes nodes. Layered JARs, images work with JIB or Builpacks and save the time between build and deployment (network traffic between Jenkins, Kubernetes nodes, etc.)


Buildpacks can be browsed at: and the configuration is in the spring-boot-maven-plugin.

OpenJ9 Buildpack


Paketo Builder

The application build happens in the builder image, there are 3 builders out-of-the-box: full, base, and tiny. They differ in the number of libraries installed, though the most used one is tiny. It is possible to create your builder, though it is complicated and worth only for corporates where the implementation of such a builder must be certified security-wise. Jib also allows creating a custom builder more simply.


The plugin also can push into the Docker registry:

  <image> ... </image>

It is dumb the credentials must be specified right in the pom.xml, though it can be passed in the command line:

mvn -Ddocker.username=TODO -Ddocker.password=TODO spring-boot:build-image

Spring Boot 3

The plugin is already built into Spring Boot 3:

      <!-- optional as long as the default values are sensible -->
mvn spring-boot:build-image -Pnative

Paketo buildpacks have also CLI that can build the native images:

pack build test_img --builder=paketobuildpacks/builder:base -e BP_JVM_VERSION=17


It is still possible to write Dockerfiles (a great tutorial is at As long as we are not ready for Buildpacks, Jib is a good choice as it is really easy to use (maven jib:build) and a subsequent transition to buildpacks is not hard. We can also use Jib without Spring Boot. JLink is not a good alternative because it conflicts with the layered JARs concepts, as long as each application has its own JRE, so they cannot share the same layers.

Goals (regardless of the technology)

  • Layered images

  • Smaller images

  • CI/CD image builds

  • Distroless images

Distroless images are without Linux distribution and contain only the application, though there is no bash to use in the container, it is smaller and safe from attacks.