If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/codecentric/spring-boot-admin shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• Last commit today
• 7 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Single-maintainer risk — top contributor 83% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live codecentric/spring-boot-admin repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/codecentric/spring-boot-admin.

What it runs against: a local clone of codecentric/spring-boot-admin — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in codecentric/spring-boot-admin | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of codecentric/spring-boot-admin. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/codecentric/spring-boot-admin.git
#   cd spring-boot-admin
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of codecentric/spring-boot-admin and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "codecentric/spring-boot-admin(\\.git)?\\b" \\
  && ok "origin remote is codecentric/spring-boot-admin" \\
  || miss "origin remote is not codecentric/spring-boot-admin (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/config/SpringBootAdminClientAutoConfiguration.java" \\
  && ok "spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/config/SpringBootAdminClientAutoConfiguration.java" \\
  || miss "missing critical file: spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/config/SpringBootAdminClientAutoConfiguration.java"
test -f "spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/registration/ApplicationRegistrator.java" \\
  && ok "spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/registration/ApplicationRegistrator.java" \\
  || miss "missing critical file: spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/registration/ApplicationRegistrator.java"
test -f "spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/registration/DefaultApplicationRegistrator.java" \\
  && ok "spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/registration/DefaultApplicationRegistrator.java" \\
  || miss "missing critical file: spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/registration/DefaultApplicationRegistrator.java"
test -f "spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/registration/ApplicationFactory.java" \\
  && ok "spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/registration/ApplicationFactory.java" \\
  || miss "missing critical file: spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/registration/ApplicationFactory.java"
test -f "spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/config/ClientProperties.java" \\
  && ok "spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/config/ClientProperties.java" \\
  || miss "missing critical file: spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/config/ClientProperties.java"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/codecentric/spring-boot-admin"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Spring Boot Admin provides a web-based dashboard and REST API for monitoring and managing Spring Boot applications via their actuator endpoints. It solves the problem of centralized visibility into dozens of microservices by aggregating health, metrics, logs, JMX operations, and environment information from heterogeneous Spring Boot clients—whether they're on-premise, in Kubernetes, or on Cloud Foundry—into a single polished Vue.js UI. Multi-module Maven monorepo: spring-boot-admin-client/ contains the lightweight registration/heartbeat library clients embed; spring-boot-admin-server/ (not fully visible but implied) runs the dashboard backend; UI is decoupled in separate modules using Vue.js + TypeScript (935K TypeScript, 600K Vue, 12.8K CSS). GitHub Actions workflows in .github/workflows/ orchestrate Maven builds, Docker image publication, and documentation deployment via Docusaurus (mdx files for docs).

DevOps engineers, SREs, and platform teams managing multiple Spring Boot microservices who need production visibility without building custom monitoring dashboards; also Spring Boot framework contributors and maintainers who want to verify actuator endpoint behavior across Spring Boot versions 2.7, 3.0, and 4.0.

Highly mature and production-ready: versioning strictly follows Spring Boot major.minor versions (currently 4.1.0-SNAPSHOT for Spring Boot 4.x), active CI/CD with GitHub Actions (build-main.yml, release-to-maven-central.yml), codecov coverage tracking, and maintained by the codecentric organization. Regular releases to Maven Central indicate stable, battle-tested code.

Standard open source risks apply.

Active 4.1.0-SNAPSHOT development targeting Spring Boot 4.x compatibility; renovation bot managing npm/Maven dependency upgrades (renovate.json); documentation being maintained (deploy-documentation.yml workflow); vulnerability scanning enabled (vulnerability-scan.yml); issue metrics tracked (issue-metrics.yml). Release workflow (release-to-maven-central.yml) is ready for tag-based Maven Central publication.

git clone https://github.com/codecentric/spring-boot-admin.git && cd spring-boot-admin && ./mvnw clean install -DskipTests && npm --version && node --version (verify node v24.15.0+ and npm 11.12.1+ installed). Then run individual modules or the test suite via ./mvnw test.

Daily commands: Backend: ./mvnw spring-boot:run in spring-boot-admin-server/ module. Frontend (if separate): cd spring-boot-admin-ui && npm install && npm run dev. Full build: ./mvnw clean package builds all modules including UI and packages as JAR with embedded Vue app.

• spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/config/SpringBootAdminClientAutoConfiguration.java — Core auto-configuration class that bootstraps the client library and wires all registration and metadata components together.
• spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/registration/ApplicationRegistrator.java — Interface defining the primary contract for registering applications with the admin server; all registration implementations must follow this pattern.
• spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/registration/DefaultApplicationRegistrator.java — Default implementation handling the core registration lifecycle and retry logic; most deployments rely on this class.
• spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/registration/ApplicationFactory.java — Abstraction for creating Application objects from different deployment contexts (servlet, reactive, Cloud Foundry); essential for multi-platform support.
• spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/config/ClientProperties.java — Configuration properties POJO defining all client-side settings; any feature requiring configuration must add properties here first.
• pom.xml — Parent POM with dependency and version management for all modules; changes here affect the entire build pipeline.
• .github/workflows/release-to-maven-central.yml — Release automation pipeline; critical for understanding versioning and deployment practices.

Add a custom metadata contributor

1. Create a new class implementing MetadataContributor interface (spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/registration/metadata/MetadataContributor.java)
2. Implement the contributeMetadata() method to return your custom metadata as a Map (spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/registration/metadata/StartupDateMetadataContributor.java)
3. Register your contributor as a Spring bean in your application configuration (spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/config/SpringBootAdminClientAutoConfiguration.java)
4. Wire it into CompositeMetadataContributor via auto-configuration (spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/registration/metadata/CompositeMetadataContributor.java)

Add support for a new deployment platform

1. Create a new ApplicationFactory implementation for your platform (spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/registration/ApplicationFactory.java)
2. Implement createApplication() to extract environment metadata and build an Application object (spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/registration/CloudFoundryApplicationFactory.java)
3. Create a conditional auto-configuration class that registers your factory when appropriate (spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/config/SpringBootAdminClientCloudFoundryAutoConfiguration.java)
4. Add configuration properties to ClientProperties or create a platform-specific properties class (spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/config/ClientProperties.java)

Customize registration behavior and retry logic

1. Review the DefaultApplicationRegistrator to understand the registration lifecycle (spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/registration/DefaultApplicationRegistrator.java)
2. Add retry/backoff configuration properties to ClientProperties (spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/config/ClientProperties.java)
3. Override or extend DefaultApplicationRegistrator and register as a bean in auto-configuration (spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/config/SpringBootAdminClientAutoConfiguration.java)
4. Wire your custom registrator into RegistrationApplicationListener (spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/registration/RegistrationApplicationListener.java)

• Spring Boot AutoConfiguration — Enables zero-configuration integration; clients automatically register simply by including the starter dependency.
• ApplicationEvent / Listener pattern — Allows registration to hook into the application startup lifecycle without invasive changes; deregistration handled on shutdown.
• Factory pattern (ApplicationFactory) — Abstracts platform differences (servlet, reactive, Cloud Foundry); each platform can supply correct endpoint metadata without core changes.
• Metadata Contributor pattern — Enables extensibility; custom metadata can be added by implementing a simple interface without modifying core registration logic.
• REST HTTP client (RestClientRegistrationClient) — Simple synchronous protocol for server communication; admin server expects REST endpoint calls for registration/deregistration.

• Synchronous registration on application startup

  • Why: Ensures the admin server has the application registered before it starts accepting traffic; prevents race conditions.
  • Consequence: Slow/unreachable servers can delay application startup; mitigated with timeout and async retry logic.

• Spring-boot version matching in admin server and client

  • Why: Simplifies dependency management and ensures API compatibility between server and client.
  • Consequence: Clients using

Java 17+ is a hard requirement (set in pom.xml maven.compiler.source/target); older JDKs will fail compilation. Maven 3.9 or later required (require.maven.version property). Node.js and npm versions are pinned exactly (v24.15.0 and 11.12.1) in pom.xml npm/node-maven-plugin configuration—using different versions may cause build cache misses or lockfile conflicts. Client library (spring-boot-admin-client) is decoupled from server version—you must coordinate versions carefully when mixing Spring Boot 2.7 server with 3.0 clients (see Compatibility Matrix in README). No .env.local or local config patterns are documented in the file list; configuration appears to be entirely Spring Boot properties-based. The UI build likely runs during Maven package phase via maven-frontend-plugin or similar (not visible in file list); Node modules may need cleaning separately if changes are made.

• Spring Boot Actuator Endpoints — Spring Boot Admin entirely depends on actuator (health, metrics, env, loggers, threaddump, etc.); understanding what each endpoint returns and how to customize them is foundational.
• Service Discovery & Registration — Clients auto-register with the admin server via REST or via discovery services (Eureka, Consul); the registration protocol and heartbeat mechanism are core to how Admin tracks instances.
• Server-Sent Events (SSE) — Admin dashboard uses SSE for real-time health status updates and live log streaming without WebSocket overhead; critical for responsive UI without polling.
• Cloud Foundry Cloud Controller API — CloudFoundryApplicationProperties.java shows Admin integrates with CF metadata; required for deployments on Cloud Foundry to auto-detect app names and routes.
• Maven Multi-Module Projects — Spring Boot Admin is structured as a Maven monorepo with client and server modules; understanding module interdependencies and property inheritance is essential for building and modifying.
• TypeScript with Vue.js Composition API — The UI (600K Vue, 935K TypeScript) uses Vue 3 and likely Composition API for reactive state management; unfamiliar with Vue? This is your learning curve.
• JMX Operations (Java Management Extensions) — Admin can invoke JMX operations remotely via the dashboard (screenshot-jmx.png); requires understanding MBean naming conventions and method invocation security.

• spring-projects/spring-boot — The upstream project that defines actuator endpoints; understanding Spring Boot internals is essential for extending Admin's monitoring capabilities.
• spring-cloud/spring-cloud-netflix — Provides service discovery (Eureka) integration that Spring Boot Admin uses for client auto-registration in cloud deployments.
• prometheus/prometheus — Common metrics sink; Spring Boot Admin can export metrics to Prometheus, making this the de facto monitoring pipeline for production deployments.
• elastic/kibana — Alternative log aggregation UI; Spring Boot Admin complements Kibana by providing real-time JMX and application-level operations Kibana cannot.
• SolarEdgeTech/pyctuator — Mentioned in README as the Python equivalent; shows how the admin pattern extends beyond Java into polyglot environments.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for CloudFoundry application registration and metadata contribution

The codebase has CloudFoundry-specific implementations (CloudFoundryApplicationFactory, CloudFoundryApplicationProperties, CloudFoundryMetadataContributor) but there's no evidence of dedicated integration tests validating the CloudFoundry registration flow end-to-end. This is critical since CloudFoundry is a major deployment platform and misconfigurations could silently fail in production.

• [ ] Create spring-boot-admin-client/src/test/java/de/codecentric/boot/admin/client/registration/CloudFoundryRegistrationIntegrationTest.java
• [ ] Test CloudFoundryApplicationFactory creates correct Application objects with CloudFoundry environment variables
• [ ] Test CloudFoundryMetadataContributor properly extracts and contributes CloudFoundry-specific metadata
• [ ] Test DefaultApplicationRegistrator successfully registers CloudFoundry applications with the admin server
• [ ] Verify metadata includes organization, space, and instance index from CloudFoundry environment

Add GitHub Actions workflow for dependency vulnerability scanning in client module

While there's a vulnerability-scan.yml workflow in place, it appears to be a general workflow. The spring-boot-admin-client module is a library that users depend on directly, making security critical. A dedicated workflow should verify no vulnerable transitive dependencies are introduced, with specific focus on registration and HTTP client dependencies.

• [ ] Review existing .github/workflows/vulnerability-scan.yml to understand current scope
• [ ] Create or enhance workflow to run 'mvn dependency-check:check' on spring-boot-admin-client module specifically
• [ ] Configure fail conditions for CVSS score thresholds relevant to client libraries (typically >= 7.0)
• [ ] Add step to validate transitive dependencies of RestClientRegistrationClient and related HTTP clients
• [ ] Document findings in CONTRIBUTING.md for contributors to understand vulnerability expectations

Add unit tests for RegistrationClient implementations with various authentication schemes

RestClientRegistrationClient and related registration clients are core to the entire registration flow, but specific test coverage for authentication scenarios (Basic Auth, Mutual TLS, custom headers) is not evident in the file structure. These tests should validate behavior with real-world Spring Security configurations.

• [ ] Create spring-boot-admin-client/src/test/java/de/codecentric/boot/admin/client/registration/RestClientRegistrationClientTest.java with parameterized tests
• [ ] Test successful registration with BasicAuthenticationInterceptor configured
• [ ] Test registration request includes all required headers from ClientProperties
• [ ] Test error handling and retry logic for 4xx/5xx responses
• [ ] Test that InstanceProperties metadata is correctly serialized in registration payload
• [ ] Test TLS/mTLS configuration scenarios if ClientProperties supports custom WebClient configuration

• Add integration tests for spring-boot-admin-client/src/main/java/de/codecentric/boot/admin/client/config/CloudFoundryApplicationProperties.java—currently visible but test coverage likely sparse for Cloud Foundry auto-detection logic; implement tests for environment variable parsing and service binding.
• Enhance documentation for InstanceProperties.java metadata fields—the config class is complex but no JavaDoc or example YAML snippets exist in the file list; add a dedicated docs page with common use-cases (custom tags, instance naming strategies, health endpoint customization).
• Implement GitHub Actions workflow to automatically validate pom.xml version consistency across modules—currently revision is defined once but could drift; add a lint step to build-feature.yml to catch version mismatches before merge.

Failed to generate security analysis.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.