Spring Boot Admin

Prerequisites

Before you deploy, make sure you have an active Azure subscription, an SSH key pair, and a VNet and subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a sensible starting point and is what the image is tuned for. Size up to monitor more applications.

In the network security group, allow inbound 22/tcp from your management network and 80/tcp for the console. Spring Boot Admin serves plain HTTP on port 80, so terminate TLS in front of it with your own domain. The application listens on 127.0.0.1:8080 only, so the app port and its actuator endpoints are never exposed to the network.

Step 1 - Deploy the image

Option A: Azure portal

• In the Azure portal, open Create a resource and search for Spring Boot Admin on Ubuntu 24.04 LTS by SecureAnyCloud.
• Select the plan and choose Create.
• On the Basics tab, choose your subscription, resource group and region. Name the VM and select Standard_B2s.
• Set Authentication type to SSH public key, enter azureuser as the username, and provide your public key.
• On the Networking tab, allow inbound 22/tcp (from your IP) and 80/tcp.
• Choose Review + create. When deployment completes, note the VM's public IP address.

Option B: Azure CLI

az vm image terms accept --urn sac1647283583153:spring-boot-admin-ubuntu-24-04:default:latest
az vm create \
  --resource-group my-spring-boot-admin-rg \
  --name spring-boot-admin \
  --image sac1647283583153:spring-boot-admin-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard
az vm open-port --resource-group my-spring-boot-admin-rg --name spring-boot-admin --port 80 --priority 900

Step 2 - Confirm the services are running

SSH in as azureuser and confirm that the two systemd units are active. spring-boot-admin.service is the console application. nginx.service is the reverse proxy on port 80.

systemctl is-active spring-boot-admin nginx

Expect output like this:

active active

The application exposes a health endpoint on the loopback interface. Use it for liveness checks:

curl -s http://127.0.0.1:8080/actuator/health

{"status":"UP","components":{"diskSpace":{...},"livenessState":{...},"ping":{...},"readinessState":{...},"ssl":{...}}}

The application and its actuator endpoints bind to the loopback interface. nginx on port 80 is the sole external surface. Confirm the listening sockets:

ss -tln | grep -E ':80 |:8080 '

Step 3 - Retrieve the per-VM administrator password

Spring Boot Admin ships with Spring Security form login switched on. There is no default or shared password. On the first boot of every VM, a one-shot service generates a random administrator password for that instance and writes it to a root-only file. Read it with sudo:

sudo cat /root/spring-boot-admin-credentials.txt

The file records the console URL, the administrator username admin and the generated password:

# Spring Boot Admin - Per-VM Credentials SBA_UI_URL=http://YOUR_VM_IP/ SBA_ADMIN_USER=admin SBA_ADMIN_PASSWORD=<set-at-first-boot>

The file is 0600 root:root. The same password is placed in /etc/spring-boot-admin/sba.env, also 0600 root:root, which systemd reads to start the application. The service account never reads either file. Keep this password safe. It is the single administrator credential for the console.

Step 4 - Sign in to the console

Open http://YOUR_VM_IP/ in your browser. Spring Boot Admin redirects to its login page because Spring Security is enabled. Enter the username admin and the password from /root/spring-boot-admin-credentials.txt, then choose Login. Any attempt to reach the console or its API without signing in is refused, so the console is never served anonymously.

Step 5 - View the applications dashboard

After you sign in, you land on the Applications view. The server is registered against itself, so one application, Spring Boot Admin (self), is already present and reporting UP. The summary shows that all applications and instances are up.

This is the same view you use to watch every application you connect. Each application groups its instances, and the color and status show at a glance whether they are healthy.

Step 6 - Inspect an application's health and metrics

Select an application to open its instance detail. The Details view brings together the instance's health, its info and registration metadata, and live process metrics. Each health indicator (liveness, readiness, disk space, ssl and more) is shown individually.

Use the Insights menu on the left to drill into Metrics, Environment, Beans, Configuration Properties, Conditions and Scheduled Tasks. All of these are pulled live from the application's actuator endpoints.

Step 7 - Manage log levels at runtime

Open Loggers from the instance menu to see every logger in the application and its current level. Raise or lower a logger's level to OFF, ERROR, WARN, INFO, DEBUG or TRACE. The change is applied to the running application immediately through its actuator endpoint, with no restart.

This is one of the most useful day-to-day features of Spring Boot Admin. Turn on DEBUG for a single package while you reproduce an issue, then set it back, all from the browser.

Step 8 - Register your own Spring Boot applications

The dashboard already monitors the bundled server. To watch your own services, add the Spring Boot Admin client to each application and point it at this server. In your application's pom.xml, add the dependency:

<dependency> <groupId>de.codecentric</groupId> <artifactId>spring-boot-admin-starter-client</artifactId> <version>4.1.2</version> </dependency>

Then, in your application's configuration, point the client at this server and expose the actuator endpoints that Spring Boot Admin reads. The console is secured, so supply the administrator credentials so that the client can register:

spring: boot: admin: client: url: http://YOUR_VM_IP username: admin password: the-generated-per-vm-password management: endpoints: web: exposure: include: "*"

When your application starts, it registers with the server and appears on the Applications dashboard within a few seconds. You can inspect it exactly like the bundled instance. Front the server with TLS, and consider a dedicated monitoring account rather than the administrator credential.

Step 9 - Security model

The image is secure by default. Spring Security form login is enabled. The administrator password is generated per VM and stored in a root-only file. The self-registration authenticates to the secured server with that same per-VM credential, so nothing usable is baked into the image.

Prove the login wall from the VM. An unauthenticated API request is refused, while the per-VM administrator is served:

PASS=$(sudo grep '^SBA_ADMIN_PASSWORD=' /root/spring-boot-admin-credentials.txt | cut -d= -f2-)
curl -s -o /dev/null -w 'unauthenticated: %{http_code}\n' -H 'Accept: application/json' http://127.0.0.1/instances
curl -s -o /dev/null -w 'admin: %{http_code}\n' -H 'Accept: application/json' -u "admin:$PASS" http://127.0.0.1/instances

An unauthenticated request is refused with 401 and the per-VM administrator is served with 200:

unauthenticated: 401 admin: 200

A bundled round-trip script proves the same end to end. It shows that the per-VM administrator authenticates and that a wrong password is rejected:

bash /usr/local/sbin/sba-cred-roundtrip.sh

The security model has these key points:

• Spring Security form login is enabled. The console and its API are never served anonymously.
• The administrator password is generated per VM on first boot. No known or blank credential ships in the image.
• The self-registration client authenticates to the secured server with the per-VM credential, read from the systemd environment at runtime and never baked into the archive.
• The application and every actuator endpoint bind to 127.0.0.1. nginx on port 80 is the only external surface.

Step 10 - Base image and versions

The image runs Spring Boot Admin 4.1.2 (aligned to Spring Boot 4.1) on OpenJDK 21, on an Ubuntu 24.04 LTS base, patched at build time. Confirm the runtime versions:

java -version

The console is a single self-contained Java archive under /opt/spring-boot-admin. The OS was patched at build time with no held packages.

Managing the services

The console and the reverse proxy run as standard systemd units:

sudo systemctl status spring-boot-admin
sudo systemctl restart spring-boot-admin
sudo systemctl restart nginx

Application logs go to the journal (use -f to follow live):

sudo journalctl -u spring-boot-admin -n 30 --no-pager

Support

This image is maintained by SecureAnyCloud with 24/7 support. For help deploying or operating Spring Boot Admin on Azure, contact the SecureAnyCloud support team through your Azure Marketplace subscription.

Deploy on Azure

Launch Spring Boot Admin on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com