VMware ESXi and vSphere Cluster Management

Spring Boot Actuator Env Endpoint

Learn how Spring Boot Actuator's env endpoint reports resolved configuration, property sources, profiles, exposure settings, sanitization, and safe production access.

Spring Boot Actuator provides production-ready monitoring and management endpoints. The env endpoint is an operational endpoint for inspecting the application's Spring environment and configuration property sources.

This lesson assumes familiarity with Spring Boot configuration, HTTP status codes, environment variables, JVM system properties, and basic authentication and authorization. The endpoint is commonly available at /actuator/env, although the management port and base path can change that URL.

What the env endpoint does

The env endpoint provides diagnostic visibility into the application's resolved environment: the profiles currently active and the ordered sources from which configuration can be obtained. It helps operators investigate questions such as:

Why is the application listening on an unexpected port?
Which profile is active in a staging deployment?
Which configuration source supplied a non-sensitive setting?
Why does a deployment behave differently from a local run?

The endpoint is for inspection, not modification. Reading a property through the endpoint does not change the application's configuration. Configuration changes must be made through the appropriate file, deployment variable, command-line option, configuration service, or secret-management system, followed by whatever restart or refresh process the application requires.

The Spring Environment and property resolution

The Spring Environment is Spring's abstraction for two related concerns: active profiles and ordered property sources. A property source is a named collection of configuration values, such as an application file, operating-system environment variables, JVM system properties, or command-line arguments.

When several sources define the same property, Spring applies property precedence. The higher-precedence source wins, producing the resolved property that the application uses. The exact ordering can vary by Spring Boot version and configuration mechanism, so use the application's documented version-specific ordering when resolving a dispute.

Property source	Typical deployment use	Can override lower sources	Operational considerations
Command-line arguments	One-off startup overrides and launch configuration	Usually yes	Inspect process definitions and launch scripts; command lines may be visible to operators.
JVM system properties	Values passed with `-Dname=value`	Often yes	Check the Java launch configuration and container entrypoint.
Operating-system environment variables	Container, cloud, CI/CD, and host-level deployment settings	Often yes	Keep secret values in a secret manager or protected runtime injection mechanism.
External configuration files	Mounted files, deployment directories, or configuration services	Depends on location and loading rules	Verify the file actually mounted in the running instance.
Profile-specific application files	Settings such as `application-staging.yml`	Can override the default file	They apply only when the corresponding profile is active.
Default application configuration files	Baseline application settings	Normally lower than deployment overrides	Do not assume a value here is the effective value.

For example, an application file might contain server.port=8080, while the deployment exports SERVER_PORT=9090. If the environment variable has higher precedence in the running setup, the effective server port is 9090. The env endpoint can help show both the source containing a value and the resulting effective value.

Environment-variable naming

Spring Boot commonly maps dotted property names to uppercase environment-variable names with underscores. For example:

export SERVER_PORT=9090

This commonly represents server.port=9090. Names containing hyphens, indexed collection elements, or relaxed-binding variations deserve extra care. Compare the actual property name shown by the application with the deployment variable rather than relying only on a visual guess.

Understanding the endpoint response

The response is organized around property sources rather than being only a flat list of final values. A typical response identifies sources and presents property names and values associated with those sources. It may also provide a property-specific lookup that shows the value, origin, and related source information.

All property sources: use the base env endpoint to inspect the available sources and their properties, subject to sanitization and endpoint-version behavior.
Targeted lookup: some Spring Boot versions support a property path such as /actuator/env/server.port. Verify this behavior for the application's version before depending on it.
Source contents: these are values supplied by individual sources. They are not automatically the final values used after every precedence rule is applied.
Resolved property: this is the effective value selected after competing sources and profile rules are considered.

For an authorized request to an intentionally exposed endpoint, examples include:

curl --user "$ACTUATOR_USER:$ACTUATOR_PASSWORD" https://example.internal/actuator/env
curl --user "$ACTUATOR_USER:$ACTUATOR_PASSWORD" https://example.internal/actuator/env/server.port

The second form is version-dependent and should be used only for non-sensitive properties. Never place real credentials directly into shell history, tickets, screenshots, or copied command examples.

Profiles and deployment configuration

An active profile selects profile-specific beans and configuration. A staging process might activate a staging profile, causing application-staging.yml to contribute properties that are absent from the default configuration.

In a container or cloud deployment, effective settings can come from image files, mounted configuration, orchestration manifests, environment variables, JVM options, command-line arguments, or an external configuration system. CI/CD jobs may inject values at startup, while operating-system service definitions may add JVM properties or environment variables.

When investigating a mismatch, check the active profiles first, then compare the relevant property sources in precedence order. A value in a profile file may be overridden by a container variable, and that variable may in turn be overridden by a command-line argument depending on the application's startup configuration.

Exposing Actuator endpoints over HTTP

Endpoint availability and endpoint exposure are separate concerns. An endpoint may exist in the application but not be reachable over HTTP because it is not included in web exposure. Conversely, an exposed endpoint still requires a valid management route and may be blocked by authentication, authorization, a firewall, or a proxy.

A deliberately limited exposure configuration might be:

management.endpoints.web.exposure.include=health,info,env

Including env should be an explicit operational decision. Avoid broad wildcard exposure in production unless every resulting endpoint has been reviewed and protected.

Management port and base path

Management endpoints can use a separate port:

management.server.port=8081

They can also use a dedicated base path:

management.endpoints.web.base-path=/actuator

With both settings, the management route may be on port 8081 even though application traffic uses another port. A public application URL may therefore return 404 while the endpoint is available through an internal management address. This separation is useful only when the management port or network is actually restricted.

Sensitive value sanitization

Sanitization masks or withholds values that may contain secrets. Actuator recognizes sensitive-looking property names and can display a masked value instead of the original. Examples include passwords, tokens, keys, credentials, and connection information.

Applications can add property-name patterns that should be sanitized:

management.endpoint.env.keys-to-sanitize=password,secret,key,token,credential

Sanitization is pattern-based and should be reviewed against the names used by the application and its libraries. A property whose name does not match an expected pattern could still contain sensitive data. Conversely, a harmless property may be masked because its name looks sensitive.

Security controls for production

Require authentication and authorization before allowing access to diagnostic endpoints. Limit access to trusted operators, private networks, bastion hosts, approved administrative tooling, or a protected management port. Use HTTPS and ensure that reverse proxies preserve the intended access policy.

Unauthorized access can reveal active profiles, hostnames, internal URLs, infrastructure details, feature configuration, library settings, and sometimes sensitive values. Even masked output can help an attacker map the deployment or infer which integrations are enabled.

Environment	Exposure recommendation	Access control	Risk considerations
Local development	Expose temporarily when needed	Bind to a local interface or require local authentication	Do not copy unmasked output into public issue trackers.
Shared test or staging	Expose only when operationally useful	Require named operator identities and restricted network access	Staging often contains realistic integration URLs and credentials.
Production	Disable or restrict env unless there is a documented need	Use strong authentication, authorization, private management traffic, and auditing	Configuration disclosure can support credential theft and infrastructure targeting.

Expose only the endpoints required for operations. If the env endpoint is not needed, omit it from web exposure or disable access through the management security policy. Do not weaken sanitization to reveal a credential; retrieve secrets through the approved secret-management system instead.

Practical diagnostic examples

Unexpected server port

Make an authorized request to the management route, confirming the correct host, port, and base path.
Check the active profiles and locate server.port in the property-source response or use the supported targeted lookup.
Compare the value in the default application file, profile-specific file, external configuration, SERVER_PORT, JVM system properties, and command-line arguments.
Identify the highest-precedence source supplying the effective value.
Correct the deployment source, restart or refresh the application as required, and verify the non-sensitive result again.

Profile-specific staging settings

Confirm that the expected profile, such as staging, is active. Then verify non-sensitive settings such as a feature mode, timeout, or service name and confirm that a profile-specific property source is present. Do not use a screenshot of the full response as evidence if it includes sensitive property names or values.

Database configuration mismatch

Check whether the expected datasource-related property names and sources are present. Compare safe metadata such as the selected profile, driver setting, pool size, or sanitized URL representation. Do not attempt to reveal a masked password or copy a full connection string into a log. Validate the secret through the approved secret-management system and compare the running deployment's secret reference with the expected reference.

Operational troubleshooting workflow

Verify reachability safely: use an approved internal request and confirm the expected management port and base path.
Interpret the status code: a 404 commonly indicates a missing dependency, unavailable endpoint, absent web exposure, or an incorrect route; 401 indicates missing or invalid authentication; 403 indicates insufficient authorization or another policy denial.
Check endpoint configuration: verify that the endpoint is available and included in HTTP exposure without opening it publicly.
Check management routing: confirm management.server.port, management.endpoints.web.base-path, proxy rules, firewall rules, and network placement.
Check authorization: use an approved operator identity and review role mappings rather than disabling security controls.
Check profiles: confirm active profiles and the presence of profile-specific sources.
Compare precedence: inspect non-sensitive property names and values from higher-precedence sources first.
Compare expected and observed settings: record only the minimum non-secret evidence needed to resolve the issue.
Protect diagnostic material: redact secrets and sensitive URLs from logs, tickets, chat messages, screenshots, and support requests.

Symptom	Likely cause	How to verify safely	Recommended remediation
The env endpoint returns 404	Actuator is absent; the endpoint is unavailable; web exposure excludes it; or the route uses another port or base path.	Check dependencies and management configuration through an authorized internal process.	Correct the intended management configuration or keep the endpoint restricted if it is not needed.
The endpoint returns 401 or 403	Authentication is required, the identity lacks the required authority, or a proxy adds access rules.	Confirm the policy and use an approved operator identity.	Adjust authorization mappings through the normal change process; do not remove protection.
A value differs from the expected setting	A higher-precedence source overrides it, an active profile supplies another value, or the property name was translated incorrectly.	Compare non-sensitive sources in precedence order and verify active profiles.	Correct the winning deployment source or profile selection.
A value is masked	The property name matches a sanitization rule or is considered sensitive.	Treat masking as expected and verify the secret reference through the approved secret system.	Keep sanitization enabled; do not expose the credential to diagnose it.

Key exam and review notes

The env endpoint inspects configuration; it does not change configuration.
The Spring Environment contains active profiles and ordered property sources.
The resolved value is determined by precedence, not simply by the value in the default application file.
Endpoint availability is distinct from HTTP exposure.
A separate management port or base path can make an endpoint unreachable from the public application route while it remains available internally.
Sanitization is valuable defense in depth, not permission to expose the endpoint publicly.
Production deployments should expose only necessary endpoints and restrict diagnostic access with authentication, authorization, and network controls.

For related operational access, see the env management route and the login page when your deployment provides them.