BootUI Demo Blog Service

Small Spring Boot demo application for demonstrating BootUI on a real MVC/JPA application.

The application imports users, posts, and comments from JSONPlaceholder into PostgreSQL and exposes several REST endpoints that can be inspected using BootUI.

Resources

• BootUI GitHub Repository
• BootUI Documentation
• BootUI Features
• BootUI Architecture Checks
• BootUI Sample Application

Stack

Run

Use the SDKs configured in .sdkmanrc:

sdk env install
sdk env

Start the application:

task run

Or directly with Maven:

mvn spring-boot:run -Dspring-boot.run.profiles=dev

The dev profile starts compose.yaml automatically using Spring Boot Docker Compose support.

URLs

• Application: http://localhost:7777
• BootUI: http://localhost:7777/bootui
• Health: http://localhost:7777/actuator/health

API

• POST /api/sync
• GET /api/users
• GET /api/users/{id}
• GET /api/users/{id}/posts
• GET /api/posts/{id}
• GET /api/posts/{id}/comments
• GET /api/statistics

GET /api/statistics intentionally performs multiple per-user repository calls and is useful for demonstrating SQL/runtime behavior in BootUI.

---

Demo 1 — Advisors And Overview

Goal: show how BootUI analyzes the application and turns findings into advisor scores.

Steps

1. Start the application:

task run

2. Open BootUI:

http://localhost:7777/bootui

3. Open Overview.

4. Run Re-run all scanners.

5. Review the overall score and individual advisor scores.

6. Open several advisors:

• Architecture
• REST API
• Spring
• Hibernate
• Memory
• Pentesting
• Vulnerabilities

7. Open one finding and explain:

• severity,
• what BootUI detected,
• why it matters,
• remediation.

The point of this demo is not to click every panel. It is to show that BootUI gives a developer-oriented overview of the running application and groups findings by area.

---

Demo 2 — Runtime Diagnostics And SQL

Goal: show what the application is doing while it is running.

Steps

1. Open Live Activity.

2. Trigger several application requests:

curl http://localhost:7777/api/users
curl http://localhost:7777/api/users/1/posts
curl http://localhost:7777/api/posts/1/comments
curl http://localhost:7777/api/statistics

3. Return to Live Activity.

4. Inspect generated HTTP activity.

5. Open the request details for:

GET /api/statistics

6. Inspect the SQL statements associated with the request.

7. Open SQL Trace and compare the executed queries.

The /api/statistics endpoint intentionally performs multiple per-user repository calls, making it useful for demonstrating repeated SQL queries and potential N+1-style behavior.

Useful additional panels:

• HTTP Exchanges
• Exceptions
• Metrics
• Threads
• Database Pool
• Scheduled Tasks
• Mappings
• Beans

---

Demo 3 — AI Agent With BootUI MCP

Goal: let Codex inspect BootUI advisor/runtime data through MCP, choose a finding, fix the code, restart the application, and verify the result with BootUI.

Step 1 — Start The Application First

Start the application before starting Codex:

task run

Verify that BootUI is available:

http://localhost:7777/bootui

Step 2 — Enable BootUI MCP

BootUI MCP is disabled by default.

Open:

BootUI → Configuration → MCP Server

Enable the MCP server using the runtime toggle.

The MCP endpoint is:

http://localhost:7777/bootui/api/mcp

If MCP is not enabled before Codex starts, Codex can fail during MCP handshake with:

MCP client for `bootui` failed to start:
BootUI MCP server is disabled.
Enable it from the MCP Server panel or set bootui.mcp.enabled=ON.

For the live demo, prefer enabling MCP from the UI to show that MCP access is opt-in.

Step 3 — Register BootUI In Codex

Run:

codex mcp add bootui --url http://localhost:7777/bootui/api/mcp

Verify:

codex mcp list

Important startup order:

Spring Boot application UP
        ↓
BootUI available
        ↓
BootUI MCP enabled
        ↓
Start / restart Codex
        ↓
MCP handshake succeeds

If MCP was enabled after Codex had already started, restart Codex.

Inside Codex, inspect MCP tools with:

/mcp

Typical BootUI MCP tools include:

architecture_scan
spring_scan
hibernate_scan
rest_api_scan
memory_scan
pentest_scan
graalvm_scan

get_overview
get_health
get_config
get_beans
get_mappings
get_live_activity
get_http_exchanges
get_sql_traces
get_traces
get_exceptions
get_exception_detail
get_log_tail
get_security_logs

Step 4 — Let Codex Triage The Application

Use this prompt:

Use the BootUI MCP server to inspect the currently running application.

Start with the BootUI overview and review all available advisor results.

Focus on HIGH severity findings first.

Choose one high-severity finding that:
1. belongs to this application,
2. can be safely demonstrated and fixed locally,
3. does not require external infrastructure changes.

Explain:
- which BootUI advisor reported it,
- the finding ID and severity,
- what BootUI detected,
- why it matters,
- which project files are involved,
- how you would fix it.

Do not modify any files yet.

This demonstrates that the agent is not only reading source code. It is using BootUI data from the currently running application.

Step 5 — Optional Pentesting Fallback

If Codex chooses a finding that is not convenient for a short live fix, use:

Use the BootUI MCP server to inspect the Pentesting advisor.

Review all HIGH severity findings and choose the one that can be safely fixed in this application with a small code or configuration change.

Explain:
- the finding ID,
- severity,
- what BootUI detected,
- which project files are involved,
- the proposed fix.

Do not modify any files.

Step 6 — Apply The Fix

After reviewing the finding, use:

Fix the selected BootUI finding.

Requirements:
- preserve the existing application behavior,
- keep the change focused on this finding,
- do not change unrelated BootUI findings,
- add or update relevant tests.

After the code changes:
1. run the relevant tests,
2. summarize what changed,
3. do not run BootUI scans yet.

Do not commit the demo change if you want to replay the same scenario later.

Step 7 — Restart The Application

BootUI is inspecting the running application, not the modified source tree.

After Codex changes the code, stop and restart the application:

task run

Wait until:

http://localhost:7777/bootui

is available again.

If the MCP runtime toggle is reset after restart, enable MCP again before continuing.

Step 8 — Verify The Fix Through MCP

Use:

Use the BootUI MCP server again.

Re-run the advisor that reported the previously selected finding.

Verify whether that finding is resolved.

Compare:
- the previous finding,
- the current finding,
- the advisor score before and after the change.

Do not modify any files.

Then refresh the BootUI Overview and show the before/after result.

The complete flow is:

BootUI Overview
      ↓
HIGH severity finding
      ↓
MCP
      ↓
Codex triage
      ↓
Source code fix
      ↓
Tests
      ↓
Application restart
      ↓
BootUI re-scan
      ↓
Before / after verification

Step 9 — Remove BootUI MCP From Codex

After the demo:

codex mcp remove bootui

Verify:

codex mcp list

BootUI MCP runs inside the Spring Boot application, so there is no separate BootUI MCP process to stop.

---

Tests And Coverage

Run:

mvn verify

The build uses JaCoCo and fails if line coverage for application logic drops below 90%.

Native Build

Build the GraalVM native executable:

task native-build

Or directly:

mvn clean -Pnative native:compile -Dspring.profiles.active=dev

Run it:

task native-run

The executable is created at:

target/bootui-demo

Configuration

Main settings:

server.port=7777
blog.api.base-url=https://jsonplaceholder.typicode.com
blog.sync.fixed-delay=PT10M

Useful files:

src/main/resources/application.yaml
src/main/resources/application-dev.yaml
src/test/resources/application-test.yaml
compose.yaml
Taskfile.yml