The English version of quarkus.io is the official project site. Translated sites are community supported on a best-effort basis.
Back to Guides
このページを編集

ネイティブ実行可能ファイルの生成

Quarkus applications can be compiled to native executables, producing a standalone binary that starts in milliseconds and uses a fraction of the memory of a JVM process.

In this guide, you will compile the application from the Getting Started Guide to a native executable, test it, and package it in a container.

Do you need a native executable?

Quarkus on the JVM is already fast, sub-second startup, low memory footprint, and optimized throughput. For many applications, JVM mode is the right choice.

Native executables shine when:

  • Startup time is critical: serverless/FaaS, CLI tools, or scale-to-zero environments where cold starts matter.

  • Memory is constrained: dense container deployments or edge devices with tight RAM budgets.

  • You want the smallest possible container image: native binaries produce images under 50MB.

JVM mode is typically better when:

  • Peak throughput matters most: the JVM’s JIT compiler optimizes hot paths at runtime, which can outperform native on long-running workloads.

  • Build time is a constraint: native compilation takes minutes, JVM builds take seconds.

  • You rely heavily on reflection or dynamic class loading: these require explicit configuration for native images.

Start with JVM mode. Move to native when you have a concrete need. Both modes use the same code and the same Quarkus optimizations: native just changes how the binary is produced.

Comparing JVM, Leyden AOT, and native modes

Native is one of three runtime options Quarkus supports. JVM fast-jar, JVM with Project Leyden AOT caching (JDK 24+), and native (Mandrel) each trade cold-start speed, peak throughput, memory footprint, and build cost differently. The table below compares them. Pick the mode that matches your workload’s most important constraint.

Mode Cold start Time to first request Peak throughput Memory (RSS) コンテナーイメージサイズ Build cost When to choose

JVM fast-jar

~0.4 s (small REST) to ~3 s (large CRUD)

4,417 ms

13,265 tps (baseline)

304 MiB

517 MB

~30 s build; no special workflow

Long-running services, throughput-critical workloads; teams on pre-JDK-24 runtimes

JVM + Leyden AOT cache

~80 ms (small) to ~900 ms (large)

1,859 ms

12,389 tps (~7% below JVM)

240 MiB

715 MB (AOT cache adds ~198 MB)

Standard build plus a training run on a representative workload

Cold-start-sensitive but not millisecond-critical; requires JDK 24+; keeps full JVM tooling (debuggers, profilers, JFR)

Native (Mandrel)

~17 ms (small) to ~240 ms (large)

581 ms

5,411 tps (~59% below JVM)

95 MiB

244 MB

3-10 min build; 4-8 GB build-host RAM

Extreme cold start (serverless, scale-to-zero); edge deployments; high-density container hosts where memory is the binding constraint

Time to first request, peak throughput, and memory (RSS) come from the 2026-04-21 perf-lab tuned benchmark (Quarkus 3.34.3, JDK 25.0.2, GraalVM 25.0.2-graalce, 4 CPUs, -Xmx512m). Cold-start ranges and container image sizes come from the Leyden integration benchmarks and the Mar 2026 performance post. For the latest numbers, see the Quarkus benchmarks chart reference.

For the Leyden AOT cache path, see the AOT caching guide. If native is the right fit for your workload, read on. The next sections walk you through prerequisites, compilation, testing, and container packaging.

前提条件

このガイドを完成させるには、以下が必要です:

C言語でのネイティブコンパイルのサポート

動作するC言語の開発環境があるとはどういう意味でしょうか?

  • Linuxでは、GCC、glibc、zlibヘッダが必要です。一般的なディストリビューションでは次の通りです:

    # dnf (rpm-based)
sudo dnf install gcc glibc-devel zlib-devel libstdc++-static
# Debian-based distributions:
sudo apt-get install build-essential libz-dev zlib1g-dev
# Arch Linux
sudo pacman -S freetype2 gcc glibc lib32-gcc-libs zlib

  • macOS では、XCode が必要な依存関係を提供します:

    xcode-select --install

  • Windows では、 Visual Studio 2022 Visual C++ Build Tools をインストールする必要があります。

Choosing a GraalVM distribution

Building a native executable requires a GraalVM distribution. There are two main options:

  • Oracle GraalVM — the standard distribution from Oracle. Supports Linux, macOS (both Intel and Apple Silicon), and Windows.

  • Mandrel — a downstream distribution tailored for Quarkus. It excludes components not needed by Quarkus (such as polyglot support) to provide a smaller distribution.

GraalVM for JDK 21 が必要です。

GraalVMの設定

このステップは、Linux 以外のオペレーティングシステムをターゲットとしたネイティブ実行可能ファイルを生成する場合にのみ必要です。 Linux をターゲットとしたネイティブ実行可能ファイルを生成する場合は、このセクションを省略して代わりに use a builder image。

If you cannot install GraalVM, you can use a multi-stage Docker build to run Maven inside a Docker container that embeds GraalVM. There is an explanation of how to do this in the Native Reference Guide.

  1. まだの場合は、GraalVM をインストールします。これにはいくつかのオプションがあります:

  2. ランタイム環境を構成します。 GRAALVM_HOME 環境変数をGraalVMインストールディレクトリーに設定します。例えば、

    export GRAALVM_HOME=$HOME/Development/mandrel/

    On macOS, point the variable to the Home sub-directory:

    export GRAALVM_HOME=$HOME/Development/graalvm/Contents/Home/

    Windowsでは、コントロールパネルから環境変数を設定する必要があります。

    scoop でインストールすれば自動的に設定されます。

  3. (オプション) 環境変数 JAVA_HOME を GraalVM のインストールディレクトリーに設定します。

    export JAVA_HOME=${GRAALVM_HOME}

  4. (オプション) GraalVM bin ディレクトリーをパスに追加します。

    export PATH=${GRAALVM_HOME}/bin:$PATH
macOS で GraalVM を使用する場合の問題

この GraalVM の issue で報告されているように、GraalVM のバイナリーは macOS 用に (まだ) 公証されていません。そのため、native-image を使用した際に以下のエラーが表示されることがあります。

"native-image" cannot be opened because the developer cannot be verified

回避策として、次のコマンドを使用して、GraalVMインストールディレクトリー上の com.apple.quarantine 拡張属性を再帰的に削除します。

xattr -r -d com.apple.quarantine ${GRAALVM_HOME}/../..

ネイティブ実行可能ファイルの生成

The native executable for your application will contain the application code, required libraries, Java APIs, and a reduced version of a VM. The smaller VM base improves the startup time of the application and produces a minimal disk footprint.

ネイティブ実行可能ファイルの生成

quarkus.native.additional-build-args および quarkus.native.additional-build-args-append プロパティーを使用して、native-image コマンドにカスタムオプションを指定できます。複数のオプションはカンマで区切ることができます。

For example, to forward the host LD_PRELOAD and LD_LIBRARY_PATH environment variables to the native-image invocation, pass them as a single comma-separated value using the -E option:

./mvnw package -Dnative \
    -Dquarkus.native.additional-build-args="-ELD_PRELOAD=${LD_PRELOAD},-ELD_LIBRARY_PATH=${LD_LIBRARY_PATH}"

All arguments must go into a single quarkus.native.additional-build-args value: as with any -D system property, repeating it on the command line keeps only the last value rather than appending. Depending on your shell, you may need to escape the $ characters.

ネイティブイメージビルド処理の設定方法については、以下の [設定リファレンス] の項で詳しく説明しています。

Native compilation takes significantly longer than a regular JVM build. Create a native executable using:

コマンドラインインタフェース
quarkus build --native
Maven
./mvnw install -Dnative
Gradle
./gradlew build -Dquarkus.native.enabled=true
Windows でのパッケージ化に関する問題

Visual Studio の Microsoft Native Tools はパッケージ化する前に初期化する必要があります。 これは、Visual Studio ビルドツールと一緒にインストールされた x64 Native Tools Command Prompt を起動することで行うことができます。 x64 Native Tools Command Prompt で、プロジェクトフォルダーに移動して ./mvnw package -Dnative を実行してください。

The build produces target/getting-started-1.0.0-SNAPSHOT-runner. You can run it directly:

./target/getting-started-1.0.0-SNAPSHOT-runner
__  ____  __  _____   ___  __ ____  ______
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/
INFO  [io.quarkus] (main) getting-started 1.0.0-SNAPSHOT native (powered by Quarkus {quarkus-version}) started in 0.012s. Listening on: http://0.0.0.0:8080
INFO  [io.quarkus] (main) Profile prod activated.
INFO  [io.quarkus] (main) Installed features: [cdi, rest, smallrye-context-propagation, vertx]

ネイティブ実行可能ファイルのテスト

Producing a native executable can lead to a few issues, and so it’s also a good idea to run some tests against the application running in the native file. The reasoning is explained in the Testing Guide.

GreetingResourceIT がネイティブ実行可能ファイルに対して実行されることを確認するには、 ./mvnw verify -Pnative を使用します。

$ ./mvnw verify -Dnative
...
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.acme.getting.started.GreetingResourceIT
...
INFO  [io.quarkus] (main) getting-started 1.0.0-SNAPSHOT native (powered by Quarkus 999-SNAPSHOT) started in 0.012s. Listening on: http://0.0.0.0:8081
INFO  [io.quarkus] (main) Profile prod activated.
INFO  [io.quarkus] (main) Installed features: [cdi, rest, smallrye-context-propagation, vertx]
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
...

Quarkus では、デフォルトでネイティブイメージの起動を 60 秒間待機した後、自動的にネイティブテストが失敗します。 この時間は、 quarkus.test.wait-time システムプロパティーを使用して変更できます。 たとえば待機時間を 300 秒に増やす場合、 ./mvnw verify -Dnative -Dquarkus.test.wait-time=300 となります。

For advanced testing scenarios, test profiles, excluding tests from native runs, or testing an existing binary, see the Native Reference Guide.

GraalVM をインストールせずに Linux 実行可能ファイルを作成する方法

次に進む前に、動作するコンテナーランタイム (Docker、podman) 環境があることを確認してください。Windows で Docker を使用している場合は、Docker Desktop のファイル共有設定でプロジェクトのドライブを共有し、Docker Desktop を再起動する必要があります。

多くの場合、Quarkusアプリケーション用のネイティブLinux実行ファイルを作成する必要があります(例えば、コンテナー化された環境で実行するためなど)、このタスクを達成するために適切なGraalVMバージョンをインストールする手間を省きたいと考えています(例えば、CI環境では、できるだけ少ないソフトウェアをインストールするのが一般的です)。

このため、Quarkusでは、Dockerやpodmanなどのコンテナーランタイムを利用して、ネイティブのLinux実行ファイルを作成する非常に便利な方法を提供しています。このタスクを達成する最も簡単な方法は、次を実行することです:

コマンドラインインタフェース
quarkus build --native --no-tests -Dquarkus.native.container-build=true
# The --no-tests flag is required only on Windows and macOS.
Maven
./mvnw install -Dnative -DskipTests -Dquarkus.native.container-build=true
Gradle
./gradlew build -Dquarkus.native.enabled=true -Dquarkus.native.container-build=true
What to expect

Your first container-based native build typically takes 3-10 minutes and uses 4-8 GB of RAM on the build host. Fan spin-up is normal; the build is still running, just working hard. A build that runs past 15 minutes without output usually means the container runtime is short on memory; raise its CPU and memory allocation and retry.

The output is a Linux binary produced inside the builder image. Its architecture matches the builder image you pulled: typically x86_64 unless you explicitly selected an arm64 variant or are running on an arm64 host. Run the binary in a Linux container that matches that architecture, not directly on your host OS.

デフォルトでは、Quarkusはコンテナランタイムを自動的に検出します。コンテナランタイムを明示的に選択したい場合は、次のようにします:

Docker の場合:

コマンドラインインタフェース
quarkus build --native -Dquarkus.native.container-build=true -Dquarkus.native.container-runtime=docker
Maven
./mvnw install -Dnative -Dquarkus.native.container-build=true -Dquarkus.native.container-runtime=docker
Gradle
./gradlew build -Dquarkus.native.enabled=true -Dquarkus.native.container-build=true -Dquarkus.native.container-runtime=docker

podman の場合:

コマンドラインインタフェース
quarkus build --native -Dquarkus.native.container-build=true -Dquarkus.native.container-runtime=podman
Maven
./mvnw install -Dnative -Dquarkus.native.container-build=true -Dquarkus.native.container-runtime=podman
Gradle
./gradlew build -Dquarkus.native.enabled=true -Dquarkus.native.container-build=true -Dquarkus.native.container-runtime=podman

これらは通常の Quarkus 設定プロパティーであるため、常にコンテナーでビルドしたい場合は、 毎回指定しなくて済むように application.properties に追加することが推奨されます。

コンテナーランタイムを使用してそのようにビルドされた実行ファイルは 64 ビット Linux 実行ファイルになるため、お使いのオペレーティングシステムによっては実行できなくなる可能性があります。

The builder image used to build the native executable is based on UBI 10. It means that the native executable produced by the container build will be based on UBI 10 as well. So, if you plan to build a container, make sure that the base image in your Dockerfile is compatible with UBI 10. The native executable will not run on UBI 8 or UBI 9 base images.

You can configure the builder image used for the container build by setting the quarkus.native.builder-image property. For example, to switch back to an UBI 9 builder image you can use:

quarkus.native.builder-image=quay.io/quarkus/ubi9-quarkus-mandrel-builder-image:jdk-21

You can see the available tags for UBI 8 here (UBI 8), for UBI 9 here (UBI 9), and for UBI 10 here (UBI 10))

JARが正常にビルドされているにもかかわらず、コンテナビルドでネイティブ実行可能ファイルを作成しようとすると、アプリケーションJARに対して以下のようなinvalid pathエラーが表示される場合は、コンテナランタイムにリモートデーモンを使用している可能性があります。

Error: Invalid Path entry getting-started-1.0.0-SNAPSHOT-runner.jar
Caused by: java.nio.file.NoSuchFileException: /project/getting-started-1.0.0-SNAPSHOT-runner.jar

この場合、パラメータ -Dquarkus.native.container-build=true の代わりに -Dquarkus.native.remote-container-build=true を使用してください。

その理由は、 -Dquarkus.native.container-build=true を通して起動されるローカルビルドドライバは、ビルドコンテナで JAR を利用できるようにするためにボリュームマウントを使用しますが、ボリュームマウントはリモートデーモンでは機能しません。リモートコンテナのビルドドライバは、必要なファイルをマウントするのではなく、コピーします。リモートドライバはローカルデーモンでも動作しますが、ローカルの場合はローカルドライバを使用した方が良いことに注意してください。なぜなら、マウントの方がコピーよりもパフォーマンスが高いからです。

Mandrel の代わりに GraalVM を使用してビルドする場合は、カスタムビルダーイメージパラメーターを追加で渡す必要があります。

コマンドラインインタフェース
quarkus build --native -Dquarkus.native.container-build=true -Dquarkus.native.builder-image=graalvm
Maven
./mvnw install -Dnative -Dquarkus.native.container-build=true -Dquarkus.native.builder-image=graalvm
Gradle
./gradlew build -Dquarkus.native.enabled=true -Dquarkus.native.container-build=true -Dquarkus.native.builder-image=graalvm

Please note that the above command points to a floating tag. It is highly recommended to use the floating tag, so that your builder image remains up-to-date and secure. If you absolutely must, you may hard-code to a specific tag (see here (UBI 8), here (UBI 9), and here (UBI 10) for available tags), but be aware that you won’t get security updates that way and it’s unsupported.

コンテナーの作成

コンテナーイメージのエクステンションの使用

Quarkusアプリケーションからコンテナーイメージを作成する最も簡単な方法は、コンテナーイメージ エクステンションの1つを利用することです。

これらのエクステンションのいずれかが存在する場合、ネイティブ実行可能ファイル用のコンテナーイメージを作成することは、基本的には単一のコマンドを実行することになります:

./mvnw package -Dnative -Dquarkus.native.container-build=true -Dquarkus.container-image.build=true

  • quarkus.native.container-build=true では GraalVM がインストールされていなくても Linux の実行ファイルを作成することができます(ローカルに GraalVM がインストールされていない場合や、ローカルのオペレーティングシステムが Linux ではない場合にのみ必要です)。

リモートDockerデーモンを実行している場合、 -Dquarkus.native.container-build=true を -Dquarkus.native.remote-container-build=true で置換する必要があります。

詳細は、Creating a Linux executable without GraalVM installed を参照してください。

  • quarkus.container-image.build=true 最終的なアプリケーションアーティファクト(この場合はネイティブ実行可能ファイル)を使用してコンテナーイメージを作成するようにQuarkusに指示します。

詳細については、 コンテナイメージガイド を参照してください。

Using the micro base image

You can also build a container manually using the generated Dockerfile. The project generation provides a Dockerfile.native-micro in the src/main/docker directory with the following content:

FROM quay.io/quarkus/ubi10-quarkus-micro-image:2.0
WORKDIR /work/
RUN chown 1001 /work \
    && chmod "g+rwX" /work \
    && chown 1001:root /work
COPY --chown=1001:root --chmod=755 target/*-runner /work/application

EXPOSE 8080
USER 1001

ENTRYPOINT ["./application", "-Dquarkus.http.host=0.0.0.0"]
Quarkus マイクロイメージとは？

The Quarkus Micro Image is a small container image providing the right set of dependencies to run your native application. It is based on UBI Micro.

このページ では、アプリケーションに特定の要件がある場合に、 quarkus-micro イメージを拡張する方法について説明しています。

Build and run the container:

docker build -f src/main/docker/Dockerfile.native-micro -t quarkus-quickstart/getting-started .
docker run -i --rm -p 8080:8080 quarkus-quickstart/getting-started

For advanced container options — multi-stage builds, distroless images, scratch images, or UPX compression — see the Native Reference Guide.

ネイティブ実行可能ファイルの設定

ネイティブ実行可能ファイルの生成方法に影響を与える設定オプションがたくさんあります。これらは他の設定プロパティーと同じように application.properties で提供されています。

プロパティーは以下の通りです:

ビルド時に固定される設定プロパティ - 他のすべての設定プロパティは実行時にオーバーライド可能

Configuration property

タイプ

デフォルト

quarkus.native.enabled

Set to enable native-image building using GraalVM.

Environment variable: QUARKUS_NATIVE_ENABLED

Show more

ブーリアン

false

quarkus.native.bundle.enabled

Set to enable native-image bundle generation.

Environment variable: QUARKUS_NATIVE_BUNDLE_ENABLED

Show more

ブーリアン

quarkus.native.bundle.dry-run

Generates the native-image bundle through a dry-run build, skipping the actual native-image build.

Environment variable: QUARKUS_NATIVE_BUNDLE_DRY_RUN

Show more

ブーリアン

false

quarkus.native.bundle.name

Set to define the native-image bundle name. If not set the default name will match the native-executable’s name suffixed by .nib. i.e. {project.name}-{project.version}-runner.nib

Environment variable: QUARKUS_NATIVE_BUNDLE_NAME

Show more

string

quarkus.native.sources-only

Set to prevent the native-image process from actually building the native image.

Environment variable: QUARKUS_NATIVE_SOURCES_ONLY

Show more

ブーリアン

false

quarkus.native.additional-build-args

Comma-separated, additional arguments to pass to the build process. If an argument includes the , symbol, it needs to be escaped, e.g. \\,

Environment variable: QUARKUS_NATIVE_ADDITIONAL_BUILD_ARGS

Show more

文字列のリスト

quarkus.native.additional-build-args-append

Comma-separated, additional arguments to pass to the build process. The arguments are appended to those provided through additional-build-args(), as a result they may override those passed through additional-build-args(). By convention, this is meant to be set on the command-line, while additional-build-args() should be preferred for use in properties files. If an argument includes the , symbol, it needs to be escaped, e.g. \\,

Environment variable: QUARKUS_NATIVE_ADDITIONAL_BUILD_ARGS_APPEND

Show more

文字列のリスト

quarkus.native.enable-http-url-handler

If the HTTP url handler should be enabled, allowing you to do URL.openConnection() for HTTP URLs

Environment variable: QUARKUS_NATIVE_ENABLE_HTTP_URL_HANDLER

Show more

ブーリアン

true

quarkus.native.enable-https-url-handler

If the HTTPS url handler should be enabled, allowing you to do URL.openConnection() for HTTPS URLs

Environment variable: QUARKUS_NATIVE_ENABLE_HTTPS_URL_HANDLER

Show more

ブーリアン

false

quarkus.native.headless

The default value for java.awt.headless JVM option. Switching this option affects linking of awt libraries.

Environment variable: QUARKUS_NATIVE_HEADLESS

Show more

ブーリアン

true

quarkus.native.file-encoding

Defines the file encoding as in -Dfile.encoding=…​.

Native image runtime uses the host’s (i.e. build time) value of file.encoding system property. We intentionally default this to UTF-8 to avoid platform specific defaults to be picked up which can then result in inconsistent behavior in the generated native executable.

Environment variable: QUARKUS_NATIVE_FILE_ENCODING

Show more

string

UTF-8

quarkus.native.add-all-charsets

If all character sets should be added to the native executable.

Note that some extensions (e.g. the Oracle JDBC driver) also take this setting into account to enable support for all charsets at the extension level.

This increases image size.

Environment variable: QUARKUS_NATIVE_ADD_ALL_CHARSETS

Show more

ブーリアン

false

quarkus.native.graalvm-home

The location of the Graal distribution

Environment variable: QUARKUS_NATIVE_GRAALVM_HOME

Show more

string

${GRAALVM_HOME:}

quarkus.native.java-home

The location of the JDK

Environment variable: QUARKUS_NATIVE_JAVA_HOME

Show more

File

${java.home}

quarkus.native.native-image-xmx

The maximum Java heap to be used during the native image generation

Environment variable: QUARKUS_NATIVE_NATIVE_IMAGE_XMX

Show more

string

quarkus.native.debug-build-process

If the native image build should wait for a debugger to be attached before running. This is an advanced option and is generally only intended for those familiar with GraalVM internals

Environment variable: QUARKUS_NATIVE_DEBUG_BUILD_PROCESS

Show more

ブーリアン

false

quarkus.native.publish-debug-build-process-port

If the debug port should be published when building with docker and debug-build-process is true

Environment variable: QUARKUS_NATIVE_PUBLISH_DEBUG_BUILD_PROCESS_PORT

Show more

ブーリアン

true

quarkus.native.enable-isolates

If isolates should be enabled

Environment variable: QUARKUS_NATIVE_ENABLE_ISOLATES

Show more

ブーリアン

true

quarkus.native.enable-fallback-images

If a JVM based 'fallback image' should be created if native image fails. This is not recommended, as this is functionally the same as just running the application in a JVM

Environment variable: QUARKUS_NATIVE_ENABLE_FALLBACK_IMAGES

Show more

ブーリアン

false

quarkus.native.auto-service-loader-registration

If all META-INF/services entries should be automatically registered

Environment variable: QUARKUS_NATIVE_AUTO_SERVICE_LOADER_REGISTRATION

Show more

ブーリアン

false

quarkus.native.dump-proxies

If the bytecode of all proxies should be dumped for inspection

Environment variable: QUARKUS_NATIVE_DUMP_PROXIES

Show more

ブーリアン

false

quarkus.native.container-build

If this build should be done using a container runtime. Unless container-runtime is also set, docker will be used by default. If docker is not available or is an alias to podman, podman will be used instead as the default.

Environment variable: QUARKUS_NATIVE_CONTAINER_BUILD

Show more

ブーリアン

quarkus.native.pie

Explicit configuration option to generate a native Position Independent Executable (PIE) for Linux. If the system supports PIE generation, the default behaviour is to disable it for performance reasons. However, some systems can only run position-independent executables, so this option enables the generation of such native executables.

Environment variable: QUARKUS_NATIVE_PIE

Show more

ブーリアン

quarkus.native.march

Generate instructions for a specific machine type. Defaults to x86-64-v3 on AMD64 and armv8-a on AArch64. Use compatibility for best compatibility, or native for best performance if a native executable is deployed on the same machine or on a machine with the same CPU features. A list of all available machine types is available by executing native-image -march=list

Environment variable: QUARKUS_NATIVE_MARCH

Show more

string

quarkus.native.remote-container-build

If this build is done using a remote docker daemon.

Environment variable: QUARKUS_NATIVE_REMOTE_CONTAINER_BUILD

Show more

ブーリアン

false

quarkus.native.builder-image

The docker image to use to do the image build. It can be one of graalvm, mandrel, or the full image path, e.g. quay.io/quarkus/ubi10-quarkus-mandrel-builder-image:jdk-21.

Note: Builder images are available using UBI 8, UBI 9, and UBI 10 base images, for example:

  • UBI 10: quay.io/quarkus/ubi10-quarkus-mandrel-builder-image:jdk-21 (default)

  • UBI 9: quay.io/quarkus/ubi9-quarkus-mandrel-builder-image:jdk-21

  • UBI 8: quay.io/quarkus/ubi-quarkus-mandrel-builder-image:jdk-21

You need to be aware that if you use a builder image using UBI 10 and you plan to build a container, you must ensure that the base image used in the container is also UBI 10.

Environment variable: QUARKUS_NATIVE_BUILDER_IMAGE

Show more

string

mandrel

quarkus.native.builder-image.pull

The strategy for pulling the builder image during the build.

Defaults to 'always', which will always pull the most up-to-date image; useful to keep up with fixes when a (floating) tag is updated.

Use 'missing' to only pull if there is no image locally; useful on development environments where building with out-of-date images is acceptable and bandwidth may be limited.

Use 'never' to fail the build if there is no image locally.

Environment variable: QUARKUS_NATIVE_BUILDER_IMAGE_PULL

Show more

alwaysAlways pull the most recent image., missingOnly pull the image if it’s missing locally., neverNever pull any image; fail if the image is missing locally.

alwaysAlways pull the most recent image.

quarkus.native.container-runtime

The container runtime (e.g. docker) that is used to do an image based build. If this is set then a container build is always done.

Environment variable: QUARKUS_NATIVE_CONTAINER_RUNTIME

Show more

docker, docker-rootless, wsl, wsl-rootless, podman, podman-rootless, unavailable

quarkus.native.container-runtime-options

Options to pass to the container runtime

Environment variable: QUARKUS_NATIVE_CONTAINER_RUNTIME_OPTIONS

Show more

文字列のリスト

quarkus.native.enable-vm-inspection

This property is deprecated: Use quarkus.native.monitoring instead.

If the resulting image should allow VM introspection.

Environment variable: QUARKUS_NATIVE_ENABLE_VM_INSPECTION

Show more

ブーリアン

false

quarkus.native.monitoring

Enable monitoring various monitoring options. The value should be comma separated.

  • jfr for JDK flight recorder support

  • jcmd for JCMD support

  • jvmstat for JVMStat support

  • heapdump for heapdump support

  • jmxclient for JMX client support (experimental)

  • jmxserver for JMX server support (experimental)

  • nmt for native memory tracking support

  • threaddump for thread dumping on SIGBREAK/SIGQUIT support

  • all for all monitoring features

  • none for explicitly turning off all monitoring features

Environment variable: QUARKUS_NATIVE_MONITORING

Show more

list of heapdumpHeapdump support., jcmdJCMD support., jvmstatJVMStat support., jfrJDK flight recorder support., jmxserverJMX server support (experimental)., jmxclientJMX client support (experimental)., nmtNative memory tracking support., threaddumpThread dumping support., allAll monitoring features., noneExplicitly turns off all monitoring features.

quarkus.native.enable-reports

If the reports on call paths and included packages/classes/methods should be generated

Environment variable: QUARKUS_NATIVE_ENABLE_REPORTS

Show more

ブーリアン

false

quarkus.native.report-exception-stack-traces

If exceptions should be reported with a full stack trace

Environment variable: QUARKUS_NATIVE_REPORT_EXCEPTION_STACK_TRACES

Show more

ブーリアン

true

quarkus.native.report-errors-at-runtime

If errors should be reported at runtime. This is a more relaxed setting, however it is not recommended as it means your application may fail at runtime if an unsupported feature is used by accident.

Note that the use of this flag may result in build time failures due to `ClassNotFoundException`s. Reason most likely being that the Quarkus extension already optimized it away or do not actually need it. In such cases you should explicitly add the corresponding dependency providing the missing classes as a dependency to your project.

Environment variable: QUARKUS_NATIVE_REPORT_ERRORS_AT_RUNTIME

Show more

ブーリアン

false

quarkus.native.reuse-existing

Don’t build a native image if it already exists.

This is useful if you have already built an image and you want to use Quarkus to deploy it somewhere.

Note that this is not able to detect if the existing image is outdated, if you have modified source or config and want a new image you must not use this flag.

Environment variable: QUARKUS_NATIVE_REUSE_EXISTING

Show more

ブーリアン

false

quarkus.native.resources.includes

A comma separated list of globs to match resource paths that should be added to the native image.

Use slash (/) as a path separator on all platforms. Globs must not start with slash.

By default, no resources are included.

Example: Given that you have src/main/resources/ignored.png and src/main/resources/foo/selected.png in your source tree and one of your dependency JARs contains bar/some.txt file, with the following configuration

quarkus.native.resources.includes = foo/**,bar/**/*.txt

the files src/main/resources/foo/selected.png and bar/some.txt will be included in the native image, while src/main/resources/ignored.png will not be included.

Supported glob features

Feature Description

*

Matches a (possibly empty) sequence of characters that does not contain slash (/)

**

Matches a (possibly empty) sequence of characters that may contain slash (/)

?

Matches one character, but not slash

[abc]

Matches one character given in the bracket, but not slash

[a-z]

Matches one character from the range given in the bracket, but not slash

[!abc]

Matches one character not named in the bracket; does not match slash

[a-z]

Matches one character outside the range given in the bracket; does not match slash

{one,two,three}

Matches any of the alternating tokens separated by comma; the tokens may contain wildcards, nested alternations and ranges

\

The escape character

Note that there are three levels of escaping when passing this option via application.properties:

  1. application.properties parser

  2. MicroProfile Config list converter that splits the comma separated list

  3. Glob parser

All three levels use backslash (\) as the escaping character. So you need to use an appropriate number of backslashes depending on which level you want to escape.

Note that Quarkus extensions typically include the resources they require by themselves. This option is useful in situations when the built-in functionality is not sufficient.

Environment variable: QUARKUS_NATIVE_RESOURCES_INCLUDES

Show more

文字列のリスト

quarkus.native.resources.excludes

This property is deprecated since 3.29: Excluding resources is not supported in the new reachability-metadata.json file used with Mandrel/GraalVM 25.0 and onwards. Quarkus plans to adopt the use of reachability-metadata.json for Mandrel/GraalVM 23.1 for JDK 21 as well (see https://github.com/quarkusio/quarkus/issues/41016).

A comma separated list of globs to match resource paths that should not be added to the native image.

Use slash (/) as a path separator on all platforms. Globs must not start with slash.

Please refer to includes for details about the glob syntax.

By default, no resources are excluded.

Example: Given that you have src/main/resources/red.png and src/main/resources/foo/green.png in your source tree and one of your dependency JARs contains bar/blue.png file, with the following configuration

quarkus.native.resources.includes = **/*.png
quarkus.native.resources.excludes = foo/**,**/green.png

the resource red.png will be available in the native image while the resources foo/green.png and bar/blue.png will not be available in the native image.

Environment variable: QUARKUS_NATIVE_RESOURCES_EXCLUDES

Show more

文字列のリスト

quarkus.native.debug.enabled

If debug is enabled and debug symbols are generated. The symbols will be generated in a separate .debug file.

Environment variable: QUARKUS_NATIVE_DEBUG_ENABLED

Show more

ブーリアン

false

quarkus.native.enable-dashboard-dump

Generate the report files for GraalVM Dashboard.

Environment variable: QUARKUS_NATIVE_ENABLE_DASHBOARD_DUMP

Show more

ブーリアン

false

quarkus.native.include-reasons-in-config-files

Include a reasons entries in the generated json configuration files.

Environment variable: QUARKUS_NATIVE_INCLUDE_REASONS_IN_CONFIG_FILES

Show more

ブーリアン

false

quarkus.native.compression.enabled

Whether compression should be enabled.

Environment variable: QUARKUS_NATIVE_COMPRESSION_ENABLED

Show more

ブーリアン

true

quarkus.native.compression.container-build

Whether the compression should be executed within a container.

Environment variable: QUARKUS_NATIVE_COMPRESSION_CONTAINER_BUILD

Show more

ブーリアン

quarkus.native.compression.container-image

The image used for compression. Defaults to quarkus.native.builder-image if not set.

Setting this variable will automatically activate

Environment variable: QUARKUS_NATIVE_COMPRESSION_CONTAINER_IMAGE

Show more

string

quarkus.native.compression.level

The compression level in [1, 10]. 10 means best.

Higher compression level requires more time to compress the executable.

Environment variable: QUARKUS_NATIVE_COMPRESSION_LEVEL

Show more

int

quarkus.native.compression.additional-args

Allows passing extra arguments to the UPX command line (like --brute). The arguments are comma-separated.

The exhaustive list of parameters can be found in https://github.com/upx/upx/blob/devel/doc/upx.pod.

Environment variable: QUARKUS_NATIVE_COMPRESSION_ADDITIONAL_ARGS

Show more

文字列のリスト

quarkus.native.agent-configuration-apply

Configuration files generated by the Quarkus build, using native image agent, are informative by default. In other words, the generated configuration files are presented in the build log but are not applied. When this option is set to true, generated configuration files are applied to the native executable building process.

Enabling this option should be done with care, because it can make native image configuration and/or behaviour dependant on other non-obvious factors. For example, if the native image agent generated configuration was generated from running JVM unit tests, disabling test(s) can result in a different native image configuration being generated, which in turn can misconfigure the native executable or affect its behaviour in unintended ways.

Environment variable: QUARKUS_NATIVE_AGENT_CONFIGURATION_APPLY

Show more

ブーリアン

false

quarkus.native.pgo.enabled

Enable Profile-Guided Optimization for native images.

Requires Oracle GraalVM. When enabled, the native build produces an instrumented binary. Running @QuarkusIntegrationTest generates a .iprof profile, and a post-integration-test Maven goal rebuilds with that profile to produce an optimized native binary.

Environment variable: QUARKUS_NATIVE_PGO_ENABLED

Show more

ブーリアン

false

次のステップ

This guide covered the creation of a native (binary) executable for your application. It provides an application exhibiting a swift startup time and consuming less memory.

関連コンテンツ

同じトピックについて

Quarkus はオープンです。このプロジェクトのすべての依存関係は、Apache Software License 2.0 または互換性のあるライセンスの下で利用可能です。 CC by 3.0

このウェブサイトは Jekyll で構築され、GitHub Pages でホストされており、完全にオープンソースです。改善したい場合は、ウェブサイトをフォークして、あなたのアイデアを見せてください。

ナビゲーション
フォローする
ヘルプ
言語
Quarkusはコミュニティプロジェクトで構成されています
Copyright © Quarkus. All rights reserved. For details on our trademarks, please visit our Trademark Policy and Trademark List. Trademarks of third parties are owned by their respective holders and their mention here does not suggest any endorsement or association.