Back to Guides
Edit this Page

Container Images

Quarkus provides extensions for building (and pushing) container images. Currently, it supports:

Container Image extensions

Jib

The extension quarkus-container-image-jib is powered by Jib for performing container image builds. The major benefit of using Jib with Quarkus is that all the dependencies (everything found under target/lib) are cached in a different layer than the actual application making rebuilds really fast and small (when it comes to pushing). Another important benefit of using this extension is that it provides the ability to create a container image without having to have any dedicated client side tooling (like Docker) or running daemon processes (like the Docker daemon) when all that is needed is the ability to push to a container image registry.

To use this feature, add the following extension to your project:

CLI
quarkus extension add container-image-jib
Maven
./mvnw quarkus:add-extension -Dextensions='container-image-jib'
Gradle
./gradlew addExtension --extensions='container-image-jib'
In situations where all that is needed to build a container image and no push to a registry is necessary (essentially by having set quarkus.container-image.build=true and left quarkus.container-image.push unset - it defaults to false), then this extension creates a container image and registers it with the Docker daemon. This means that although Docker isn’t used to build the image, it is nevertheless necessary. Also note that using this mode, the built container image will show up when executing docker images.

Including extra files

There are cases when additional files (other than ones produced by the Quarkus build) need to be added to a container image. To support these cases, Quarkus copies any file under src/main/jib into the built container image (which is essentially the same idea that the Jib Maven and Gradle plugins support). For example, the presence of src/main/jib/foo/bar would result in /foo/bar being added into the container filesystem.

JVM Debugging

There are cases where the built container image may need to have Java debugging conditionally enabled at runtime.

When the base image has not been changed (and therefore ubi9/openjdk-17-runtime, or ubi9/openjdk-21-runtime is used), then the quarkus.jib.jvm-additional-arguments configuration property can be used in order to make the JVM listen on the debug port at startup.

The exact configuration is:

quarkus.jib.jvm-additional-arguments=-agentlib:jdwp=transport=dt_socket\\,server=y\\,suspend=n\\,address=*:5005

Other base images might provide launch scripts that enable debugging when an environment variable is set, in which case you would set than environment variable when launching the container.

Custom Entrypoint

The quarkus.jib.jvm-entrypoint configuration property can be used to completely override the container entry point and can thus be used to either hard code the JVM debug configuration or point to a script that handles the details.

For example, if the base images ubi9/openjdk-17-runtime or ubi9/openjdk-21-runtime are used to build the container, the entry point can be hard-coded on the application properties file.

Example application.properties
quarkus.jib.jvm-entrypoint=java,-Dcustom.param=custom_value,-jar,quarkus-run.jar

Or a custom start-up script can be created and referenced on the properties file. This approach works better if there’s a need to set application params using environment variables:

Example application.properties
quarkus.jib.jvm-entrypoint=/bin/sh,run-java.sh
Example src/main/jib/home/jboss/run-java.sh
java \
  -Djavax.net.ssl.trustStore=/deployments/truststore \
  -Djavax.net.ssl.trustStorePassword="$TRUST_STORE_PASSWORD" \
  -jar quarkus-run.jar
/home/jboss is the WORKDIR for all quarkus binaries in the base images ubi9/openjdk-17-runtime and ubi9/openjdk-21-runtime (Dockerfile for ubi9/openjdk-17-runtime)

Multi-module projects and layering

When building a multi-module project containing a Quarkus application as one module and various supporting project dependencies as other modules, Quarkus supports placing these supporting modules in a separate container image layer from the rest of the application dependencies, with the expectation that these supporting modules will change more frequently than the regular application dependencies - thus making a rebuild faster if the application dependencies have not changed.

To enable this feature, the property quarkus.bootstrap.workspace-discovery needs to be set to true either as a system property when invoking the build tool, either as a build tool property. Setting this property in application.properties will not work because this property needs to be known very early on in the build process.

AppCDS

Quarkus supports generating and including an Application Class Data Sharing archive when generating a container image using Jib. See the AppCDS documentation for more details.

Docker

The extension quarkus-container-image-docker is using the Docker binary and the generated Dockerfiles under src/main/docker in order to perform Docker builds.

To use this feature, add the following extension to your project.

CLI
quarkus extension add container-image-docker
Maven
./mvnw quarkus:add-extension -Dextensions='container-image-docker'
Gradle
./gradlew addExtension --extensions='container-image-docker'

The quarkus-container-image-docker extension is capable of creating multi-platform (or multi-arch) images using docker buildx build. See the quarkus.docker.buildx.* configuration items in the Docker Options section below.

docker buildx build ONLY supports loading the result of a build to docker images when building for a single platform. Therefore, if you specify more than one argument in the quarkus.docker.buildx.platform property, the resulting images will not be loaded into docker images. If quarkus.docker.buildx.platform is omitted or if only a single platform is specified, it will then be loaded into docker images.

This means that if you want to build images for more than one platform at a time (i.e. quarkus.docker.buildx.platform=linux/amd64,linux/arm64), you need to push the images (quarkus.container-image.push=true) directly as part of the build process. Docker buildx does not support loading into the local registry when building multi-platform images.

Podman

The extension quarkus-container-image-podman uses Podman and the generated Dockerfiles under src/main/docker in order to perform container builds.

To use this feature, add the following extension to your project.

CLI
quarkus extension add container-image-podman
Maven
./mvnw quarkus:add-extension -Dextensions='container-image-podman'
Gradle
./gradlew addExtension --extensions='container-image-podman'
When to use Docker vs Podman extension

The Docker extension is and has always been backwards-compatible with Podman because Podman exposes a Docker-compatible API. You can build container images with Podman using the Docker extension (see the Using Podman with Quarkus guide).

Use either the quarkus-container-image-docker or quarkus-container-image-podman extension when doing things specific to either Docker or Podman, respectively.

For example, building multi-platform images is implemented differently for Docker and Podman. Docker uses the buildx plugin whereas Podman can build multi-platform images natively. Because of this, you would need to use the specific extension to perform that function.

OpenShift

The extension quarkus-container-image-openshift is using OpenShift binary builds in order to perform container builds inside the OpenShift cluster. The idea behind the binary build is that you just upload the artifact and its dependencies to the cluster and during the build they will be merged to a builder image (defaults to fabric8/s2i-java).

The benefit of this approach, is that it can be combined with OpenShift’s DeploymentConfig that makes it easy to roll out changes to the cluster.

To use this feature, add the following extension to your project.

CLI
quarkus extension add container-image-openshift
Maven
./mvnw quarkus:add-extension -Dextensions='container-image-openshift'
Gradle
./gradlew addExtension --extensions='container-image-openshift'

OpenShift builds require creating a BuildConfig and two ImageStream resources, one for the builder image and one for the output image. The creation of such objects is being taken care of by the Quarkus Kubernetes extension.

Buildpack

The extension quarkus-container-image-buildpack is using buildpacks in order to perform container image builds. Under the hood buildpacks will use a Docker daemon for the actual build. While buildpacks support alternatives to Docker, this extension will only work with Docker.

Additionally, the user will have to configure which build image to use (no default image is provided). For example:

quarkus.buildpack.jvm-builder-image=<jvm builder image>

or for native:

quarkus.buildpack.native-builder-image=<native builder image>

To use this feature, add the following extension to your project.

CLI
quarkus extension add container-image-buildpack
Maven
./mvnw quarkus:add-extension -Dextensions='container-image-buildpack'
Gradle
./gradlew addExtension --extensions='container-image-buildpack'
When using the buildpack container image extension it is strongly advised to avoid adding quarkus.container-image.build=true in your properties configuration as it might trigger nesting builds within builds. It’s preferable to pass it as an option to the build command instead.

Building

To build a container image for your project, quarkus.container-image.build=true needs to be set using any of the ways that Quarkus supports.

CLI
quarkus build quarkus deploy openshift
Maven
./mvnw install -Dquarkus.container-image.build=true
Gradle
./gradlew build -Dquarkus.container-image.build=true
If you ever want to build a native container image and already have an existing native image you can set -Dquarkus.native.reuse-existing=true and the native image build will not be re-run.

Using @QuarkusIntegrationTest

To run tests on the resulting image, quarkus.container-image.build=true needs to be set using any of the ways that Quarkus supports.

Maven
./mvnw verify -Dquarkus.container-image.build=true
Gradle
./gradlew quarkusIntTest -Dquarkus.container-image.build=true

Pushing

To push a container image for your project, quarkus.container-image.push=true needs to be set using any of the ways that Quarkus supports.

CLI
quarkus build quarkus deploy openshift
Maven
./mvnw install -Dquarkus.container-image.push=true
Gradle
./gradlew build -Dquarkus.container-image.push=true
If no registry is set (using quarkus.container-image.registry) then docker.io will be used as the default.

Selecting among multiple extensions

It does not make sense to use multiple extension as part of the same build. When multiple container image extensions are present, an error will be raised to inform the user. The user can either remove the unneeded extensions or select one using application.properties.

For example, if both container-image-docker and container-image-podman are present and the user needs to use container-image-docker:

quarkus.container-image.builder=docker

Integrating with systemd-notify

If you are building a container image in order to deploy your Quarkus application as a Linux service with Podman and Systemd, you might want to consider including the Quarkus Systemd Notify Extension as part of your application, with:

CLI
quarkus extension add io.quarkiverse.systemd.notify:quarkus-systemd-notify
Maven
./mvnw quarkus:add-extension -Dextensions='io.quarkiverse.systemd.notify:quarkus-systemd-notify'
Gradle
./gradlew addExtension --extensions='io.quarkiverse.systemd.notify:quarkus-systemd-notify'

Customizing

The following properties can be used to customize the container image build process.

Container Image Options

Configuration property fixed at build time - All other configuration properties are overridable at runtime

Configuration property

Type

Default

quarkus.container-image.group

The group the container image will be part of

Environment variable: QUARKUS_CONTAINER_IMAGE_GROUP

Show more

string

quarkus.container-image.name

The name of the container image. If not set defaults to the application name

Environment variable: QUARKUS_CONTAINER_IMAGE_NAME

Show more

string

${quarkus.application.name:unset}

quarkus.container-image.tag

The tag of the container image. If not set defaults to the application version

Environment variable: QUARKUS_CONTAINER_IMAGE_TAG

Show more

string

${quarkus.application.version:latest}

quarkus.container-image.additional-tags

Additional tags of the container image.

Environment variable: QUARKUS_CONTAINER_IMAGE_ADDITIONAL_TAGS

Show more

list of string

quarkus.container-image.labels."label-name"

Custom labels to add to the generated image.

Environment variable: QUARKUS_CONTAINER_IMAGE_LABELS__LABEL_NAME_

Show more

Map<String,String>

quarkus.container-image.registry

The container registry to use

Environment variable: QUARKUS_CONTAINER_IMAGE_REGISTRY

Show more

string

quarkus.container-image.image

Represents the entire image string. If set, then group, name, registry, tags, additionalTags are ignored

Environment variable: QUARKUS_CONTAINER_IMAGE_IMAGE

Show more

string

quarkus.container-image.username

The username to use to authenticate with the registry where the built image will be pushed

Environment variable: QUARKUS_CONTAINER_IMAGE_USERNAME

Show more

string

quarkus.container-image.password

The password to use to authenticate with the registry where the built image will be pushed

Environment variable: QUARKUS_CONTAINER_IMAGE_PASSWORD

Show more

string

quarkus.container-image.insecure

Whether or not insecure registries are allowed

Environment variable: QUARKUS_CONTAINER_IMAGE_INSECURE

Show more

boolean

false

quarkus.container-image.build

Whether or not a image build will be performed.

Environment variable: QUARKUS_CONTAINER_IMAGE_BUILD

Show more

boolean

quarkus.container-image.push

Whether or not an image push will be performed.

Environment variable: QUARKUS_CONTAINER_IMAGE_PUSH

Show more

boolean

quarkus.container-image.builder

The name of the container image extension to use (e.g. docker, podman, jib, s2i). The option will be used in case multiple extensions are present.

Environment variable: QUARKUS_CONTAINER_IMAGE_BUILDER

Show more

string

Using CI Environments

Various CI environments provide a ready to use container-image registry which can be combined with the container-image Quarkus extensions in order to effortlessly create and push a Quarkus application to said registry.

For example, GitLab provides such a registry and in the provided CI environment, makes available the CI_REGISTRY_IMAGE environment variable (see GitLab’s documentation) for more information), which can be used in Quarkus like so:

quarkus.container-image.image=${CI_REGISTRY_IMAGE}
See this for more information on how to combine properties with environment variables.

Jib Options

In addition to the generic container image options, the container-image-jib also provides the following options:

Configuration property fixed at build time - All other configuration properties are overridable at runtime

Configuration property

Type

Default

quarkus.jib.base-jvm-image

The base image to be used when a container image is being produced for the jar build. When the application is built against Java 21 or higher, registry.access.redhat.com/ubi9/openjdk-21-runtime:1.21 is used as the default. Otherwise registry.access.redhat.com/ubi9/openjdk-17-runtime:1.21 is used as the default.

Environment variable: QUARKUS_JIB_BASE_JVM_IMAGE

Show more

string

quarkus.jib.base-native-image

The base image to be used when a container image is being produced for the native binary build. The default is "quay.io/quarkus/ubi9-quarkus-micro-image:2.0". You can also use "registry.access.redhat.com/ubi9/ubi-minimal" which is a bigger base image, but provide more built-in utilities such as the microdnf package manager.

Environment variable: QUARKUS_JIB_BASE_NATIVE_IMAGE

Show more

string

quay.io/quarkus/ubi9-quarkus-micro-image:2.0

quarkus.jib.jvm-arguments

The JVM arguments to pass to the JVM when starting the application

Environment variable: QUARKUS_JIB_JVM_ARGUMENTS

Show more

list of string

-Djava.util.logging.manager=org.jboss.logmanager.LogManager

quarkus.jib.jvm-additional-arguments

Additional JVM arguments to pass to the JVM when starting the application

Environment variable: QUARKUS_JIB_JVM_ADDITIONAL_ARGUMENTS

Show more

list of string

quarkus.jib.native-arguments

Additional arguments to pass when starting the native application

Environment variable: QUARKUS_JIB_NATIVE_ARGUMENTS

Show more

list of string

quarkus.jib.jvm-entrypoint

If this is set, then it will be used as the entry point of the container image. There are a few things to be aware of when creating an entry point

  • Entrypoint "INHERIT" means to inherit entrypoint from base image, jvmArguments field is used for arguments

  • A valid entrypoint is jar package specific (see quarkus.package.jar.type)

  • A valid entrypoint depends on the location of both the launching scripts and the application jar file. To that end it’s helpful to remember that when fast-jar packaging is used (the default), all necessary application jars are added to the /work directory and that the same directory is also used as the working directory. When legacy-jar or uber-jar are used, the application jars are unpacked under the /app directory and that directory is used as the working directory.

  • Even if the jvmArguments field is set, it is ignored completely unless entrypoint is "INHERIT"

When this is not set, a proper default entrypoint will be constructed. As a final note, a very useful tool for inspecting container image layers that can greatly aid when debugging problems with endpoints is dive

Environment variable: QUARKUS_JIB_JVM_ENTRYPOINT

Show more

list of string

quarkus.jib.native-entrypoint

If this is set, then it will be used as the entry point of the container image. There are a few things to be aware of when creating an entry point

  • Entrypoint "INHERIT" means to inherit entrypoint from base image, nativeArguments field is used for arguments

  • A valid entrypoint depends on the location of both the launching scripts and the native binary file. To that end it’s helpful to remember that the native application is added to the /work directory and that and the same directory is also used as the working directory

  • Even if the nativeArguments field is set, it is ignored completely unless entrypoint is "INHERIT"

When this is not set, a proper default entrypoint will be constructed. As a final note, a very useful tool for inspecting container image layers that can greatly aid when debugging problems with endpoints is dive

Environment variable: QUARKUS_JIB_NATIVE_ENTRYPOINT

Show more

list of string

quarkus.jib.environment-variables."environment-variable-name"

Environment variables to add to the container image

Environment variable: QUARKUS_JIB_ENVIRONMENT_VARIABLES__ENVIRONMENT_VARIABLE_NAME_

Show more

Map<String,String>

quarkus.jib.base-registry-username

The username to use to authenticate with the registry used to pull the base JVM image

Environment variable: QUARKUS_JIB_BASE_REGISTRY_USERNAME

Show more

string

quarkus.jib.base-registry-password

The password to use to authenticate with the registry used to pull the base JVM image

Environment variable: QUARKUS_JIB_BASE_REGISTRY_PASSWORD

Show more

string

quarkus.jib.ports

The ports to expose

Environment variable: QUARKUS_JIB_PORTS

Show more

list of int

${quarkus.http.port:8080}

quarkus.jib.user

The user to use in generated image

Environment variable: QUARKUS_JIB_USER

Show more

string

quarkus.jib.working-directory

The working directory to use in the generated image. The default value is chosen to work in accordance with the default base image.

Environment variable: QUARKUS_JIB_WORKING_DIRECTORY

Show more

string

/home/jboss

quarkus.jib.always-cache-base-image

Controls the optimization which skips downloading base image layers that exist in a target registry. If the user does not set this property, then read as false. If true, base image layers are always pulled and cached. If false, base image layers will not be pulled/cached if they already exist on the target registry.

Environment variable: QUARKUS_JIB_ALWAYS_CACHE_BASE_IMAGE

Show more

boolean

false

quarkus.jib.platforms

List of target platforms. Each platform is defined using the pattern:

<os>|<arch>[/variant]|<os>/<arch>[/variant]

for example:

linux/amd64,linux/arm64/v8

If not specified, OS default is linux and architecture default is amd64. If more than one platform is configured, it is important to note that the base image has to be a Docker manifest or an OCI image index containing a version of each chosen platform. The feature does not work with native images, as cross-compilation is not supported. This configuration is based on an incubating feature of Jib. See Jib FAQ for more information.

Environment variable: QUARKUS_JIB_PLATFORMS

Show more

list of string

quarkus.jib.image-digest-file

The path of a file in which the digest of the generated image will be written. If the path is relative, the base path is the output directory of the build tool.

Environment variable: QUARKUS_JIB_IMAGE_DIGEST_FILE

Show more

string

jib-image.digest

quarkus.jib.image-id-file

The path of a file in which the id of the generated image will be written. If the path is relative, the base path is the output directory of the build tool.

Environment variable: QUARKUS_JIB_IMAGE_ID_FILE

Show more

string

jib-image.id

quarkus.jib.offline-mode

Whether, or not to operate offline.

Environment variable: QUARKUS_JIB_OFFLINE_MODE

Show more

boolean

false

quarkus.jib.docker-executable-name

Name of binary used to execute the docker commands. This is only used by Jib when the container image is being built locally.

Environment variable: QUARKUS_JIB_DOCKER_EXECUTABLE_NAME

Show more

string

quarkus.jib.docker-environment."environment-variable-name"

Sets environment variables used by the Docker executable. This is only used by Jib when the container image is being built locally.

Environment variable: QUARKUS_JIB_DOCKER_ENVIRONMENT__ENVIRONMENT_VARIABLE_NAME_

Show more

Map<String,String>

quarkus.jib.use-current-timestamp

Whether to set the creation time to the actual build time. Otherwise, the creation time will be set to the Unix epoch (00:00:00, January 1st, 1970 in UTC). See Jib FAQ for more information

Environment variable: QUARKUS_JIB_USE_CURRENT_TIMESTAMP

Show more

boolean

true

quarkus.jib.use-current-timestamp-file-modification

Whether to set the modification time (last modified time) of the files put by Jib in the image to the actual build time. Otherwise, the modification time will be set to the Unix epoch (00:00:00, January 1st, 1970 in UTC). If the modification time is constant (flag is set to false so Unix epoch is used) across two consecutive builds, the docker layer sha256 digest will be different only if the actual files added by Jib to the docker layer were changed. More exactly, having 2 consecutive builds will generate different docker layers only if the actual content of the files within the docker layer was changed. If the current timestamp is used the sha256 digest of the docker layer will always be different even if the content of the files didn’t change.

Environment variable: QUARKUS_JIB_USE_CURRENT_TIMESTAMP_FILE_MODIFICATION

Show more

boolean

true

quarkus.jib.base-image-layers-cache

The directory to use for caching base image layers. If not specified, the Jib default directory is used.

Environment variable: QUARKUS_JIB_BASE_IMAGE_LAYERS_CACHE

Show more

string

quarkus.jib.application-layers-cache

The directory to use for caching application layers. If not specified, the Jib default directory is used.

Environment variable: QUARKUS_JIB_APPLICATION_LAYERS_CACHE

Show more

string

Docker Options

In addition to the generic container image options, the container-image-docker also provides the following options:

Configuration property fixed at build time - All other configuration properties are overridable at runtime

Configuration property

Type

Default

quarkus.docker.dockerfile-jvm-path

Path to the JVM Dockerfile. If set to an absolute path then the absolute path will be used, otherwise the path will be considered relative to the project root. If not set src/main/docker/Dockerfile.jvm will be used.

Environment variable: QUARKUS_DOCKER_DOCKERFILE_JVM_PATH

Show more

string

src/main/docker/Dockerfile.jvm

quarkus.docker.dockerfile-native-path

Path to the native Dockerfile. If set to an absolute path then the absolute path will be used, otherwise the path will be considered relative to the project root. If not set src/main/docker/Dockerfile.native will be used.

Environment variable: QUARKUS_DOCKER_DOCKERFILE_NATIVE_PATH

Show more

string

src/main/docker/Dockerfile.native

quarkus.docker.build-args."arg-name"

Build args passed to docker via --build-arg

Environment variable: QUARKUS_DOCKER_BUILD_ARGS__ARG_NAME_

Show more

Map<String,String>

quarkus.docker.cache-from

Images to consider as cache sources. Values are passed to docker build/podman build via the cache-from option

Environment variable: QUARKUS_DOCKER_CACHE_FROM

Show more

list of string

quarkus.docker.network

The networking mode for the RUN instructions during build

Environment variable: QUARKUS_DOCKER_NETWORK

Show more

string

quarkus.docker.executable-name

Name of binary used to execute the docker/podman commands. This setting can override the global container runtime detection.

Environment variable: QUARKUS_DOCKER_EXECUTABLE_NAME

Show more

string

quarkus.docker.additional-args

Additional arbitrary arguments passed to the executable when building the container image.

Environment variable: QUARKUS_DOCKER_ADDITIONAL_ARGS

Show more

list of string

Configuration for Docker Buildx options

Type

Default

quarkus.docker.buildx.platform

Which platform(s) to target during the build. See https://docs.docker.com/engine/reference/commandline/buildx_build/#platform

Environment variable: QUARKUS_DOCKER_BUILDX_PLATFORM

Show more

list of string

quarkus.docker.buildx.output

Sets the export action for the build result. See https://docs.docker.com/engine/reference/commandline/buildx_build/#output. Note that any filesystem paths need to be absolute paths, not relative from where the command is executed from.

Environment variable: QUARKUS_DOCKER_BUILDX_OUTPUT

Show more

string

quarkus.docker.buildx.progress

Set type of progress output (auto, plain, tty). Use plain to show container output (default “auto”). See https://docs.docker.com/engine/reference/commandline/buildx_build/#progress

Environment variable: QUARKUS_DOCKER_BUILDX_PROGRESS

Show more

string

Podman Options

In addition to the generic container image options, the container-image-podman also provides the following options:

Configuration property fixed at build time - All other configuration properties are overridable at runtime

Configuration property

Type

Default

quarkus.podman.dockerfile-jvm-path

Path to the JVM Dockerfile. If set to an absolute path then the absolute path will be used, otherwise the path will be considered relative to the project root. If not set src/main/docker/Dockerfile.jvm will be used.

Environment variable: QUARKUS_PODMAN_DOCKERFILE_JVM_PATH

Show more

string

src/main/docker/Dockerfile.jvm

quarkus.podman.dockerfile-native-path

Path to the native Dockerfile. If set to an absolute path then the absolute path will be used, otherwise the path will be considered relative to the project root. If not set src/main/docker/Dockerfile.native will be used.

Environment variable: QUARKUS_PODMAN_DOCKERFILE_NATIVE_PATH

Show more

string

src/main/docker/Dockerfile.native

quarkus.podman.build-args."arg-name"

Build args passed to docker via --build-arg

Environment variable: QUARKUS_PODMAN_BUILD_ARGS__ARG_NAME_

Show more

Map<String,String>

quarkus.podman.cache-from

Images to consider as cache sources. Values are passed to docker build/podman build via the cache-from option

Environment variable: QUARKUS_PODMAN_CACHE_FROM

Show more

list of string

quarkus.podman.network

The networking mode for the RUN instructions during build

Environment variable: QUARKUS_PODMAN_NETWORK

Show more

string

quarkus.podman.executable-name

Name of binary used to execute the docker/podman commands. This setting can override the global container runtime detection.

Environment variable: QUARKUS_PODMAN_EXECUTABLE_NAME

Show more

string

quarkus.podman.additional-args

Additional arbitrary arguments passed to the executable when building the container image.

Environment variable: QUARKUS_PODMAN_ADDITIONAL_ARGS

Show more

list of string

quarkus.podman.platform

Which platform(s) to target during the build. See https://docs.podman.io/en/latest/markdown/podman-build.1.html#platform-os-arch-variant

Environment variable: QUARKUS_PODMAN_PLATFORM

Show more

list of string

quarkus.podman.tls-verify

Require HTTPS and verify certificates when contacting registries

Environment variable: QUARKUS_PODMAN_TLS_VERIFY

Show more

boolean

true

OpenShift Options

In addition to the generic container image options, the container-image-openshift also provides the following options:

Configuration property fixed at build time - All other configuration properties are overridable at runtime

Configuration property

Type

Default

quarkus.openshift.build-strategy

The build config strategy to use.

Environment variable: QUARKUS_OPENSHIFT_BUILD_STRATEGY

Show more

binary, docker

binary

quarkus.openshift.base-jvm-image

The base image to be used when a container image is being produced for the jar build. The value of this property is used to create an ImageStream for the builder image used in the Openshift build. When it references images already available in the internal Openshift registry, the corresponding streams are used instead. When the application is built against Java 21 or higher, registry.access.redhat.com/ubi9/openjdk-21:1.21 is used as the default. Otherwise registry.access.redhat.com/ubi9/openjdk-17:1.21 is used as the default.

Environment variable: QUARKUS_OPENSHIFT_BASE_JVM_IMAGE

Show more

string

quarkus.openshift.base-native-image

The base image to be used when a container image is being produced for the native binary build. The value of this property is used to create an ImageStream for the builder image used in the Openshift build. When it references images already available in the internal Openshift registry, the corresponding streams are used instead.

Environment variable: QUARKUS_OPENSHIFT_BASE_NATIVE_IMAGE

Show more

string

quay.io/quarkus/ubi9-quarkus-native-binary-s2i:2.0

quarkus.openshift.jvm-dockerfile

The default Dockerfile to use for jvm builds

Environment variable: QUARKUS_OPENSHIFT_JVM_DOCKERFILE

Show more

string

src/main/docker/Dockerfile.jvm

quarkus.openshift.native-dockerfile

The default Dockerfile to use for native builds

Environment variable: QUARKUS_OPENSHIFT_NATIVE_DOCKERFILE

Show more

string

src/main/docker/Dockerfile.native

quarkus.openshift.jvm-arguments

The JVM arguments to pass to the JVM when starting the application

Environment variable: QUARKUS_OPENSHIFT_JVM_ARGUMENTS

Show more

list of string

quarkus.openshift.native-arguments

Additional arguments to pass when starting the native application

Environment variable: QUARKUS_OPENSHIFT_NATIVE_ARGUMENTS

Show more

list of string

quarkus.openshift.jar-directory

The directory where the jar is added during the assemble phase. This is dependent on the S2I image and should be supplied if a non default image is used.

Environment variable: QUARKUS_OPENSHIFT_JAR_DIRECTORY

Show more

string

quarkus.openshift.jar-file-name

The resulting filename of the jar in the S2I image. This option may be used if the selected S2I image uses a fixed name for the jar.

Environment variable: QUARKUS_OPENSHIFT_JAR_FILE_NAME

Show more

string

quarkus.openshift.native-binary-directory

The directory where the native binary is added during the assemble phase. This is dependent on the S2I image and should be supplied if a non-default image is used.

Environment variable: QUARKUS_OPENSHIFT_NATIVE_BINARY_DIRECTORY

Show more

string

quarkus.openshift.native-binary-file-name

The resulting filename of the native binary in the S2I image. This option may be used if the selected S2I image uses a fixed name for the native binary.

Environment variable: QUARKUS_OPENSHIFT_NATIVE_BINARY_FILE_NAME

Show more

string

quarkus.openshift.build-timeout

The build timeout.

Environment variable: QUARKUS_OPENSHIFT_BUILD_TIMEOUT

Show more

Duration 

PT5M

quarkus.openshift.build-log-level

The log level of OpenShift build log.

Environment variable: QUARKUS_OPENSHIFT_BUILD_LOG_LEVEL

Show more

fatal, error, warn, info, debug, trace

info

quarkus.openshift.image-push-secret

The image push secret to use for pushing to external registries. (see: https://cloud.redhat.com/blog/pushing-application-images-to-an-external-registry)

Environment variable: QUARKUS_OPENSHIFT_IMAGE_PUSH_SECRET

Show more

string
About the Duration format

To write duration values, use the standard java.time.Duration format. See the Duration#parse() Java API documentation for more information.

You can also use a simplified format, starting with a number:

  • If the value is only a number, it represents time in seconds.

  • If the value is a number followed by ms, it represents time in milliseconds.

In other cases, the simplified format is translated to the java.time.Duration format for parsing:

  • If the value is a number followed by h, m, or s, it is prefixed with PT.

  • If the value is a number followed by d, it is prefixed with P.

Buildpack Options

In addition to the generic container image options, the container-image-buildpack also provides the following options:

Configuration property fixed at build time - All other configuration properties are overridable at runtime

Configuration property

Type

Default

quarkus.buildpack.jvm-builder-image

The buildpacks builder image to use when building the project in jvm mode.

Environment variable: QUARKUS_BUILDPACK_JVM_BUILDER_IMAGE

Show more

string

paketocommunity/builder-ubi-base:latest

quarkus.buildpack.native-builder-image

The buildpacks builder image to use when building the project in native mode.

Environment variable: QUARKUS_BUILDPACK_NATIVE_BUILDER_IMAGE

Show more

string

quarkus.buildpack.lifecycle-image

The lifecycle image to use when building the project This is optional, but can be used to override the lifecycle present within a builder image.

Environment variable: QUARKUS_BUILDPACK_LIFECYCLE_IMAGE

Show more

string

quarkus.buildpack.platform-level

The platform level to force for the build. Normally the platform level is determined from the intersection of the builder image supported levels, and the platform implementation supported levels. Sometimes it can be beneficial to force the platform to a particular version to force behavior during the build.

Environment variable: QUARKUS_BUILDPACK_PLATFORM_LEVEL

Show more

string

quarkus.buildpack.trust-builder-image

Should the builder image be 'trusted' ? Trusted builders are allowed to attempt to use the creator lifecycle, which runs all the build phases within a single container. This is only possible for builders that do not use extensions. Running all phases in one container exposes some phases to information they may not see normally with a container-per-phase.

Environment variable: QUARKUS_BUILDPACK_TRUST_BUILDER_IMAGE

Show more

boolean

quarkus.buildpack.builder-env."environment-variable-name"

Environment key/values to pass to buildpacks.

Environment variable: QUARKUS_BUILDPACK_BUILDER_ENV__ENVIRONMENT_VARIABLE_NAME_

Show more

Map<String,String>

quarkus.buildpack.registry-user."registry-host"

Usernames to use with registry hosts

Environment variable: QUARKUS_BUILDPACK_REGISTRY_USER__REGISTRY_HOST_

Show more

Map<String,String>

quarkus.buildpack.registry-password."registry-host"

Passwords to use with registry hosts

Environment variable: QUARKUS_BUILDPACK_REGISTRY_PASSWORD__REGISTRY_HOST_

Show more

Map<String,String>

quarkus.buildpack.registry-token."registry-host"

Tokens to use with registry hosts

Environment variable: QUARKUS_BUILDPACK_REGISTRY_TOKEN__REGISTRY_HOST_

Show more

Map<String,String>

quarkus.buildpack.run-image

The buildpacks run image to use when building the project When not supplied, the run image is determined by the builder image. If extensions are used by the builder image, they may override the run image.

Environment variable: QUARKUS_BUILDPACK_RUN_IMAGE

Show more

string

quarkus.buildpack.pull-timeout-seconds

Initial pull timeout for builder/run images, in seconds

Environment variable: QUARKUS_BUILDPACK_PULL_TIMEOUT_SECONDS

Show more

int

300

quarkus.buildpack.pull-timeout-increase-seconds

Increase pull timeout for builder/run images after failure, in seconds

Environment variable: QUARKUS_BUILDPACK_PULL_TIMEOUT_INCREASE_SECONDS

Show more

int

15

quarkus.buildpack.pull-retry-count

How many times to retry an image pull after a failure

Environment variable: QUARKUS_BUILDPACK_PULL_RETRY_COUNT

Show more

int

3

quarkus.buildpack.docker-host

DOCKER_HOST value to use. This value is normally auto-determined, and is available for override if needed. If not set, the env var DOCKER_HOST is used, if that is not set the platform will test if podman is available on the path, if so, it will use podman to configure the appropriate values. If podman is not on the path, docker is assumed, and per-platform defaults for docker are used.

Environment variable: QUARKUS_BUILDPACK_DOCKER_HOST

Show more

string

quarkus.buildpack.docker-socket

Path to the Docker socket to use. This value is normally auto-determined, and is available for override if needed. The path to the socket can vary, especially when the docker/podman daemon is running inside a VM, if useDaemon mode is true, then this path must refer to the path that can be used to mount the socket inside a container, so may refer to the path to the socket in the VM rather than the host.

Environment variable: QUARKUS_BUILDPACK_DOCKER_SOCKET

Show more

string

quarkus.buildpack.use-daemon

use Daemon mode? Should the buildpack build have the docker socket mounted into the build container(s). If this is false, then the image will be built directly as layers in a remote registry, this will probably require registry credentials to be passed. Defaults to 'true'

Environment variable: QUARKUS_BUILDPACK_USE_DAEMON

Show more

boolean

true

quarkus.buildpack.docker-network

Use specified docker network during build This can be handy when building against a locally hosted docker registry, where you will require the build containers to be part of the 'host' network to enable them to access the local registry.

Environment variable: QUARKUS_BUILDPACK_DOCKER_NETWORK

Show more

string

quarkus.buildpack.log-level

Log level to use. The log level to use when executing the build phases in containers. Defaults to 'info', supported values are 'info', 'warn' and 'debug'

Environment variable: QUARKUS_BUILDPACK_LOG_LEVEL

Show more

string

info

quarkus.buildpack.get-use-timestamps

Should the container log information include timestamps?

Environment variable: QUARKUS_BUILDPACK_GET_USE_TIMESTAMPS

Show more

boolean

true

Related content

On the same topics

Quarkus is open. All dependencies of this project are available under the Apache Software License 2.0 or compatible license.

This website was built with Jekyll, is hosted on GitHub Pages and is completely open source. If you want to make it better, fork the website and show us what you’ve got.

Navigation
Follow Us
Get Help
Languages
Quarkus is made of community projects
CC by 3.0 | Privacy Policy Sponsored by