Jib Build

Jib is a set of plugins for Maven and Gradle for building optimized OCI-compliant container images for Java applications without a Docker daemon.

Skaffold can help build artifacts using Jib; Jib builds the container images and then pushes them to the local Docker daemon or to remote registries as instructed by Skaffold.

Skaffold requires using Jib v1.4.0 or later.

Skaffold supports building with Jib

  1. locally and
  2. remotely on Google Cloud Build

Jib Maven and Gradle locally


To use Jib, add a jib field to each artifact you specify in the artifacts part of the build section. context should be a path to your Maven or Gradle project.

The jib type offers the following options:

Option Description Default
project selects which sub-project to build for multi-module builds.
args additional build flags passed to the builder. []
type the Jib builder type; normally determined automatically. Valid types are maven: for Maven. gradle: for Gradle.
fromImage overrides the configured jib base image.

Skaffold’s jib support chooses the underlying builder (Maven or Gradle) based on the presence of standard build files in the artifact’s context directory:

  • Maven: pom.xml, or .mvn directory.
  • Gradle: build.gradle, gradle.properties, settings.gradle, or the Gradle wrapper script (gradlew, gradlew.bat, or gradlew.cmd).

Artifact Dependency

You can define dependency on other artifacts using the requires keyword. This can be useful to specify another artifact image as the fromImage.

  - image: image1 # jib artifact
      fromImage: image2
    - image: image2
  - image: image2 # base image artifact


See the Skaffold-Jib demo project for an example.

Multi-Module Projects

Skaffold can be configured for multi-module projects too. A multi-module project has several modules (Maven terminology) or sub-projects (Gradle terminology) that each produce a separate container image.


To build a Maven multi-module project, first identify the sub-projects (also called modules in Maven) that should produce a container image. Then for each such sub-project:

  • Create a Skaffold artifact in the skaffold.yaml.
  • Set the artifact’s context field to the root project location.
  • Add a jib element and set its project field to the sub-project’s :artifactId, groupId:artifactId, or the relative path to the sub-project within the project.


To build a multi-module project with Gradle, first identify the sub-projects that should produce a container image. Then for each such sub-project:

  • Create a Skaffold artifact in the skaffold.yaml.
  • Set the artifact’s context field to the root project location.
  • Add a jib element and set its project field to the sub-project’s name.

Remotely with Google Cloud Build

Skaffold can build artifacts using Jib remotely on Google Cloud Build.


To configure, add googleCloudBuild to build section to skaffold.yaml. The following options can optionally be configured:

Option Description Default
projectId ID of your Cloud Platform Project. If it is not provided, Skaffold will guess it from the image name. For example, given the artifact image name gcr.io/myproject/image, Skaffold will use the myproject GCP project.
diskSizeGb disk size of the VM that runs the build. See Cloud Build Reference.
machineType type of the VM that runs the build. See Cloud Build Reference.
timeout amount of time (in seconds) that this build should be allowed to run. See Cloud Build Reference.
logging specifies the logging mode. Valid modes are: LOGGING_UNSPECIFIED: The service determines the logging mode. LEGACY: Stackdriver logging and Cloud Storage logging are enabled (default). GCS_ONLY: Only Cloud Storage logging is enabled. See Cloud Build Reference.
logStreamingOption specifies the behavior when writing build logs to Google Cloud Storage. Valid options are: STREAM_DEFAULT: Service may automatically determine build log streaming behavior. STREAM_ON: Build logs should be streamed to Google Cloud Storage. STREAM_OFF: Build logs should not be streamed to Google Cloud Storage; they will be written when the build is completed. See Cloud Build Reference.
dockerImage image that runs a Docker build. See Cloud Builders. gcr.io/cloud-builders/docker
kanikoImage image that runs a Kaniko build. See Cloud Builders. gcr.io/kaniko-project/executor
mavenImage image that runs a Maven build. See Cloud Builders. gcr.io/cloud-builders/mvn
gradleImage image that runs a Gradle build. See Cloud Builders. gcr.io/cloud-builders/gradle
packImage image that runs a Cloud Native Buildpacks build. See Cloud Builders. gcr.io/k8s-skaffold/pack
koImage image that runs a ko build. The image must contain Skaffold, Go, and a shell (runnable as sh) that supports here documents. See Cloud Builders. gcr.io/k8s-skaffold/skaffold
concurrency how many artifacts can be built concurrently. 0 means “no-limit”. 0
workerPool configures a pool of workers to run the build.
region configures the region to run the build. If WorkerPool is configured, the region will be deduced from the WorkerPool configuration. If neither WorkerPool nor Region is configured, the build will be run in global(non-regional). See Cloud Build locations.
platformEmulatorInstallStep specifies a pre-build step to install the required tooling for QEMU emulation on the GoogleCloudBuild containers. This enables performing cross-platform builds on GoogleCloudBuild. If unspecified, Skaffold uses the docker/binfmt image by default.
serviceAccount Google Cloud platform service account used by Cloud Build. If unspecified, it defaults to the Cloud Build service account generated when the Cloud Build API is enabled.


Following configuration instructs skaffold to build gcr.io/k8s-skaffold/project1 with Google Cloud Build using Jib builder:

  - image: gcr.io/k8s-skaffold/project1
    jib: {}
    projectId: YOUR-GCP-PROJECT

Advanced usage

Additional arguments

The jib build artifact supports an args field to provide additional arguments to the Maven or Gradle command-line. For example, a Gradle user may choose to use:

- image: jib-gradle-image
    args: [--no-daemon]

Using the custom builder

Some users may have more complicated builds that may be better suited to using the custom builder. For example, the jib builder normally invokes the prepare-package goal rather than package as Jib packages the .class files rather than package in the jar. But some plugins require the package goal.

- image: jib-gradle-image
    buildCommand: mvn -Dimage=$IMAGE package $(if [ $PUSH_IMAGE = true ]; then echo jib:build; else echo jib:dockerBuild; fi)
      - src/**