Spring Boot Admin on Ubuntu 24.04 on Azure User Guide

Overview

Spring Boot Admin is an open source administration console for Spring Boot applications. It registers your running applications and surfaces their Spring Boot Actuator data, health, metrics, environment, JVM threads, loggers, HTTP mappings and more, in one web dashboard, so operators can watch and manage a fleet of services from a single place. It is built and maintained by codecentric and licensed under Apache 2.0.

Spring Boot Admin is distributed as a set of Maven libraries rather than a ready to run server, so this cloudimg image does the assembly for you: it builds a minimal Spring Boot Admin server application at image build time into a single self contained Java archive, runs it under systemd behind an nginx reverse proxy on port 80, and registers the server against itself. That means the applications dashboard already shows one live, monitored application the moment the VM boots, so the console is useful straight away and you can see exactly what a monitored instance looks like before you connect your own.

The image ships Spring Boot Admin 4.1.2 on a bundled OpenJDK 21 runtime, on a hardened, fully patched Ubuntu 24.04 LTS base. The console is secured with Spring Security form login enabled, and a unique administrator password is generated on the first boot of every VM. The server binds to the loopback interface only; nginx on port 80 is the sole external surface, and every actuator endpoint stays on loopback. Backed by 24/7 cloudimg support.

What is included:

• Spring Boot Admin 4.1.2 served by nginx on port 80, running as a Spring Boot service on a bundled OpenJDK 21 runtime
• A minimal Spring Boot Admin server application built from source at image build time into a single Java archive (Maven and its cache are removed afterwards)
• The server registered against itself, so the dashboard shows one live monitored application, UP, on first boot
• Spring Security form login enabled by default, with a per VM administrator password generated on first boot and recorded in a root only file
• No shipped default login: no known or blank credential authenticates, and the console is never served anonymously
• The application and all actuator endpoints bound to 127.0.0.1 only; nginx on port 80 is the sole external surface
• spring-boot-admin.service and nginx.service as enabled systemd units
• An unauthenticated /actuator/health liveness endpoint on the loopback interface
• 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet plus 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. NSG inbound: allow 22/tcp from your management network and 80/tcp for the console. Spring Boot Admin serves plain HTTP on port 80; for production, 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

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

Option B: Azure CLI

az vm create \
  --resource-group my-spring-boot-admin-rg \
  --name spring-boot-admin \
  --image cloudimg: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 the two systemd units are active. spring-boot-admin.service is the console application and nginx.service is the reverse proxy on port 80.

systemctl is-active spring-boot-admin nginx

Expected output:

active
active

The application exposes a health endpoint on the loopback interface that you can use 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. You can 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=the-generated-per-vm-password

The file is 0600 root:root, and 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 click 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 signing in you land on the Applications view. Because the server is registered against itself, one application, Spring Boot Admin (self), is already present and reporting UP, and the summary shows all applications and instances are up. This is the same view you will use to watch every application you connect: each application groups its instances, and the colour and status tell you at a glance whether they are healthy.

Step 6 - Inspect an application's health and metrics

Click an application to open its instance detail. The Details view brings together the instance's health, with each health indicator (liveness, readiness, disk space, ssl and more) shown individually, alongside its info and registration metadata and live process metrics. The Insights menu on the left drills into Metrics, Environment, Beans, Configuration Properties, Conditions and Scheduled Tasks, all 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. You can raise or lower a logger's level, OFF, ERROR, WARN, INFO, DEBUG or TRACE, and 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:

<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 Spring Boot Admin reads. Because the console is secured, supply the administrator credentials so 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, ready to inspect exactly like the bundled instance. For production, 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, and the self registration authenticates to the secured server with that same per VM credential, so nothing usable is baked into the image. You can 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

Expected output, 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, that the per VM administrator authenticates and a wrong password is rejected:

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

Key points of the security model:

• 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, 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 a fully patched Ubuntu 24.04 LTS base. Confirm the runtime:

java -version

The console is a single self contained Java archive under /opt/spring-boot-admin, and the OS ships fully patched with no held packages and no pending security updates.

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 cloudimg with 24/7 support. If you need help deploying or operating Spring Boot Admin on Azure, contact the cloudimg support team through your Azure Marketplace subscription.