Spring Boot Docker: Layered JARs and Jib Builds (2026)

Spring Boot applications, when containerized with Jib, can be built into highly efficient, multi-layered Docker images by leveraging Spring Boot’s "layered JARs" feature.

Let’s see this in action. Imagine a simple Spring Boot app. Its pom.xml (or build.gradle) would have the Jib plugin configured, and the Spring Boot Maven/Gradle plugin would be set up to produce layered JARs:

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <executions>
                <execution>
                    <goals>
                        <goal>repackage</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
        <plugin>
            <groupId>com.google.cloud.tools</groupId>
            <artifactId>jib-maven-plugin</artifactId>
            <version>3.3.1</version> <!-- Use latest version -->
            <configuration>
                <to>
                    <image>my-spring-boot-app:${project.version}</image>
                </to>
                <container>
                    <mainClass>com.example.MyApplication</mainClass>
                </container>
            </configuration>
        </plugin>
    </plugins>
</build>

When you run mvn clean package (or ./gradlew clean build), Jib doesn’t just bundle your entire application into a single layer. Instead, it intelligently separates your application’s dependencies, Spring Boot’s loader, and your application’s code into distinct layers.

Here’s what happens internally:

1. Dependency Layers: Your application’s dependencies are identified and placed into one or more layers. This is crucial because dependencies rarely change.
2. Spring Boot Loader Layer: The Spring Boot loader code, which is responsible for unpacking and running your layered JAR, gets its own layer. This also changes infrequently.
3. Application Code Layer: Your actual application code (your .java files compiled and packaged) forms the final layer. This is the part that changes most often during development.

When Jib builds the Docker image, it pushes these layers independently. The magic happens during subsequent builds. If you only change your application code and not your dependencies, Jib only needs to rebuild and push the application code layer. Docker’s layer caching mechanism then reuses the unchanged dependency and loader layers from the previous build. This dramatically speeds up image builds and reduces the amount of data transferred, especially in CI/CD pipelines.

The primary problem this solves is inefficient Docker image layering. Traditional Spring Boot builds often result in a single "fat JAR" layer. Any change to the application, no matter how small, invalidates that entire layer, forcing Docker to re-download and re-upload everything. Layered JARs, combined with Jib, break this down.

The exact levers you control are primarily within the Jib plugin configuration in your pom.xml or build.gradle. You can specify the target image name, the main class, and even customize the base image. Jib automatically detects the Spring Boot layered JAR structure if the Spring Boot Maven/Gradle plugin is configured correctly to produce them.

If you’re building a Spring Boot application and not using Jib with layered JARs, you’re likely missing out on significant build performance gains. The most surprising thing is how seamlessly Jib integrates with Spring Boot’s layered JAR feature; it doesn’t require any special Jib configuration to "understand" Spring Boot’s layers – it just works by inspecting the JAR’s structure.

The next concept you’ll likely encounter is optimizing the base image for Jib, which can further reduce image size and improve security.