BootUI on Quarkus — design & strategy

Status: Implemented and shipping. What began as a design proposal is now the bootui-quarkus / bootui-quarkus-deployment extension described throughout this document — the large majority of the panel set is live on Quarkus today (see §5 for the authoritative per-panel status and SPECIFICATION.md §1.1 for the honest maturity statement: the Spring Boot adapter is complete, the Quarkus adapter is still being built out). The rest of this document is kept as the design record the implementation follows; treat the phased plan in §9 as historical — Phases 0–2 have shipped and Phase 3's capture panels are also live (§5.3).

1. Goal

Run the same BootUI developer console — same Vue UI, same REST contract, same DTOs — on a Quarkus dev application, sharing as much code as possible with the Spring Boot implementation. Each framework contributes only a thin adapter layer; the bulk of BootUI's logic lives in framework-neutral shared modules.

Concretely:

1. One UI artifact. bootui-ui (the Vue 3 SPA) is built once and served unchanged by both backends.
2. One data contract. The immutable record DTOs in bootui-core are the contract; both backends emit identical JSON at the configured API path (/bootui/api/** by default).
3. One engine. Advisor rule engines, scanners, the OSV scanner, the OTLP/telemetry store, JVM/MXBean readers, the dependency catalog, secret masking, scoring, and the MCP server move into a shared, Spring-free engine module.
4. Thin per-framework adapters. Spring and Quarkus each provide: a web binding (Spring MVC controllers vs JAX-RS / Vert.x routes), implementations of a small portability SPI, a safety-filter binding, and an activation hook.

Non-goals

• Native-image BootUI. BootUI is dev-only; Quarkus dev mode is always JVM mode (see §6), so native is out of scope.
• Integrating into Quarkus's built-in Dev UI (/q/dev). BootUI keeps its own standalone console (/bootui/ by default). Quarkus Dev UI uses build-time Lit web components; reusing our Vue UI is what keeps the UI shared.
• 100% panel parity. A curated subset ships on Quarkus (§5). Spring-only panels are dropped or replaced.
• Spring Boot 3.x / Gradle — unchanged, still out of scope.

2. Why this is feasible — evidence from the current codebase

The repository already separates "what the data means" (framework-neutral) from "where the data comes from" (Spring-specific). Measured against the current tree:

The coupling that remains is concentrated in: the web layer (@RestController), the Actuator/ApplicationContext/ Environment data readers, the servlet safety filters, and the EnvironmentPostProcessor-based config plumbing. That is exactly the surface the SPI seam abstracts.

3. Current module topology

Current modules and their roles:

SHARED (framework-neutral, built once, reused by both backends)
  bootui-core                    DTO records, SecretMasker, BootUiInfo
  bootui-engine                  Framework-neutral services, advisors, and io.github.jdubois.bootui.spi ports
  bootui-conformance             Shared HTTP contract suite and golden panel manifests
  bootui-ui                      Vue 3 SPA, built once

SPRING ADAPTER
  bootui-spring-autoconfigure        Shared Spring MVC/WebFlux auto-configuration, endpoints, SPI implementations, and safety
  bootui-spring-boot-starter         Drop-in Spring MVC starter
  bootui-spring-boot-starter-reactive
                                     Drop-in Spring WebFlux starter
  bootui-spring-sample-app           Spring MVC demo/integration app + Playwright e2e
  bootui-spring-webflux-sample-app   Spring WebFlux demo/conformance app

QUARKUS ADAPTER
  bootui-quarkus-parent              Shared Quarkus LTS BOM and plugin management
  bootui-quarkus                     Runtime JAX-RS/Vert.x resources, SPI implementations, and safety filters
  bootui-quarkus-deployment          Build-time wiring, capability gates, and production-dark activation
  bootui-quarkus-integration-tests   Docker-free @QuarkusTest conformance and smoke tests
  bootui-quarkus-sample-app          Demo/integration app

Dependency direction is one-way: bootui-engine depends on bootui-core; both adapters depend on the shared modules; the shared modules never depend on Spring, Quarkus, servlet, JAX-RS, Vert.x, or either framework's JSON library. The neutral SPI remains the io.github.jdubois.bootui.spi package inside bootui-engine.

bootui-core ◄── bootui-engine ◄── Spring and Quarkus adapters
      ▲                ▲
      └────────────────┘

bootui-ui           built once and packaged for each adapter
bootui-conformance  exercises the same HTTP contract against each adapter

How the web layer stays mostly shared

Spring MVC/WebFlux and JAX-RS annotations are incompatible, so their adapter-specific bindings cannot be one class. The fix is to keep bindings thin and push all logic into shared bootui-engine services:

Spring:   @RestController BeansController ─┐
                                           ├─► (shared) service in bootui-engine ─► DTO from bootui-core
Quarkus:  @Path JAX-RS resource ───────────┘         (calls an SPI provider for raw data)

Most BootUI controllers are already shaped this way (e.g. ArchitectureController → ArchitectureScanner, VulnerabilitiesController → DependencyProvider/OsvVulnerabilityScanner). The refactor extracts the scanner/service into bootui-engine and leaves a ~10-line binding in each framework module.

4. The portability SPI (the io.github.jdubois.bootui.spi package in bootui-engine)

Small interfaces the shared engine calls; each framework implements them. Names are illustrative.

The framework-neutral safety decision (loopback check, Host/allowed-hosts validation, Origin/Sec-Fetch-Site CSRF defense) is extracted into a shared LocalhostGuard in bootui-engine, reusing the existing CidrRange / ContainerGatewayDetector logic. Each framework only supplies request metadata and writes the deny response.

Per-panel access rules (bootui.panels.<id>.enabled / .read-only, plus the global bootui.read-only) are a separate, sibling mechanism — implemented on Spring as PanelAccessFilter and, at full behavioral parity (same config keys, same canonical JSON 403 body), on Quarkus as QuarkusPanelAccessFilter. Both bind to the same shared BootUiPanels registry to resolve a request path to a panel id and its actionCapable() flag, and both run as a second filter after the loopback/Host/CSRF guard (QuarkusPanelAccessFilter is registered at a lower Vert.x filter priority than BootUiQuarkusSafetyFilter, so a request failing both checks is rejected by the safety guard, not the panel-access filter).

5. The Quarkus panel set

The console keeps a single routes.js. For every route, the backend's /bootui/api/panels manifest returns a PanelDto: available reports whether the adapter can currently serve the panel, and unavailableReason explains why when it cannot. The separate enabled, readOnly, and readOnlyReason fields describe operator policy. App.vue uses those fields so the same UI build renders the correct sidebar and status on each backend.

Implementation status (current). The Quarkus adapter now lights up the large majority of the panel set — all of §5.1 and §5.2 below, plus the advisors (Architecture, the Quarkus application advisor replacing Spring, Hibernate, Pentesting, a Quarkus-native Security advisor, REST API, Memory) and the §5.3 capture panels (HTTP Exchanges, Live Activity, Log Tail, SQL Trace, REST Client, Exceptions, Security Logs, Email, Kafka, RabbitMQ). Action-capable panels behave identically to Spring, behind the shared LocalhostGuard write floor: Heap Dump (capture/analyze/delete/download), Threads (download), the advisor scans, Loggers (set level), HTTP Probe, Cache (clear), Flyway (migrate/clean), Liquibase (update), Traces (clear), Email (clear), Kafka (clear), RabbitMQ (clear), REST Client Reactive (clear + recording toggle), and the MCP Server toggle. Eight panels — GraalVM, CRaC, Conditions, Startup Timeline, HTTP Sessions, Spring Data, Spring Security, and DevTools — are intentionally unavailable with a panel-specific not-applicable reason (§5.5). JMS is the sole panel that is not yet available on Quarkus (§5.6). The per-panel **Implemented** markers below and docs/FEATURES.md carry the authoritative, current per-platform detail.

Expensive advisor actions also share Spring's per-scanner single-flight contract: overlapping Architecture, Quarkus-application, Hibernate, Memory, Security, Pentesting, REST API, and Vulnerabilities/OSV scans fail fast with the canonical JSON 409 response, while Heap Dump capture/analyze/delete share one mutation-domain admission. MCP returns the same busy message in-band, and passive reads continue serving the last completed report.

5.1 Ported as-is — framework-agnostic or same library (19)

Logic lives entirely in bootui-core + bootui-engine; the Quarkus adapter adds at most a trivial supplier.

Memory · Live Memory · JVM Tuning · Heap Dump · Threads (pure JVM MXBeans) · Metrics (Micrometer — same API) · Hibernate advisor (same 72-rule registry/report contract; mapping and configuration rules port, while Spring Data query rules skip when repository metadata is unavailable) · Hibernate Statistics (standalone Database-section panel over org.hibernate.stat.Statistics, gated on the same Hibernate ORM capability as the advisor; its explicit runtime-enable action has the same read-only and cross-site-write protection as Spring) · Vulnerabilities (classpath Maven metadata + OSV) · Pentesting · HTTP Probe (local HTTP probing) · AI Framework · Traces (OTLP — a standard; Quarkus/LangChain4j export it) · GitHub (HttpClient) · Copilot · Claude Code (read ~/.copilot / ~/.claude) · MCP Server (Implemented — full JSON-RPC bridge: the shared engine McpDispatcher owns method routing/gating/tool lookup, a thin Jackson-2 QuarkusMcpEnvelope codec + QuarkusMcpTools catalog + working enable toggle sit behind the LocalhostGuard write floor; JVM-mode integration is covered end to end, while native-image availability follows each backing panel and is not claimed beyond the native-image tests that exercise that capability) · Dev Services (Implemented — a Quarkus-native concept; build-time DevServicesResultBuildItem snapshot captured via recorder + synthetic bean, masked config, logs/restart unavailable; service type classified via the shared DevServiceTypeInference engine helper, matching Spring's classification).

Pentesting uses the shared 80-check engine and report contract. Its thin Quarkus collector supplies the live port, quarkus.http.root-path, CORS, OIDC auth-server URL, and direct-listener TLS posture, with TLS property-name discovery bounded at 4096 entries. It explicitly marks Spring endpoint/security metadata unavailable; A01 is therefore NOT_APPLICABLE, while no-finding mixed categories use Quarkus-specific INFO wording rather than a false pass. The explicit scan sends at most one GET and one OPTIONS request directly to 127.0.0.1, with no redirect, proxy, or external host access. See PENTEST-CHECKS.md for the exact evidence limits and mappings.

5.2 Ported by swapping the data source (12)

Same DTO and UX; the Quarkus adapter implements the relevant SPI against a Quarkus API.

Health (→ SmallRye Health) · Configuration (Implemented — → SmallRye Config; read path enumerates/masks/pages the effective config, read-only on Quarkus because the runtime-override write path is Spring-bootstrap-specific) · Profile Diff (Implemented — → SmallRye Config; groups active %profile.-prefixed keys) · Loggers (→ JBoss LogManager) · Mappings (Implemented — → the application's JAX-RS resources scanned from the build-time Jandex index by a registerMappings build step + @Recorder into a synthetic bean; same paged MappingProvider DTO as Spring's Actuator read, BootUI's own routes filtered out at build time) · Flyway (→ quarkus-flyway) · Liquibase (Implemented — → quarkus-liquibase; discovered via LiquibaseFactoryUtil.getActiveLiquibaseFactories(), the shared RanChangeSet history read + update action behind the same DTO contract) · Scheduled Tasks (→ quarkus-scheduler) · Fault Tolerance (Implemented — → SmallRye Fault Tolerance; @CircuitBreaker, @Retry, @Timeout, @Bulkhead, @RateLimit, and @Fallback declarations are scanned from the build-time Jandex index by a registerFaultTolerancePolicies build step + @Recorder into a synthetic bean, then mapped onto the same FaultTolerancePolicyProvider SPI and DTO contract Spring's Resilience4j/Spring Retry providers use. MicroProfile Fault Tolerance configuration overrides (<class>/<method>/<annotation>/<member> and its two broader forms) are resolved at runtime through SmallRye Config and reported with CONFIGURED provenance, including the .../<annotation>/enabled switches and MP_Fault_Tolerance_NonFallback_Enabled: a policy the application turned off through configuration is listed with a leading enabled = false setting instead of being silently shown as if it still applied. Live circuit-breaker state and state-transition events come from CircuitBreakerMaintenance, which SmallRye only exposes for breakers carrying @CircuitBreakerName; anonymous breakers honestly report UNKNOWN. Honest fidelity gaps: SmallRye publishes no per-call event stream, so retries, rejections and timeouts are not individually captured on Quarkus (only breaker state transitions are), and it exposes no per-policy call counters through a public API, so the metrics block is reported absent rather than invented. The whole integration is capability-gated on Capability.SMALLRYE_FAULT_TOLERANCE, with SmallRyeCircuitBreakerStates — the only class importing the fault-tolerance API — R2-excluded from Arc when the extension is absent) · Architecture advisor (shared ArchUnit registry; generic rules run unchanged, Spring-only annotation rules no-op, and Jakarta-based/platform-sensitive rules use Quarkus semantics) · Beans (Implemented — → Arc/CDI BeanManager.getBeans(...), with resolved injection edges captured after Arc build-time validation and overlaid on the retained runtime inventory; defining resources and Spring Conditions evidence remain unavailable) · Overview (panel available; the scoring dashboard aggregates the advisor endpoints client-side, and GET /bootui/api/overview reports the Quarkus version + shell chrome).

5.3 Kept, with a rebuilt capture layer or reduced fidelity (13)

The DTO and UI are reused; the Quarkus adapter rebuilds the capture/source on the reactive stack.

Current Quarkus messaging interceptor limitations. Incoming Kafka/RabbitMQ deliveries carry connector metadata and are captured normally. An outgoing message is captured only when it already carries the matching OutgoingKafkaRecordMetadata or OutgoingRabbitMQMetadata; a payload-only emission that relies entirely on channel configuration is not visible at the interceptor callback. SmallRye also selects only one default OutgoingInterceptor and one default IncomingInterceptor per channel. BootUI's Kafka and RabbitMQ pairs are both default-qualified at the same fallback priority, so an application that installs both connectors currently gets capture for only the pair SmallRye selects; a channel-specific application interceptor takes precedence over BootUI as designed. Finally, Kafka availability is currently gated by the broad Quarkus KAFKA capability, so an application with only the lower-level quarkus-kafka-client can over-report the panel as available even though Reactive Messaging capture is not wired.

Why the per-request profiler (GET /bootui/api/activity/{id}) is trace-id-only on Quarkus. Spring's /activity/request/{id} profiler is a Symfony-style join across SQL, exceptions, security audit events, the distributed trace, and timing for one request (LiveActivityCorrelator) — it is not CPU/flame-graph sampling. Its richness comes from a tiered correlation strategy: (1) OpenTelemetry trace id (the strongest, most precise signal), then, for requests without one, (2) HTTP method+path+time-window+thread heuristics for exceptions, (3) serving-thread correlation for SQL, and (4) time-window+principal for security events. Tiers 2-4 key on serving-thread identity: a servlet request runs start-to-finish on one worker thread that serves only one request at a time, so SQL, exceptions, and security events observed on that thread within its time window belong to it exactly, even with no distributed tracing configured at all (threadMatched is a first-class field on RequestProfileSecurityDto/carried by RequestProfileExceptionDto's thread). Quarkus's Vert.x event-loop-plus-worker-thread model has no equivalent "the one thread that served this request" identity — handling can hop across the event loop and one or more worker threads — so tiers 2-4 have nothing to key on and are not ported (this was investigated and correctly ruled out as infeasible; see the PR that shipped this trace-id-only profiler for the reasoning).

Tier 1, however, is portable and is now implemented: the same trace-id stamping that powers the LiveActivityAssembler nesting above (§ the Live Activity row) is reused by a dedicated engine class, RequestProfileAssembler, to answer GET /bootui/api/activity/{id} directly. When the requested exchange carries a trace id, the endpoint gathers every SQL/exception/security entry sharing that exact trace id and returns available: true with sqlCorrelationApproximate: false (trace-id matching is exact, unlike Spring's time-window heuristics for untraced requests) and a notes entry disclosing that this is a reduced, trace-id-only profile — no time-window/thread-based correlation. threadMatched always reports false (Quarkus has no thread-identity concept to key on), while principalMatched on RequestProfileSecurityDto is honestly computed by comparing principals. Ambiguous trace ids (shared by more than one in-flight request — the same edge case the main feed already guards) render an available: true profile with empty correlated lists plus an explanatory note, never a hard failure or cross-request data leak. When the exchange has no trace id at all — OpenTelemetry absent, or this particular request predates quarkus-opentelemetry being added — the endpoint honestly returns available: false with a clear reason (RequestProfileDto.unavailable(...)) rather than fabricating a partial result. In the main feed, ActivityEntryDto.profileable is computed adapter-side in LiveActivityResource: true for request entries with a resolvable trace id, false otherwise; the shared engine's own profileable default is untouched so Spring is completely unaffected.

The optional durable JDBC persistence backend (bootui.activity.persistence.enabled) is implemented identically to Spring. Every engine class — ActivityStore, InMemoryActivityStore, JdbcActivityStore, BufferedActivityStore, ActivityCaptureCoordinator/ActivityCapturePoller, ActivityInstanceIds, ActivityStoreFactory, ActivityPersistenceSettings, SimpleDriverDataSource, BootUiJdbcCaptureGuard — is 100% framework-neutral and reused unchanged; nothing in bootui-engine needed to change to support Quarkus. BootUiEngineProducer @Produces the ActivityPersistenceSettings (read live from MicroProfile Config, matching Spring's relaxed-binding defaults) and ActivityStore (built by the same ActivityStoreFactory.create(...), resolving a DataSource through Instance<DataSource> for SHARED mode) beans unconditionally — like the Cache/Flyway/Liquibase/Connection-Pools producers, since ActivityStoreFactory itself renders a harmless InMemoryActivityStore when disabled, so there is no capability gate, no ExcludedTypeBuildItem, and no R2 classloading trap to guard against (javax.sql.DataSource is a JDK type, not an optional library). Because both beans always exist, LiveActivityResource injects ActivityStore and ActivityPersistenceSettings directly (no Instance<> wrapper needed) and branches its activity() method on persistenceSettings.enabled() exactly like Spring's controller. Unlike Spring — whose inferred-destroy-method convention auto-closes the ActivityStore bean at context shutdown — CDI/Arc has no equivalent automatic behavior, so a small dedicated lifecycle bean, QuarkusActivityCapture, fills the gap: @Observes StartupEvent builds the sequencer/coordinator/poller and starts polling LiveActivityResource#mergedReport on bootui.activity.persistence.capture-interval (only when enabled), and @Observes ShutdownEvent stops the poller — making one last synchronous capture pass first, so entries produced since the last tick aren't dropped — then unconditionally closes the store, which flushes any still-buffered entries with the same bounded (2-10s), never-blocks- shutdown guarantee BufferedActivityStore#close() gives Spring. The one honest, pre-existing divergence: Quarkus's baseline (persistence-disabled) feed has no server-side type/severity/since filtering to begin with (unlike Spring's separate LiveActivityService, the shared LiveActivityAssembler Quarkus's resource calls has none), so those filters take effect on Quarkus only once persistence is enabled and the query is served from the ActivityStore — the KPI strip stays computed from the full, unfiltered live merge either way, on both adapters.

Live Activity's Live flow service map (GET /bootui/api/activity/service-map) is implemented identically to Spring. LiveServiceMapResource is a thin JAX-RS binding that gathers evidence from beans this adapter already owns — the Vert.x-fed HttpExchangeBuffer (through the shared HttpExchangesService, so self-filtering and masking are inherited), the RestClientTraceRecorder, the Agroal-backed ConnectionPoolService, the optional Instance<SqlTraceRecorder>, and the shared KafkaActivityRecorder/RabbitActivityRecorder — and delegates every interpretation rule to the framework-neutral ServiceMapAssembler, so the wire contract is byte-identical across all three runtimes. Each source is gated on both QuarkusPanelAvailability.isPanelAvailable and isPanelEnabled, so a panel that is unavailable on this runtime or switched off by the live access policy contributes nothing rather than appearing as a dependency with no traffic; an unsatisfied SqlTraceRecorder (no Agroal datasource) simply yields no statement evidence. The resource is registered through BootUiQuarkusProcessor.addBeanClasses(...) like every other runtime resource, is strictly read-only, and performs no network call, probe, or scan. sources() always passes cacheAvailable: false with an empty event list — this runtime has no CacheActivityRecorder-equivalent bean at all, for the identical reason its Live Activity feed carries no CACHE entries (quarkus-cache's built-in interceptors leave no comparable interception seam) — so the map never draws a cache dependency it cannot honestly back with evidence.

The map's opaque ServiceMapInteractionDto.flowId needed no Quarkus-specific work either, and comes almost for free. ServiceMapAssembler derives it one-way from whatever distributed-trace id was already captured on the HttpExchangeBuffer/RestClientTraceRecorder/SqlTraceRecorder entries this resource reads — the same capability-gated QuarkusOtelTraceIdProvider stamping described above for the Live Activity feed. So wherever quarkus-opentelemetry is present, an inbound request, its SQL, and any outbound REST call sharing one trace already correlate into one flow on this map with no additional code; only cache participates on Spring MVC/WebFlux alone, since Quarkus captures no cache evidence to correlate in the first place.

Two Live Activity SSE source-subscription gaps are now closed. LiveActivityResource#stream previously fanned in the HTTP exchange buffer, scheduled-task runs, Kafka, RabbitMQ, captured email, and REST Client calls, but neither the SQL trace recorder nor the exception store — both of which already fed activity(). A purely database-driven or purely failing workload therefore left the panel silently stale until an unrelated signal arrived. Both now subscribe like every other source (the SQL recorder through a resolvable-guarded change source, since it is an optional bean), which also keeps the Live flow map — which refreshes off the same tick — honest for JDBC and failure evidence. The shared Quarkus SSE helper coalesces any number of notifications into one pending update while downstream has no demand, rather than using an unbounded buffer; normal delivery and the existing per-resource maximum-open-stream limit remain unchanged.

The runtime "Use the existing datasource" hot-switch is also implemented identically to Spring. The shared engine ActivitySwitchService — which verifies/creates the backing table over the resolved DataSource and atomically swaps the live SwitchableActivityStore's delegate from InMemoryActivityStore to a newly built durable BufferedActivityStore, starting its capture poller in the same step — is reused unchanged; BootUiEngineProducer@Produces a SwitchableActivityStore in front of it (rather than producing ActivityStore directly), and a thin LiveActivityResource#useExistingDatasource mirrors Spring's controller method: 404 when no DataSource is present, 400 when the request is not explicitly confirmed, 200-and-no-op when persistence is already active, and 200 with the store swapped and capturing on success — all behind the shared LocalhostGuard write floor. Every GET /bootui/api/activity response carries the same persistenceOption field ({"active": false, "dataSourceAvailable": true, "tableName": "bootui_activity"}) the Vue UI reads to render the "Currently saving N events in memory" tip and the Use a database button/confirmation flow, so the panel behaves and looks identical on both adapters.

5.4 Replaced with a Quarkus-native panel (3)

5.5 Dropped on Quarkus (9)

No equivalent, low value, or superseded by Quarkus's own tooling:

• Build-time model differences: Conditions (Quarkus resolves conditions at build time — no runtime report), Startup Timeline (build-time augmentation eliminates startup steps — there is no runtime per-step buffer like Spring's BufferingApplicationStartup, only coarse boot totals — so it is reported not applicable, not not yet, alongside GraalVM/CRaC).
• Different security/data stacks: Spring Security, Spring Data (Quarkus uses Elytron/OIDC and Panache).
• Hibernate advisor query rules: mapping/configuration rules run against Quarkus' JPA metamodel, but HIB-QUERY rules remain unavailable because Panache exposes no reliable runtime equivalent of Spring Data repository query metadata.
• Servlet-only / low value on a reactive stack: HTTP Sessions.
• Superseded or moot: GraalVM readiness (Quarkus is native-first with its own build), CRaC (BootUI's advisor and generated assets depend on Spring LifecycleProcessor, Spring scheduling, Spring Boot Hikari integration, and spring.context.checkpoint=onRefresh, so partial reuse would be misleading), DevTools (Implemented as NOT_APPLICABLE — Quarkus has built-in dev-mode live reload, so there is no Spring-style DevTools restart/LiveReload to expose; the panel reports not applicable rather than not yet).
• No comparable capture hook: Transactions — capture relies on Spring Framework's TransactionExecutionListener, registered against ConfigurableTransactionManager beans. Quarkus's transaction management goes through Narayana's JTA TransactionManager/Synchronization or the CDI @Transactional interceptor, neither of which exposes a comparable per-boundary listener without far more invasive instrumentation (wrapping every @Transactional bean with a custom interceptor ordered ahead of every other interceptor); the panel honestly reports not applicable rather than forcing a lower-fidelity capture path.

5.6 Not yet available on Quarkus (1)

• JMS uses Spring JMS (JmsTemplate and @JmsListener) today. Quarkus users can use the implemented Kafka and RabbitMQ panels while a Quarkus-native JMS capture layer remains unimplemented.

Result: 47 of the 57 panels ship on Quarkus: 26 are statically available and 21 are capability/detector-gated. The remaining 10 panels do not ship: 9 are intentionally not applicable (GraalVM, CRaC, Conditions, Startup Timeline, HTTP Sessions, Spring Data, Spring Security, DevTools, Transactions), and 1 (JMS) is not yet available. By portability strategy, the 47 shipped panels comprise 19 ported as-is, 12 source-swapped, 13 capture-rebuilt, and 3 replaced with a Quarkus-native panel. The Overview dashboard panel is available (its scoring dashboard renders client-side from the advisor endpoints, and the shell-chrome GET /bootui/api/overview endpoint is served on both adapters).

6. Activation & safety on Quarkus

• Dev-mode-only extension. The bootui-quarkus-deployment module registers BootUI's routes and beans only in dev mode via @BuildStep. This is the natural Quarkus analogue of BootUI's "active only in dev/local, fail closed" rule, and it means BootUI is simply absent from production/native builds.
• The static shell is dark in production too, not just the API. The launch-mode-gated @BuildSteps above stop BootUI's own CDI beans/JAX-RS resources from being wired in LaunchMode.NORMAL, but the compiled Vue bundle at META-INF/resources/bootui/ used to remain reachable regardless: Quarkus' built-in static-resource handler serves any classpath resource under META-INF/resources/** unconditionally, wired by quarkus-vertx-http independently of this extension's build steps, and Quarkus offers no build-time mechanism to exclude a single path from that scan. Left alone, a production deployment would still answer GET /bootui/ with the empty SPA shell's index.html/JS/CSS — no working API behind it, but reachable. BootUiProdShellGuardFilter closes this: a CDI Vert.x filter registered by its own always-on @BuildStep (deliberately not launch-mode-gated, the opposite polarity from every other build step in the extension), whose handle() method reads a CDI-injected LaunchMode and answers a plain 404 for the configured UI/API surface and the private /bootui classpath mount only when it is LaunchMode.NORMAL — an immediate no-op pass-through otherwise, so dev/@QuarkusTest behavior is unaffected. Net effect: the public and internal BootUI paths are plain 404s in production, at parity with the Spring adapter, whose BootUiShellGuardAutoConfiguration answers the same 404 for the same reserved /bootui mount whenever BootUI's activation condition resolves to disabled — Spring Boot's default static-resource handling exposed the packaged shell there for exactly the same reason (#856). Proven by a genuine LaunchMode.NORMAL build+run via QuarkusProdModeTest (BootUiQuarkusProdShellGuardBootTest, in the dedicated bootui-quarkus-prod-shell-guard-integration-tests module — kept separate from every @QuarkusTest-based module because Quarkus's own test framework refuses to mix QuarkusProdModeTest and @QuarkusTest in the same Surefire fork), alongside a white-box unit suite (BootUiProdShellGuardFilterTest, in bootui-quarkus) — see BootUiQuarkusProcessor's class Javadoc for the full investigation.
• Native is therefore a non-issue. Quarkus dev mode always runs on the JVM, so the bytecode-scanning advisors, classpath Maven metadata (Vulnerabilities), and JVM MXBeans all work exactly as on Spring. The native-image limitations (no runtime classpath scan, stripped metadata) only apply to production native images, which BootUI never ships in.
• Loopback safety preserved. The shared LocalhostGuard enforces the same loopback / allowed-hosts / CSRF rules; the Quarkus adapter binds it as a high-priority Vert.x handler after configured public requests have been rerouted to the private mount, failing closed for non-loopback callers — matching LocalhostOnlyFilter's Integer.MIN_VALUE servlet ordering.
• Per-panel access gating at parity. QuarkusPanelAccessFilter enforces bootui.panels.<id>.enabled / .read-only and the global bootui.read-only, mirroring Spring's PanelAccessFilter exactly (same config keys, same BootUiPanels path resolution, same canonical {"error":"BootUI panel access denied","panel":"<id>", "reason":"<reason>"} JSON 403 body). It runs as a lower-priority Vert.x filter than BootUiQuarkusSafetyFilter, so the loopback/Host/CSRF guard always evaluates first. QuarkusPanelAvailability and QuarkusMcpPanelPolicy (the MCP tool gate) both read the same config, so a disabled or read-only panel is refused consistently across the REST API, the /bootui/api/panels manifest, and the MCP bridge. Backend/integration coverage lives alongside the runtime classes; browser-level coverage is bootui-quarkus-sample-app/e2e/tests/read-only.spec.js, the Quarkus twin of the Spring sample's read-only.spec.js — it spawns fresh, throwaway quarkus:dev instances with bootui.read-only / bootui.panels.<id>.read-only passed as plain JVM system properties (MicroProfile Config picks these up live, the same mechanism playwright.config.js already relies on for -Dquarkus.http.port) and asserts both the API (403 + canonical reason) and the shared Vue UI (disabled controls, the panel-read-only-alert banner) reflect the setting. One divergence from the Spring spec: it cannot use the config panel as the "unaffected control panel" the way Spring does, because Configuration is always read-only on Quarkus for an unrelated reason (no runtime-override write path yet — see above); it uses memory instead.

Configurable path routing

bootui.path and bootui.api-path use the same normalized contract as the Spring adapters. /bootui and /bootui/api remain the defaults. The public paths compose with quarkus.http.root-path; the host root is prepended exactly once to browser-visible links, the startup banner, session-cookie scope, and production suppression.

Quarkus' runtime and static resources remain registered at a private /bootui classpath/JAX-RS mount. An early Vert.x filter recognizes only the configured public UI/API paths and reroutes them internally without redirecting the browser. It preserves the query string, marks the routing context before rerouting to prevent recursion, and sends the bare and trailing-slash shell paths through the index resource so both receive runtime <base> and API metadata. When bootui.path is custom, direct requests to the private /bootui mount return 404; it is not exposed as a legacy alias. The later safety, authentication, panel-access, and response-header filters therefore continue to enforce one internal route shape without weakening the public boundary.

The UI path cannot be nested under /bootui/**, which avoids collisions with that private mount. Invalid active configuration fails dev/test startup. Production remains dark even if dormant path settings are invalid: the always-registered production guard uses fail-closed safe defaults and suppresses both configured/default and private mounts without wiring data-bearing resources.

BootUI's own requests are excluded from the telemetry it reports on. HTTP-exchange capture, request-failure capture, pre-mapping exception capture, and log-based exception capture all resolve "is this BootUI?" through one shared matcher that strips quarkus.http.root-path and matches the configured bootui.path / bootui.api-path mounts as well as the private /bootui mount. The console therefore never appears in HTTP Exchanges, Live Activity, or Exceptions under a custom root path or a custom mount, while application paths that merely resemble the console — /bootui-other, for instance — remain captured.

7. Code-sharing scorecard

The Quarkus-specific code is concentrated in the SPI implementations, the thin web layer, and the extension plumbing — deliberately small relative to the shared engine and UI.

8. Quarkus sample app & end-to-end testing

Quarkus support needs its own reference application, mirroring bootui-spring-sample-app: a new bootui-quarkus-sample-app reactor module that is a deliberately feature-rich Quarkus dev application exercising every supported panel, plus a parallel Playwright suite. Like the Spring sample app it is demo/integration only and must set <maven.deploy.skip>true</maven.deploy.skip> so it is never published to Maven Central, while still building as part of the reactor.

Its job is the same as the Spring sample app's: give every panel realistic, non-sensitive data and seed intentional anti-patterns so the advisors and the Overview score produce demonstrable findings (and so screenshots show populated panels, per the contributor guidance).

8.1 Ingredient mapping

The Spring sample app already wires up one feature per panel. The Quarkus sample app mirrors each with its Quarkus counterpart; ingredients for dropped/replaced panels are swapped or omitted.

Pure-JVM panels (Memory, Threads, Heap Dump, …) and host-level panels (GitHub, Copilot, Claude Code, Vulnerabilities, Pentesting, HTTP Probe, MCP Server) need no special ingredients — they work against any running Quarkus dev app.

8.2 Dev loop & CI

• Run: ./mvnw -pl bootui-quarkus-sample-app -am quarkus:dev starts Quarkus dev mode and serves the console at http://localhost:8082/bootui — the analogue of the Spring sample app's spring-boot:run smoke-test path (the sample app defaults to 8082, not 8080, so it can run alongside the Spring servlet sample app (8080) and the Spring WebFlux sample app (8081) for the cross-service trace demo — see bootui-spring-sample-app/README.md). Quarkus live reload replaces DevTools for the inner loop. (-am builds the upstream bootui-quarkus extension first.)
• e2e: a bootui-quarkus-sample-app/e2e/ Playwright project mirrors bootui-spring-sample-app/e2e/, with one spec per supported panel plus quarkus-advisor.spec.js / cache.spec.js; drop specs only for the panels genuinely not shipped on Quarkus (conditions, startup, spring-security, data, http-sessions, graalvm, crac, devtools) covered instead by not-applicable.spec.js. (An earlier revision of this plan also listed beans, profile-diff, and security as drop candidates; all three shipped and now have dedicated specs — see §5 for the authoritative per-panel availability.) Reuse the existing fixtures.js / app-shell.spec.js patterns. To honor the "as much common code as possible" goal, factor the panel-agnostic Playwright helpers into a shared library both suites import, rather than copying them.
• CI: add a job mirroring the existing Spring e2e job in .github/workflows/build.yml — build the extension + sample app, npx playwright install --with-deps chromium, then npm test — so both platforms are gated on every build.
• Screenshots: the docs screenshots in docs/images/bootui-*.webp are captured from the Spring sample app and stay the canonical set. The Quarkus sample app's e2e can reuse scripts/capture-docs-screenshots.mjs if/when the docs add Quarkus-specific imagery; otherwise it is test-only.

9. Phased delivery

1. Phase 0 — Refactor in place (no behavior change). Introduce bootui-engine and its io.github.jdubois.bootui.spi package; move framework-neutral services and advisor engines out of bootui-spring-autoconfigure; reimplement the Spring controllers as thin bindings over the shared services; extract LocalhostGuard. Spring BootUI must stay green (all existing JUnit, Vitest, and Playwright suites pass) — this phase ships value even without Quarkus.
2. Phase 1 — Quarkus MVP. Stand up bootui-quarkus + -deployment, serve the shared UI at /bootui/, wire the Vert.x safety handler and dev-mode activation, and light up §5.1 + §5.2 panels (the framework-agnostic and source-swapped sets). Stand up bootui-quarkus-sample-app and its parallel Playwright run (§8) to gate the work.
3. Phase 2 — Advisors & replacements. Port the REST API handler model to JAX-RS, add the Quarkus advisor ruleset, and add the Quarkus Cache panel. Grow the sample app and e2e specs to match.
4. Phase 3 — Capture panels. Implement the Vert.x/Agroal/LogManager-based capture for the §5.3 set.

10. Risks & open questions

• Overlap with Quarkus Dev UI. The source-swapped runtime panels (Config, Health, Mappings, Scheduled, …) duplicate Quarkus's built-in Dev UI. BootUI's net-new value on Quarkus is the advisor + scoring + agent (MCP) loop — which is also the most portable part. Lead with it; treat generic runtime panels as table stakes.
• Build-time augmentation effort. A Quarkus extension (runtime + deployment + @BuildSteps) is more involved than a Spring auto-configuration. Phase 0/1 should validate the route + dev-mode wiring early.
• Reactive capture fidelity. Vert.x-based request/exchange/SQL capture must be verified to match the servlet panels' detail (timing, headers, correlation). Correlation is now resolved via the OpenTelemetry trace id (Live Activity nests SQL/exceptions/security events under their request, and stamps securedPrincipal, when quarkus-opentelemetry is present); the per-request profile drill-down is now implemented too, but in reduced, trace-id-only form — Spring's time-window/thread-based tiers lean on servlet thread-per-request serving-thread identity that the Vert.x model has no equivalent for, so they remain deliberately unported (§5.3 has the detailed reasoning).
• Module naming & coordinates. New shared/adapter modules keep com.julien-dubois.bootui:* coordinates and io.github.jdubois.bootui.* packages; the Quarkus extension follows Quarkus's runtime / deployment convention.
• Docs & checks. The Quarkus application advisor is backed by docs/QUARKUS-ADVISOR-CHECKS.md and the Quarkus Security advisor by docs/QUARKUS-CHECKS.md, mirroring the existing *-CHECKS.md files; docs/FEATURES.md would gain a per-platform availability note; and the contributor docs (CONTRIBUTING.md, AI instructions) would document the second sample app and its e2e suite.

11. Appendix — full panel disposition

Port = ships from shared code · Adapt = swap data source via SPI · Rebuild = reimplement capture · Replace = Quarkus-native panel · Drop = intentionally not applicable · Not yet = not currently shipped.