BootUI properties

BootUI reads its bootui.* configuration from the host application's own configuration — Spring Boot property sources on the Spring adapter, MicroProfile Config on the Quarkus adapter. It is local-only by default: it activates only in development contexts, rejects non-loopback callers, masks secret-like values, and disables itself for production profiles unless explicitly forced on.

Panel settings are consistent across the UI and API:

• Every visible panel has bootui.panels.<panel-id>.enabled with default true.
• Panels with browser-triggered actions also have bootui.panels.<panel-id>.read-only with default false.
• bootui.read-only=true makes every action-capable panel read-only, even when the per-panel read-only flag is false.
• Disabled panels are moved to the Disabled / unavailable sidebar group and their panel API routes return 403.
• Read-only panels keep read endpoints visible but block mutating API requests. Safe methods (GET, HEAD, OPTIONS) remain allowed.

Spring vs Quarkus (cross-adapter parity)

BootUI targets Spring Boot and Quarkus from one codebase, and its bootui.* keys are largely the same by name on both adapters — but they are read by different configuration engines, and a few keys are platform-specific.

How keys are read. On Spring, bootui.* keys are bound once into a @ConfigurationProperties object, so Spring's relaxed binding applies (camelCase, kebab-case, and underscores are all accepted). On Quarkus, each key is read live, per request through MicroProfile Config and must be written in exact kebab-case; a missing or invalid value fails closed (for example, masking stays on and non-loopback access stays denied). Most keys below are honored identically on both adapters.

Activation. Spring decides activation at runtime from bootui.enabled and the enabled-profiles / disabled-profiles lists (plus DevTools). Quarkus decides activation at build time from the launch mode: the console is wired in dev and test and is completely absent (prod-dark) in a production build. The three Spring activation keys therefore have no effect on Quarkus.

Host application namespace. The host application itself is configured with its own framework's properties — spring.* on Spring, quarkus.* on Quarkus. BootUI does not read spring.* keys on Quarkus; its advisors bridge the two namespaces internally (for example, the Hibernate advisor maps the Spring property names its rules expect onto their quarkus.hibernate-orm.* equivalents).

Keys that are not shared

Keys with a shared name but platform-specific behavior

Everything not listed in the two tables above is honored under the same key — and with the same default — on both adapters. This includes the safety keys (bootui.allow-non-localhost, bootui.allowed-hosts, bootui.trusted-proxies, bootui.trust-container-gateway, bootui.authentication.token), bootui.expose-values, bootui.mask-secrets, bootui.path / bootui.api-path, bootui.monitoring.exclude-self, bootui.http-exchanges.max-exchanges (default 200), bootui.log-tail.max-bytes (default 0, meaning unbounded), and the bootui.github.*, bootui.vulnerabilities.* (including osv-base-uri, default https://api.osv.dev), bootui.sql-trace.*, bootui.transactions.*, bootui.telemetry.* (except max-request-bytes), bootui.heap-dump.*, bootui.exceptions.*, bootui.security-logs.*, bootui.cache.* (except .activity-capture-enabled and .activity-max-events, Spring only — see above), bootui.mcp.*, bootui.cli.*, bootui.ai.*, bootui.copilot.*, and bootui.claude-code.* families. It also includes the per-panel access keys — bootui.panels.<id>.enabled / .read-only and the global bootui.read-only — which are enforced on Quarkus by QuarkusPanelAccessFilter at full behavioral parity with Spring's PanelAccessFilter (same config keys, same BootUiPanels path resolution, same canonical JSON 403 body); see "Panel access settings" below.

Global settings

Remote API authentication

The configured static SPA remains available after non-loopback access is explicitly enabled, but the configured API surface requires authentication for every caller whose raw TCP peer is not loopback. Paste the startup token into the unlock screen; BootUI exchanges it for an HTTP-only, SameSite=Strict session cookie scoped to the browser-visible API path (including the host application's context/root path), which also authenticates SSE streams and downloads. CLI, MCP, and OTLP clients should send the token using the standard HTTP bearer authorization scheme.

Localhost requests remain frictionless and do not require a token. Authentication is an additional layer: activation, source trust, Host validation, cross-site-write protection, panel access, and read-only checks still apply. Use HTTPS for direct remote access because bearer credentials sent over plain HTTP can be intercepted.

Custom UI and API paths

bootui.path is configurable on Spring MVC, Spring WebFlux, and Quarkus. /bootui remains the exact backward-compatible default. When only the UI path is set, the API path is derived after normalization:

bootui.path=/dev-console/
# Effective API path: /dev-console/api

Use bootui.api-path only when the API must live elsewhere:

bootui.path=/dev-console
bootui.api-path=/internal/bootui-api

Both values are relative to the application root. server.servlet.context-path, spring.webflux.base-path, or quarkus.http.root-path is prepended automatically and exactly once. Do not include that framework root in the bootui.* values.

BootUI trims surrounding whitespace and trailing slashes. It rejects blank or root paths, . / .. path segments, duplicate interior slashes, query/fragment content, percent encoding, backslashes, routing metacharacters, and any character outside RFC 3986's unreserved path-segment set. Invalid active configuration fails startup with the property name in the error. The UI path also cannot be nested below /bootui/**, which is reserved for Quarkus' private internal classpath mount; the exact /bootui default is valid, and the API default /bootui/api remains valid.

With a custom UI path, the old packaged /bootui mount is answered with 404 rather than retained as a compatibility alias. The generated SPA shell receives the fully composed UI/API locations at runtime, so assets, API calls, SSE, downloads, MCP configuration, and OTLP setup copy all follow the configured paths.

Panel access settings

Enforced identically on Spring and Quarkus (PanelAccessFilter / QuarkusPanelAccessFilter).

Per-panel action details

Startup Timeline

HTTP Sessions

GitHub

Configuration

Loggers

REST API

Spring

Spring Security

Security Logs

Security

Pentesting

Cache

Hibernate

Hibernate Statistics

Enable for this runtime starts statistics collection for the current application process only. It does not rewrite application configuration or reset existing counters, and it does not require confirmation. The action is blocked when either bootui.read-only=true or bootui.panels.hibernate-statistics.read-only=true. To enable collection persistently from startup, set hibernate.generate_statistics=true on Spring or quarkus.hibernate-orm.statistics=true on Quarkus, as recommended by HIB-CONFIG-007.

Database

Run Database checks performs bounded, read-only JDBC schema introspection. It does not require confirmation and is blocked when either bootui.read-only=true or bootui.panels.database-advisor.read-only=true.

Memory

Flyway

Liquibase

SQL Trace

Transactions

REST Client

WebSockets

BootUI never reads, decodes, or stores a WebSocket message payload on any stack; only frame size, direction, type, and destination are recorded, and provider session ids are replaced by a short one-way hash before they leave the process.

AI Framework

Live Activity

The Live Activity panel reuses the HTTP Exchanges, SQL Trace, REST Client, Exceptions, Security Logs, Cache, Scheduled Tasks, and Email sources, so disabling any of those panels through their own bootui.panels.* toggles also removes them from the stream. Kafka, RabbitMQ, and JMS capture additionally have their own bootui.kafka.*, bootui.rabbitmq.*, and bootui.jms.* toggles—see below—and each stops feeding Live Activity when its dedicated panel is disabled. The panel itself is read-only. A request whose correlated SQL trips bootui.activity.n-plus-one-threshold is flagged with a red N+1 badge both in the main stream row and in its profile drawer (the same threshold, so the two views never disagree); the drawer additionally lists the flagged group's call site(s) whenever bootui.sql-trace.capture-call-site is enabled.

Live Activity Kafka capture

When Kafka support is present, BootUI captures producer/consumer outcomes into the Live Activity stream as MESSAGING entries. Spring does this by wrapping application-owned KafkaTemplate and @KafkaListener container factory beans; Quarkus does it through SmallRye Reactive Messaging Kafka interceptors. Only metadata is captured — topic, partition, offset, a hash of the key, timing, success/failure, consumer group id when exposed, and listener id — the message value/payload is never captured, and failure text is generic so exception messages cannot leak payload or credentials. On Spring, the consumer group is available and the listener-id field currently carries the listener container factory bean name (not the resolved per-@KafkaListener id); on Quarkus the group is unavailable and the channel name is used as the listener id. Quarkus outgoing capture requires OutgoingKafkaRecordMetadata to be attached before the interceptor; payload-only emissions that rely solely on channel configuration are not recorded. See SPECIFICATION.md §5.14.2.

Live Activity JMS capture

On Spring MVC and WebFlux, spring-jms activates metadata-only capture for application-owned JmsTemplate and @JmsListener container factories. JMS has its own bounded recorder and settings, independent from Kafka and RabbitMQ, so one transport's traffic cannot evict another transport's history. Destination names are control-character-stripped, length-bounded, and credential-like URI/user-info or password/secret/token/API-key assignments are masked before storage. Unknown provider-specific Destination implementations are not rendered because their toString() output can expose broker metadata. Raw message IDs, payloads, arbitrary headers/properties, and exception messages are never stored; when a MessageCreator or MessagePostProcessor exposes the provider-assigned message ID, only its SHA-256 hash is retained. Quarkus does not claim a JMS capture integration.

Live Activity RabbitMQ capture

When RabbitMQ support is present, BootUI captures publish/consume activity as MESSAGING entries. Spring composes with application-owned RabbitTemplate before-publish processors and listener-factory advice; Quarkus uses SmallRye Reactive Messaging RabbitMQ interceptors. Message bodies and arbitrary headers are never captured. Routing metadata is bounded, correlation IDs are omitted by default and stored only as a SHA-256 hash when explicitly enabled, and failure details are generic so exception messages cannot leak payload or credential data. On Quarkus, producer exchange, consumer queue, and producer duration are unavailable because SmallRye's callbacks do not expose them; outgoing capture also requires OutgoingRabbitMQMetadata to be attached before the interceptor.

Live Activity durable persistence

Off by default: the merged stream stays in-memory-only, exactly as above. Setting bootui.activity.persistence.enabled=true additionally buffers captured entries and flushes them to a SQL database over direct JDBC, so history survives a restart and the dashboard can page back further than fits in memory. Available on both adapters with an identical config surface and wire contract; on Quarkus a QuarkusActivityCapture CDI bean (@Observes StartupEvent/ShutdownEvent) owns the capture-poller lifecycle instead of Spring's controller-inline wiring. See SPECIFICATION.md §5.14.2 for the full design (the ActivityStore abstraction, buffering/flush, merge-for-reads, re-queue-on-failure, the flush guard, and multi-tenancy).

Traces

HTTP Exchanges

HTTP Probe

Email

Kafka

The Kafka panel is a dedicated, filterable view over the same producer/consumer capture that feeds Live Activity's MESSAGING entries — see "Live Activity Kafka capture" above for the shared bootui.kafka.* capture properties (enabled, capture-key, max-entries, max-key-length), which tune both surfaces identically.

RabbitMQ

The RabbitMQ panel is a dedicated view over the same bounded capture that feeds Live Activity. On Spring it is available when a RabbitTemplate bean exists; on Quarkus it is available when quarkus-messaging-rabbitmq is present in dev/test mode. The bootui.rabbitmq.* properties above tune both surfaces.

Fault Tolerance

The Fault Tolerance panel reads protective policies live from Resilience4j registries, Spring Retry @Retryable metadata, and SmallRye Fault Tolerance annotations captured at build time on Quarkus. It is strictly capture-only: BootUI never opens, closes, resets, or otherwise mutates a circuit breaker, retry, rate limiter, bulkhead or time limiter. Captured events are metadata only — policy name, outcome, attempt number, duration, exception simple name, and circuit breaker state — never method arguments, return values or exception messages.

JMS

The JMS panel is a dedicated view over the same bounded Spring JMS capture that feeds Live Activity. The bootui.jms.* properties above tune both surfaces. Quarkus reports this panel not yet available.

Exceptions

Log Tail

Vulnerabilities

Heap Dump

Threads

Architecture

GraalVM

CRaC

Spring DevTools

Dev Services

Copilot

Claude Code

MCP server

The MCP server exposes BootUI's advisors and read-only diagnostics to local AI agents (GitHub Copilot, Claude Code) over a loopback-only Model Context Protocol endpoint at POST <bootui.api-path>/mcp (default POST /bootui/api/mcp). It is off by default and only ever active while BootUI itself is active, so it is never reachable in production. Tools inherit the same safety model as the panels: read tools require the backing panel to be enabled, action (*_scan) tools are additionally refused when the panel is read-only, and all values flow through the same secret masking as the REST API.

Command-line endpoint

The command-line endpoint projects the same tool registry the MCP server exposes onto plain REST, so a terminal or a CI job can ask a running application one diagnostic question without an MCP client. GET <bootui.api-path>/cli (default GET /bootui/api/cli) describes the tools this instance advertises, and POST <bootui.api-path>/cli/tools/{name} invokes one, returning its payload directly with the outcome in the HTTP status (403 panel disabled or read-only, 404 unknown tool, 400 bad argument, 409 action already running, 429 at capacity, 504 timeout).

It is on by default, because it is a different spelling of data the panel endpoints already serve rather than a new capability: every tool remains gated by its panel's enable/read-only settings, and the endpoint sits under bootui.api-path, so the loopback, Host allow-list, cross-site-write, and bootui.authentication.token protections apply unchanged. It does not require bootui.mcp.enabled, and its calls are counted separately so the MCP Server panel keeps reporting only what agents did.

Make the whole application read-only:

bootui.read-only=true

Hide one panel entirely:

bootui.panels.devtools.enabled=false

Keep one panel visible but disable its actions:

bootui.panels.config.read-only=true

Require both an action gate and panel read-only state to allow an action:

bootui.panels.dev-services.read-only=false
bootui.dev-services.restart-enabled=true