Jib: building Java container images without a Docker daemon

What Jib replaces, and for whom

The README states the problem directly: Jib builds optimized Docker and OCI images for Java applications without a Docker daemon, and without requiring deep mastery of Docker best practices. That sentence describes the audience. If you maintain a Java service and your image build currently means writing a Dockerfile, copying a fat JAR into it, and calling docker build and docker push from CI, Jib is aimed at you. The repository ships it as a Maven plugin, a Gradle plugin, and a Java library called Jib Core, with a separate Jib CLI that the README says is built on Jib Core. The disclaimer at the bottom of the README is worth noticing: this is not an officially supported Google product, despite the GoogleContainerTools organization. That affects who you escalate to when a build breaks, not the licence.

How the layered build actually works

The mechanism is layer separation. The README says that whereas traditionally a Java application is built as a single image layer with the application JAR, Jib's build strategy separates the Java application into multiple layers for more granular incremental builds. Dependencies go in one set of layers, your classes in another. Change a line of code and only the classes layer is rebuilt and pushed; the dependency layers are unchanged and, per the stated goal of reproducibility, rebuilding with the same contents generates the same image. The README lists three goals: fast, reproducible, daemonless. The third is the one with the sharpest consequences. Because there is no daemon, there is also no local image store in the Docker sense. The build either writes to a registry or to a tarball, and Jib talks to the registry API itself.

The base image is a real configuration surface, not a hidden default. The README says the layers are by default layered on top of an OpenJDK base image, and that docs/default_base_image.md covers it, while a custom base image can be configured. The repository layout backs this up: there are separate modules for the build plan (jib-build-plan), shared plugin code (jib-plugins-common), and extension APIs for both the Gradle and Maven plugins, which is how third parties hook into the build without forking it.

Adding Jib to a Maven build and pushing a first image

The README points to the jib-maven-plugin Quickstart for Maven rather than printing the setup on the front page, so the plugin coordinates live in that module's documentation. The top-level README does give the module path, and the repository layout confirms jib-maven-plugin as a top-level entry. The version to pin is the one from the most recent Maven release, v3.5.2-maven, which corresponds to jib-maven-plugin 3.5.2 in the release list. The plugin is published to Maven Central, which the README shows via its Maven Central badge for com.google.cloud.tools:jib-maven-plugin.

For Gradle, the README shows the Gradle Plugin Portal badge for com.google.cloud.tools.jib, and the corresponding release is v3.5.4-gradle, jib-gradle-plugin 3.5.4. The README does not print the plugin block itself; it defers to the jib-gradle-plugin Quickstart. What the README does state plainly is the outcome: you build the image from within Maven or Gradle and push to any registry of your choice, with no Dockerfile and no docker build or docker push call. In both build systems the first push needs registry credentials, and the README routes credential questions to the FAQ in docs/faq.md rather than restating them on the front page. Read that FAQ before the first push; it is the README's designated answer surface for exactly this class of question.

If you would rather not touch your build file at all, the README lists Jib CLI as a command-line interface for building images that uses Jib Core, documented in the jib-cli module. That is the path for a one-off image or for a build system the plugins do not cover.

Where Jib is the wrong tool

No Dockerfile means no RUN. If your image needs to install an OS package, compile a native extension, or run any command at build time inside the image, Jib's model does not express that. The build plan is about assembling layers from what your build already produced, not about executing arbitrary steps in a container filesystem. The workaround is to prepare those artifacts before Jib runs, which pushes the problem back into your build script and loses the readability a Dockerfile gave you.

There is a second boundary that is easy to miss. Jib is a Java tool. The README describes it as building images for your Java applications, and the examples directory is Java frameworks: Spring Boot, Micronaut, Dropwizard, Vert.x, Ktor, Spark Java. A polyglot repository with a Node frontend and a Java backend will need a second image pipeline for the frontend, and the two will not share conventions. The daemonless design also means the registry is a hard dependency for the push path. Where docker build followed by docker push can tolerate a slow or flaky registry because the image exists locally first, Jib's push is the build. The README does not document a rollback story for a partially pushed image.

Jib against a Dockerfile and against rules_docker

The honest comparison is with the Dockerfile you already have, not with a competitor. A Dockerfile gives you a base image, an ordered set of instructions, and full control over what runs. Jib gives you a fixed pipeline with a narrow configuration surface and, in exchange, layer caching that understands Java build outputs. If your Dockerfile is ten lines of FROM, COPY, ENTRYPOINT, you gain reproducibility and lose nothing much. If your Dockerfile installs fonts, generates certificates, or runs a package manager, you are outside Jib's model.

The README itself names the closest alternative: rules_docker, described as a similar existing container image build tool for the Bazel build system. The difference is the build system, not the output. rules_docker integrates with Bazel's dependency graph and hermetic execution model; Jib integrates with Maven and Gradle and their plugin lifecycles. If your repository is already Bazel, rules_docker fits the model you have. If it is Maven or Gradle, adding Bazel to get container builds is a much larger change than adding a plugin.

Maintenance, versions and licence

The last push to the repository was on 2026-07-15, and the most recent releases are v3.5.4-gradle, v3.5.2-maven and v0.28.2-core, all dated 2026-07-14. The Maven and Gradle plugins carry separate version numbers, which matters when you write upgrade notes: a Gradle bump to 3.5.4 does not imply a Maven bump to 3.5.2 at the same time, and the core library has its own 0.x line. Pin the plugin version explicitly in your build file rather than relying on a range, because the plugin controls the produced image format.

The licence is Apache-2.0, which is permissive and includes an explicit patent grant. That is a statement about the licence text, not legal advice; if your organization has a policy on Apache-2.0 dependencies or on the SLSA level 3 badge the README displays, check it against your own requirements. The upgrade cost is mostly in the base image. Because the default is an OpenJDK image and a custom base is configurable, a JDK upgrade on your platform side can mean touching the base image configuration in every module that builds an image, and that is the change most likely to surprise a team that adopted Jib for its low configuration surface.

Editorial conclusion

Adopt Jib if your application is a Java service built by Maven or Gradle and you want image builds inside the same build you already run, with dependencies and classes split into separate layers. Do not adopt it if you need a Dockerfile-shaped build with arbitrary RUN steps, or if your image is not a Java application. Before committing, verify two things against your own registry: that Jib can authenticate to it from your build environment, and that the default OpenJDK base image is one your platform team accepts, since changing it later means editing the base image configuration in every module.

Frequently asked questions

Official sources

1. GoogleContainerTools/jib on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases