Search for a command to run...
Learn what Jib is, how it works, and when to use Jib vs Dockerfile. A guide with real-world scenarios
Senior Software Engineer. I write about practical tips and epic stories about my experiences in the field of computer science and engineering!
No comments yet. Be the first to comment.
Stop guessing your maximum-pool-size. Learn how to calculate limits backwards from your database
A prod debugging story you’ll probably relate to
The $0 solution to a Distributed Cache Invalidation
Introduction At our current organization, earlier this year as we were looking at the errors at one of our signup API, we observed that nearly 5% of our requests were getting failed, all due to 400 BAD REQUEST errors, and the root cause was traced ba...
When I joined PayPay, one of the first things I tried to understand was how our services were containerized.
A common exercise when joining a new backend team is to look at the Dockerfiles used across services as they often reveal interesting patterns:
Which base images are used
Whether the builds are optimized
If multi-stage builds are implemented
Opportunities for reducing image size or improving caching
So naturally, I went looking for the Dockerfile.
But to my surprise… I couldn't find one.
After digging a bit deeper, I realized something interesting. The project wasn’t using a Dockerfile at all. Instead, it was using Jib.
Imagine shipping a Java microservice where changing a single line of code doesn’t force your CI pipeline to rebuild a massive container image.
That’s exactly what Jib enables.
Jib is an open-source container image builder for Java applications that:
Eliminates the need for a Dockerfile
Does not require a Docker daemon
Integrates directly with Maven and Gradle
Instead of packaging your application as a single fat layer, Jib understands Java project structure and splits your application into optimized layers:
Runtime (base image)
Dependencies
Resources
Application classes
Because of this layered structure, when you change only your application code, only the top layer is rebuilt and pushed.
The result?
⚡ Faster builds
🧱 Better caching
🚀 Simpler CI pipelines
🔧 Less Dockerfile maintenance
In this post, we'll explore how Jib works, when to use it, and how it compares to traditional Dockerfiles.
If you build Java applications and ship containers, you’ve probably written Dockerfiles like this:
FROM eclipse-temurin:17-jre
WORKDIR /app
COPY target/app.jar app.jar
ENTRYPOINT ["java", "-jar", "app.jar"]
It works.
But it’s not optimized for Java.
This is where Jib changes the game.
Before Jib, containerizing Java apps required:
Writing and maintaining Dockerfiles
Installing Docker everywhere (including CI)
Packaging fat JARs
Rebuilding full images for small code changes
Manually optimizing layers
Even a small code change could invalidate caching and rebuild everything.
That’s inefficient.
Jib builds container images by splitting your app into logical layers:
Base Image (JRE)
Dependencies
Resources
Application classes
This means:
If dependencies don’t change → layer reused
If only code changes → only top layer rebuilt
This drastically improves CI speed.
Add this to your pom.xml:
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
<version>3.4.0</version>
<configuration>
<to>
<image>ghcr.io/yourorg/yourapp</image>
</to>
</configuration>
</plugin>
Build & push:
mvn compile jib:build
plugins {
id("com.google.cloud.tools.jib") version "3.4.0"
}
jib {
to {
image = "ghcr.io/yourorg/yourapp"
}
}
Build:
./gradlew jib
This is the real question.
The answer depends on some of the use cases.
Spring Boot
Micronaut
Quarkus
Plain Maven/Gradle apps
Jib integrates directly with your build system.
Jib:
Does not require a Docker daemon
Builds incremental layers
Pushes smaller diffs
Produces reproducible builds
If CI time matters, Jib usually wins.
No Dockerfile. No manual layering. Less DevOps friction.
If you need:
apt-get install
Native libraries
Custom shell scripts
Jib does not support arbitrary RUN commands.
Dockerfile wins here.
If your container includes:
Node + Java
Python + Java
Multiple build tools
Custom entrypoints
Dockerfile provides full flexibility.
Example:
Compile native binaries
Build frontend assets
Run security scans during build
Copy artifacts between stages
Dockerfile is more powerful here.
| Feature | Jib | Dockerfile |
|---|---|---|
| Requires Docker daemon | ❌ No | ✅ Yes |
| Requires Dockerfile | ❌ No | ✅ Yes |
| OS Customization | ❌ Limited | ✅ Full |
| Java Layer Optimization | ✅ Automatic | ❌ Manual |
| CI/CD Simplicity | ✅ High | ⚠️ Medium |
| Multi-language builds | ❌ No | ✅ Yes |
| Learning Curve | Low | Medium |
Kubernetes
GitHub Actions
CI cost matters
👉 Jib is usually the better choice.
Custom Alpine base image
OS packages
Hardening scripts
Multi-stage builds
👉 Dockerfile is better.
Java-only stack
No DevOps team
Want fast pipelines
👉 Jib simplifies everything.
Because Jib separates dependencies and classes:
Code-only changes rebuild in seconds
Docker layer cache invalidation is minimized
CI builds are more predictable
In large microservice ecosystems, this adds up significantly.
Jib is optimized for:
Java developer productivity.
Dockerfile is optimized for:
Infrastructure control.
If you build modern Java microservices → Start with Jib.
If you need deep OS-level control → Use Dockerfile.
Containerization doesn’t have to be complicated. If your stack is Java-centric and you value speed, reproducibility, and developer autonomy, then Jib is one of the smart tools you can adopt today.