BootUI on Quarkus

BootUI ships as a Quarkus extension. It serves the same console and the same JSON contract as the Spring starter, backed by the Quarkus build of the framework-neutral engine.

Prerequisites

• Java 17 or later
• A Quarkus application, built and tested against the platform version pinned by the root pom.xml (quarkus.platform.version, currently the 3.40.1 LTS release)
• Maven or Gradle (or their local wrappers)

The extension also supports the previous LTS line, 3.33. Every build runs the published build of the extension through all of its Quarkus integration fixtures on Quarkus 3.33.4 LTS, and runs the extension's own tests compiled against it. Its core, REST client, production-guard, and Hibernate JVM fixtures have also passed with Quarkus 3.39.5. Quarkus 3.39 is the most recently released non-LTS line, but its upstream support ended when 3.40 shipped.

Add the extension

<dependency>
  <groupId>com.julien-dubois.bootui</groupId>
  <artifactId>bootui-quarkus</artifactId>
  <version>2.1.0</version>
</dependency>

// Groovy DSL (build.gradle)
implementation 'com.julien-dubois.bootui:bootui-quarkus:2.1.0'

// Kotlin DSL (build.gradle.kts)
implementation("com.julien-dubois.bootui:bootui-quarkus:2.1.0")

Declare only bootui-quarkus. The Quarkus extension mechanism resolves the matching bootui-quarkus-deployment artifact for you.

Run your app in development mode

Start Quarkus in dev mode. BootUI activates automatically, with no profile or flag to set:

./mvnw quarkus:dev

./gradlew quarkusDev

BootUI is then available at http://localhost:8080/bootui.

The bootui.path and bootui.api-path settings described in Use a custom path work in dev and test mode and compose with quarkus.http.root-path.

Activation and safety

The Quarkus launch mode decides activation. There is no Spring-style profile and no bootui.enabled flag:

This is fail-closed by design: no flag turns BootUI on in a production build.

The request-time safety model matches Spring Boot. The shared LocalhostGuard applies loopback-source trust, a Host allow-list against DNS rebinding, and cross-site-write protection. API callers from untrusted sources must also present the BootUI bearer token; loopback callers and sources you have explicitly trusted through bootui.trusted-proxies or bootui.trust-container-gateway are exempt. The same keys apply, read from MicroProfile Config:

# Default: reject non-loopback callers.
bootui.allow-non-localhost=false
# Extra Host header values to accept.
bootui.allowed-hosts=localhost
# Extra source ranges, for example a Docker gateway.
bootui.trusted-proxies=172.17.0.1/32
# Auto-trust the container gateway in dev containers.
bootui.trust-container-gateway=AUTO
# Optional stable token; otherwise generated at startup.
# bootui.authentication.token=...

The Docker container guidance applies to Quarkus too, since dev mode is already active there. Per-panel bootui.panels.* toggles and the bootui.read-only master switch behave identically on both frameworks.

Runtime configuration overrides are Spring-only today, so the Configuration panel is read-only on Quarkus.

Panel availability

Most panels are live. Nine target Spring-specific runtime concepts and are permanently marked not applicable, and JMS is not available yet. See what is not on Quarkus for the list and the reason for each. To try a fully wired application, see Try the sample app.

The MySQL panel needs an existing default or named JDBC datasource with the io.quarkus:quarkus-jdbc-mysql extension and a MySQL declaration: quarkus.datasource.db-kind=mysql for the default datasource, or quarkus.datasource.<name>.db-kind=mysql for a named one. A reactive MySQL client alone is not enough, and BootUI creates no monitoring datasource of its own.