Try the sample app

The fastest way to see BootUI is to run a published sample-app image. No clone, no build, and no JDK are required — only a Docker-compatible engine such as Docker Desktop, Docker Engine, or Podman.

The published images follow the released line. To try the v2-only runtime journal, Runtime Insights, and Java-agent panels before 2.0 publication, build the v2 branch and use the sample's source launchers instead.

docker run --rm -p 8080:8080 -e BOOTUI_TRUST_CONTAINER_GATEWAY=AUTO jdubois/bootui-sample-app

Then open http://localhost:8080/bootui from a browser on the same machine.

BOOTUI_TRUST_CONTAINER_GATEWAY=AUTO lets the browser on your host reach BootUI through Docker's bridge gateway while the Host allow-list and cross-site-write defenses stay in force. See running inside a Docker container.

Available images

Each flavor listens on one fixed port, identical whether you run it from Docker or from source with Maven.

What the default profile gives you

Every image is Docker-free and runs on an in-memory H2 database, so no PostgreSQL, Redis, or Ollama is needed.

On the four Spring servlet images, the sample app's dev profile also uses an in-memory cache and excludes the Spring AI auto-configuration. Most panels work normally, including Configuration, Database, Spring Data, Flyway, and Liquibase. The sample's own Chat page reports that no model is reachable, and Dev Services lists no containers. The AI Framework panel itself stays available, because it is gated on Spring AI being on the classpath rather than on a configured model; it simply shows no captured conversations.

The Quarkus sample differs: it builds on LangChain4j rather than Spring AI, and the Spring-specific panels are marked not applicable there.

Database migrations are disabled for a faster boot. To populate the Flyway and Liquibase panels, turn them back on:

docker run --rm -p 8080:8080 \
  -e BOOTUI_TRUST_CONTAINER_GATEWAY=AUTO \
  -e SPRING_FLYWAY_ENABLED=true -e SPRING_LIQUIBASE_ENABLED=true \
  jdubois/bootui-sample-app

The WebFlux image takes the same two variables on port 8081, and the Quarkus image uses QUARKUS_FLYWAY_MIGRATE_AT_START=true and QUARKUS_LIQUIBASE_MIGRATE_AT_START=true on port 8082.

Three images cannot be changed this way:

• The AOT and native images run Spring AOT with the migrations disabled, which freezes that decision into the generated context. Setting the variables at runtime leaves the Flyway and Liquibase panels reporting No Flyway beans are available. Rebuild with the flags removed from the process-aot configuration instead.
• The CRaC image takes its checkpoint with migrations off, so the variables must be set on the run that creates the checkpoint. An existing checkpoint has to be regenerated.

JVM + AOT image

jdubois/bootui-sample-app-aot combines two Ahead-of-Time optimizations on the plain JVM image. It needs no GraalVM toolchain and no CRIU privileges:

• Spring AOT pre-generates the application context wiring at build time, replacing dynamic CGLIB proxies and reflection with static factory code.
• The JDK 25 AOT class loading cache (JEP 483) records class loading and linking during a training run in the Docker build and replays it on every start.

docker run --rm -p 8080:8080 -e BOOTUI_TRUST_CONTAINER_GATEWAY=AUTO jdubois/bootui-sample-app-aot

Historical sample measurements showed roughly 40–45 % off the Spring-reported startup time (about 9.7 s down to 5–6 s) for a 70–100 MB larger image. These have not been rerun for the current v2 code and are not startup guarantees.

-e SPRING_PROFILES_ACTIVE=... still changes which property files are loaded, but it cannot change which beans exist. Spring AOT evaluated the profile and property conditions when the image was built, so bean selection is fixed whatever you pass at runtime.

docker run --rm -p 127.0.0.1:8080:8080 \
  -e BOOTUI_TRUST_CONTAINER_GATEWAY=AUTO \
  -e 'JDK_JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching' \
  jdubois/bootui-sample-app-aot

GraalVM native image

jdubois/bootui-sample-app-native is a GraalVM native image. Historical sample measurements reported about 0.3 s of application startup; the current v2 code has not been remeasured:

docker run --rm -p 8080:8080 -e BOOTUI_TRUST_CONTAINER_GATEWAY=AUTO jdubois/bootui-sample-app-native

A native image freezes auto-configuration during AOT, so both the dev profile and the disabled migrations are baked in at build time. Rebuild the image to change them.

docker-compose-native.yml runs it against PostgreSQL. It also starts Redis and points the application at it, but the native image is built with the dev profile, which excludes the Redis auto-configuration, so those beans are not restored by runtime configuration alone.

CRaC image

jdubois/bootui-sample-app-crac uses CRaC to restore a pre-initialized application context. Historical sample measurements reported about 0.11 s of application restore; the current v2 code has not been remeasured. The checkpoint is taken at onRefresh, after non-lazy singleton initialization but before lifecycle start, so it is not a fully warmed-up application.

It runs on a Linux host only, needs elevated privileges for CRIU, and keeps its checkpoint in a volume so it survives container restarts:

docker run --rm -p 8080:8080 \
  --cap-add=CHECKPOINT_RESTORE --cap-add=SYS_PTRACE --cap-add=SYS_ADMIN --cap-add=NET_ADMIN \
  -e BOOTUI_TRUST_CONTAINER_GATEWAY=AUTO \
  -v bootui-sample-app-crac:/opt/crac/checkpoint \
  jdubois/bootui-sample-app-crac

The first start boots once to write the checkpoint; later starts restore it. Run docker volume rm bootui-sample-app-crac to force a fresh checkpoint. For details, see "Run it with CRaC" in the sample app README.

WebFlux image

jdubois/bootui-sample-app-webflux serves the same console at /bootui, backed by the reactive build of the BootUI engine on Netty:

docker run --rm -p 8081:8081 -e BOOTUI_TRUST_CONTAINER_GATEWAY=AUTO jdubois/bootui-sample-app-webflux

Then open http://localhost:8081/bootui.

The reactive adapter supports every panel except HTTP Sessions, including every advisor scan and every action. A few are reactive equivalents rather than the servlet behaviour: the Security advisor runs its WebFlux-native 26-rule catalogue, and the raw Spring Security panel shows the reactive SecurityWebFilterChain pipeline with explanations marked best effort. See Framework support.

What a panel shows still depends on the application's own dependencies, and this sample is a minimal one. It has no JPA and no Spring AI, so the Hibernate and AI panels report themselves unavailable here even though the adapter supports them.

There is one WebFlux flavor, with no AOT, native, or CRaC variant: the reactive sample exists to exercise the reactive adapter, not to demonstrate every JVM startup technique twice.

Quarkus image

jdubois/bootui-sample-app-quarkus serves the same console at /bootui, backed by the Quarkus build of the engine:

docker run --rm -p 8082:8082 -e BOOTUI_TRUST_CONTAINER_GATEWAY=AUTO jdubois/bootui-sample-app-quarkus

Then open http://localhost:8082/bootui.

BootUI activates only outside Quarkus' production launch mode, so the image starts the application in dev mode. That requires a full JDK base image, which makes it larger than the Spring images.

Most panels are live. A handful target Spring-specific concepts and are marked not applicable — see what is not on Quarkus. There is no AOT, native, or CRaC variant: Quarkus builds native images itself, and BootUI's GraalVM and CRaC advisors are Spring-oriented.

Want the full experience?

To exercise every panel with PostgreSQL, Redis, and Ollama, run the sample app with the docker profile from a checkout of the repository. See the sample app README.