BootUI

BootUI is a local-only developer console designed for Spring Boot 4 (both servlet and WebFlux) and Quarkus applications. It provides a centralized UI for runtime observability, diagnostics, and application analysis without requiring Node.js or npm in the consuming application, as the Vue UI is packaged within the host app.

Core Capabilities

• Runtime Observability: Inspect health, metrics, memory, threads, heap dumps, startup timing, and JVM sizing.
• Advisors Dashboard: Analyze and score applications for architecture, REST API, Spring, Hibernate, JVM memory, Spring Security, and vulnerabilities.
• Diagnostics Toolbox: Review traces, log tails, HTTP exchanges, local probes, architecture checks, GraalVM readiness, and dependency vulnerabilities.
• Database Insight: Inspect connection pools, PostgreSQL vital signs, SQL traces, Hibernate statistics, transactions, Spring Data, Flyway, and Liquibase.
• Services and Integrations: Monitor scheduled tasks, REST clients, fault tolerance, WebSockets, caches, email, Kafka, RabbitMQ, and JMS.
• Developer Tooling: Dashboards for Spring DevTools, GitHub, Copilot, and Claude Code local activity.

BootUI is composed of several modules categorized by their role in the ecosystem:

Core & Engine

• bootui-core: Shared DTOs, secret masking, and core helpers.
• bootui-engine: Framework-neutral services/advisors and SPI ports.

Spring Framework Adapters

• bootui-spring-autoconfigure: Spring MVC/WebFlux adapter (auto-configuration, endpoints, safety).
• bootui-spring-boot-starter: Spring MVC starter dependency.
• bootui-spring-boot-starter-reactive: Spring WebFlux starter dependency.

Quarkus Framework Adapters

• bootui-quarkus: Quarkus runtime adapter.
• bootui-quarkus-deployment: Quarkus build-time wiring module.
• bootui-quarkus-parent: Shared Quarkus LTS BOM and plugin management.

Frontend & CLI

• bootui-ui: Vue 3 frontend packaged into META-INF/resources/bootui/.
• bootui-client: Dependency-free client for the command-line endpoint.
• bootui-cli: The bootui command-line interface, generated from the engine's MCP tool catalog.

Testing & Compliance

• bootui-conformance: Shared HTTP contract suite and golden panel manifests for all adapters.
• bootui-coverage: Aggregated coverage report (built by the coverage profile only).

BootUI supports three primary application stacks. While they share the same engine, console, and JSON contract, the available panels vary depending on the stack:

• Spring MVC: The reference stack. Supports every panel.
• Spring WebFlux: Supports every panel except HTTP Sessions (due to the lack of a servlet session registry).
• Quarkus: Supports most panels, but has specific permanent exclusions (see What is not on Quarkus).

Note that panel availability is also determined by your application's classpath. For example, if Kafka is not on your classpath, the Kafka panel will not be available. You can check the current availability for your specific application by opening the BootUI console or querying the /bootui/api/panels endpoint.

| Stack             | Panel availability                               | Setup                              |
| ----------------- | ------------------------------------------------ | ---------------------------------- |
| Spring MVC        | Every panel. This is the reference stack.        | [Setup](./SETUP.md)                |
| Spring WebFlux    | Every panel except **HTTP Sessions**.            | [WebFlux setup](./setup/webflux.md) |
| Quarkus           | Most panels — see [below](#what-is-not-on-quarkus). | [Quarkus setup](./setup/quarkus.md) |

The following features are implemented for Quarkus support:

BootUI provides a safe, local-only developer console for running applications. It uses a framework-neutral engine to serve a consistent Vue UI and a standardized /bootui/api/** API contract across different runtimes.

Supported Runtimes:

• Spring Boot 4 (supporting both servlet and WebFlux starters)
• Quarkus (via a dedicated extension)

Design Principles for Panels:

• Safety: Operations are primarily read-only or read-mostly. Any mutating actions (e.g., clearing a cache) require explicit confirmation gates.
• Fail-Closed Behavior: If required classes, beans, Actuator endpoints, or data are missing, panels must return stable empty DTOs and a clear reason for unavailability rather than crashing.
• Security: Sensitive property names, headers, addresses, or values must be routed through the existing masking and value-exposure model.
• Local-Only: Designed to operate safely within a local development context.

BootUI is a design system for a local-only developer console for Spring Boot applications. It is designed as a "Calm Control Room" to make dense telemetry (beans, config, health, traces, etc.) legible and unalarming.

Core Principles:

• Visual Identity: Uses a frosted-glass instrument panel aesthetic floating over a green→blue→violet gradient. It utilizes Spring green (#198754) and signal blue (#0d6efd) as its primary identity.
• Bootstrap Integration: Built on Bootstrap 5.3, but explicitly avoids the "default Bootstrap admin template" look. Bootstrap serves as the underlying utility layer, while the visible finish is defined by a custom token system.
• Calmness: The UI is designed to be quiet by default. Status colors (like red) are only used for genuine risks and are always paired with a text label to ensure clarity.
• Geometry: Features soft, generous geometry with a documented radius scale (typically 0.5–1.25rem) and low-profile shadows.
• Themes: Supports both Light and Dark themes (both targeting WCAG 2.1 AA compliance), plus opt-in skins like Graphite, Minimal, Cyberpunk, France, and Windows 95.

BootUI is an embedded, local-only developer console designed for Spring Boot 4 (servlet and WebFlux) and Quarkus applications. It acts as a framework-neutral visualization and explanation layer over your application's live runtime diagnostics and context.

Use Cases

• Understanding Wiring: Quickly see how beans are wired, which configurations are effective, and inspect endpoints.
• Onboarding: Understand unfamiliar profiles, conditional beans, and dependencies in inherited services.
• Debugging: Inspect local health, connection details, mappings, and configuration sources at a glance.
• Standardized Inspection: Provide a common diagnostic surface for platform engineers managing multiple Spring Boot or Quarkus services.

Key Distinctions

• Not an APM: It is not for production monitoring or hosted dashboards.
• Embedded: It runs inside your application via a Spring Boot starter or Quarkus extension.
• Local-First: It is intended for use on localhost during the inner development loop.

When EPSS (Exploit Prediction Scoring System) enrichment is enabled, BootUI extracts canonical CVE IDs from advisories to estimate exploitation probability in the wild over the next 30 days.

Key behaviors and constraints:

• Prioritization Heuristic: For advisories containing multiple CVEs, BootUI selects the maximum AVAILABLE per-CVE probability. This is a prioritization heuristic and not a combined probability of exploitation for the entire advisory or application.
• Calculation Rules: Probabilities are never summed or combined via multiplication of complements.
• Data Integrity: A missing alias must not hide a valid result from another alias. A score of zero is treated as an available score, not an 'unknown'.
• Distinction: EPSS estimates exploitation probability, whereas CVSS describes severity.
• Limitations: The DTO does not expose the specific selected CVE, the score date, or the model version. Do not assume the scalar represents every alias or is date-pinned.

The Architecture panel uses ArchUnit to run a fixed, zero-config ruleset against your application's classes.

Core Mechanism

1. Base Package Discovery: The scanner identifies your application's base package(s).
   • Spring: Uses @SpringBootApplication configuration (AutoConfigurationPackages).
   • Quarkus: Uses a build-time BasePackageProvider seam to reduce the Jandex index to a package root antichain.
2. Class Import: It imports compiled .class files from those base packages using ArchUnit's ClassFileImporter. It only imports the application's own base packages, not the entire classpath.
3. Rule Evaluation: Every registered rule in the ArchitectureRuleRegistry is evaluated against the imported classes.

Framework Support & Availability

• Spring: ArchUnit is included transitively via bootui-spring-boot-starter. For the panel to work, ArchUnit must be on the classpath and a base package must be resolvable.
• Quarkus: The Quarkus adapter bundles ArchUnit itself.
• Dual-Framework Compatibility: Rules keyed on Spring-only annotations (e.g., @Autowired, @Component) act as no-ops on Quarkus/CDI applications (they match zero classes and pass) to avoid false positives. Rules using jakarta.* annotations (e.g., @Transactional, @PostConstruct) work on both.

GET <api>/architecture/rules/{id}/violations?scanId=...&offset=0&limit=100

The Overview panel serves as a guided dashboard for understanding your application's state. It is not a static summary but an on-demand findings and coverage dashboard.

Key behaviors:

• On-demand scanning: Nothing is scanned on load. The panel reads existing cached reports from previous scans (including those started by advisors or local agents) via GET requests. These requests do not trigger new scans or probes.
• Scoring Model: The Overall score is the rounded arithmetic mean of all eligible, available, and visible advisor scores, plus the GitHub security-alert score (when eligible).
• Score Bands: Results are categorized into three color-coded bands:
  • Good (80–100)
  • Needs attention (50–79)
  • At risk (0–49)
• No backend dashboard service: The dashboard is rendered entirely in the browser. The shell reads individual advisor reports and displays them independently.
• Integration with AI: After running scanners, the panel suggests enabling the MCP Server panel, which allows AI agents to read the results and automatically fix findings.