Properties
The Properties page shows where every property of a Spring Boot instance comes from, which value the application actually uses, which properties are deprecated, and which beans read them.
Properties as presented in Axelix UI
The same property can come from many places: application.yaml, profile-specific files, environment variables, system
properties, command-line arguments.
What the page shows
The page lists all properties grouped by property source. The sources go from the highest precedence to the lowest, in the order Spring Boot consults them (see Externalized Configuration). When several sources define the same property, the application uses the value from the source higher in the list.
For each property, you can see:
- Whether its value takes effect:
- Active when the application uses this value.
- Suppressed when a source with a higher precedence defines it too, so this value never reaches the application.
- All the sources that define it, from the highest precedence to the lowest, with the winning value marked.
- The
@ConfigurationPropertiesbean that binds it and the beans that inject it through@Value, with links to the Configuration Properties and Beans pages. - Its description from
spring-configuration-metadata.json, when available.
Properties dropdown as presented in Axelix UI
Deprecated properties are highlighted and show the deprecation message, so you can find settings to migrate before upgrading.
Deprecated property as presented in Axelix UI
The page also shows the active and default profiles of the instance (spring.profiles.active and
spring.profiles.default).
Dangerous property values
Some property values are fine on a developer's machine but often cause trouble in production: lost data, leaked
internals, or slow queries. Axelix marks properties set to such values. For each of them, it shows why the value is
risky and which value to use instead. For example, spring.jpa.hibernate.ddl-auto=update lets Hibernate change the
database schema on its own.
Axelix checks only the value the application uses, so a dangerous value in a suppressed property source is not marked.
The value must match as a whole, in any letter case: management.endpoints.web.exposure.include=* is marked,
but health,* is not. Masked values are not checked either, so
without the ENV_VALUES_READ authority you don't see the mark for keys that are masked (see Value
sanitization).
By default, every value is masked as ****** for callers that do not carry the ENV_VALUES_READ authority. See Value
sanitization below for how to choose which keys are masked and who sees the originals.
Value sanitization
Axelix never relies on the Spring Boot management.endpoint.env.show-values switch. It always asks Spring Boot to
return raw values (Show.ALWAYS) and applies its own masking on top, driven by an authority check.
Who sees raw values. Callers carrying the ENV_VALUES_READ authority (granted by the built-in ADMIN and
SUPER_ADMIN roles) receive the originals. Everyone else gets values replaced with ******. See Roles and
authorities for the full
role/authority matrix.
Which keys are masked. A single starter property, axelix.sbs.endpoints.config.sanitized-properties, controls the
set, and it applies to both axelix-env (this page) and axelix-configprops (the Configuration
Properties page):
- Empty list (default): every value is masked for callers without the authority.
- Non-empty list: only the listed keys are masked, the rest are returned as-is.
axelix.sbs.endpoints.config.sanitized-properties[0]=database.password
axelix.sbs.endpoints.config.sanitized-properties[1]=spring.datasource.password
axelix.sbs.endpoints.config.sanitized-properties[2]=jwt.signing-keySee Sanitize sensitive property values in the Spring Boot Starter configuration guide for the same property described alongside the rest of the starter setup.
The standard Spring Boot Actuator properties for masking (management.endpoint.env.show-values,
management.endpoint.env.keys-to-sanitize, and their configprops equivalents) are not consulted. Use
axelix.sbs.endpoints.config.sanitized-properties instead.
MCP Tools
The full environment of a managed instance (application properties, system properties, and OS environment variables) is also exposed to AI agents through MCP. See the MCP Tools catalog.
Enable Dedicated Actuator Endpoint
If you are on Axelix 1.2.0 or later, none of this is required: the starter registers its custom actuator endpoints by itself, and Axelix no longer requires the health/info endpoints to be enabled — it works perfectly well without them. No configuration is needed here.
The page is backed by the axelix-env actuator endpoint contributed by the Axelix Spring Boot Starter. Expose it
through the standard Spring Boot Actuator properties — see Configuring Spring Boot
Starter for the full list
of Axelix endpoints and surrounding setup:
management.endpoints.web.exposure.include=axelix-env