BootUI
A local-only developer console for Spring Boot 4 and Quarkus applications.
See BootUI in four minutes
The Spring Boot sample app from start-up to fix: advisors, Live Activity, runtime panels, and an AI agent verifying its change over MCP.
Runtime observability
Inspect health, metrics, memory, threads, heap dumps, startup timing, and JVM sizing from the running Spring Boot or Quarkus app.
Advisors dashboard
Analyze and score your application with advanced advisors for architecture, REST API, Spring, Hibernate, JVM memory, Spring Security, pentesting, and vulnerabilities.
Diagnostics toolbox
Review traces, log tail, 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 repositories, Flyway, and Liquibase.
Services and integrations
Follow scheduled tasks, REST clients, fault tolerance, WebSockets, caches, email, Kafka, RabbitMQ, and JMS.
Local safety model
Stay loopback-only by default with secret masking, fail-closed activation, read-only controls, and explicit confirmation for mutating actions.
Start here
| Goal | Documentation |
|---|---|
| Run the full demo locally | Try the sample app |
| Add BootUI to a Spring Boot 4 or Quarkus app | Setup |
| Explore every panel | Features |
| Configure activation, safety, panels, and actions | Properties |
| Drive BootUI from an AI coding agent | AI agents |
| Ask a running application from a terminal or CI | Command line |
How BootUI works
Your application serves the console at /bootui/ and its JSON API at /bootui/api/**. The Vue UI is packaged inside the jar, so your build needs no Node.js and no npm.
The same console runs on Spring Boot 4 (servlet or WebFlux) and on Quarkus. A shared, framework-neutral engine serves an identical REST contract on all three.
BootUI is a development tool and stays one by default. It activates only in development, rejects non-loopback callers, masks secret-like values, and disables itself in production profiles. Every state-changing action is user-triggered, and the destructive ones ask for confirmation first.
Panels that depend on optional Spring, Actuator, or development infrastructure stay visible when that infrastructure is missing. They explain what is unavailable instead of disappearing.