Actuators: Types, Operation, Selection, and Control

Spring Boot Actuator Env Endpoint

Learn how to use Spring Boot Actuator's env endpoint to inspect profiles, property sources, configuration precedence, overrides, and sanitized values safely.

The Spring Boot Actuator env endpoint reports information from the Spring Environment of a running application. The Spring Environment is Spring's abstraction for active profiles and ordered property sources used to resolve configuration.

This makes the endpoint useful when runtime behavior does not match the configuration you expected. You can investigate active profiles, operating-system environment variables, Java system properties, command-line arguments, application configuration files, and other forms of externalized configuration.

The endpoint is primarily an inspection tool. It reports configuration and its sources; it does not normally edit application configuration or change the running application.

How the env endpoint works

Actuator is Spring Boot's production-ready feature set for monitoring, diagnostics, and operations. A management endpoint is one of the operational endpoints supplied by Actuator. The env endpoint is the management endpoint that reports environment properties and their property sources.

With the default Actuator HTTP base path, the full route is usually /actuator/env. For example, an application listening on port 8080 may be queried with:

curl -s http://localhost:8080/actuator/env

The exact URL can differ when the application changes its management web base path or uses a separate management port.

Enabled versus exposed

An endpoint being enabled means that Actuator creates and makes the endpoint available within the application. An endpoint being exposed means that it is made accessible through a technology such as HTTP or JMX.

These are separate decisions. An enabled env endpoint may not be reachable over HTTP if it is absent from HTTP exposure configuration. Conversely, exposure configuration does not make a specifically disabled endpoint available.

To expose a selected set of endpoints over HTTP in application.properties:

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

The equivalent YAML configuration is:

management:
  endpoints:
    web:
      exposure:
        include: health,info,env

To explicitly exclude the endpoint from HTTP exposure:

management.endpoints.web.exposure.exclude=env

To disable the endpoint itself:

management.endpoint.env.enabled=false

Exposure defaults, endpoint defaults, and the interaction between include and exclude settings can vary by Spring Boot release. Check the documentation for the version installed by your application.

Routes and typical uses

Route — Purpose — Typical use — Access considerations

/actuator/env — Reports active profiles, default profiles, and environment property sources — Investigate broad configuration and precedence issues — Restrict to trusted, authenticated operators because the response may reveal sensitive metadata.

/actuator/env/{propertyName} — Reports matching property sources for one property — Find the origin of an unexpected setting without retrieving every property source — Still protect the route because a property name or value can be sensitive.

Reading the response

A full env response commonly contains high-level profile information and a collection of property sources. Field names and the exact JSON shape can differ between Spring Boot versions, so treat the following as a conceptual structure rather than a version-independent schema:

{
  "activeProfiles": ["production"],
  "defaultProfiles": ["default"],
  "propertySources": [
    {
      "name": "...",
      "properties": {
        "server.port": {
          "value": "8080"
        }
      }
    }
  ]
}

Active profiles are the selected Spring profiles. A profile can activate profile-specific configuration and beans. Default profiles are used when no active profile has been selected.

A property source is a named source of key-value configuration properties. Common sources include:

  • Command-line arguments passed to the application.
  • Java system properties supplied with JVM options such as -Dserver.port=8081.
  • Operating-system environment variables.
  • Application configuration files such as application.properties or application.yml.
  • Profile-specific files such as application-production.yml.
  • Random-value sources.
  • Test-specific property sources when running under a test context.

Each property entry identifies a property name and usually displays a value. Sensitive values may be replaced with a masked representation rather than shown in raw form.

Finding the effective value

To determine where a setting comes from:

  1. Find the canonical property name you are investigating.
  2. Search the property sources for that name.
  3. Note every source containing the property, not just the first visible match.
  4. Compare the sources using Spring Boot's property precedence rules and the response ordering for your installed version.
  5. Identify the value supplied by the source with the highest applicable precedence.

The same property can occur in several sources. The effective value is selected by property precedence: the ordering rules that decide which value wins when multiple sources define the same key.

Property source precedence and overrides

Configuration files are often treated as the application's baseline, while deployment-specific sources override that baseline. For example, a packaged application.properties value can be overridden by a profile-specific file, environment variable, Java system property, command-line argument, or test property source, depending on the applicable Spring Boot version and context.

Do not infer precedence from the fact that a property appears in a file you edited. A deployment environment may supply the same property through a higher-priority source.

Property source category — Typical origin — Example property — Override considerations

Command-line arguments — Arguments such as --server.port=9090 — server.port — Often intended as an explicit deployment-time override.

Java system properties — JVM options such as -Dspring.profiles.active=staging — spring.profiles.active — Compare JVM startup arguments with configuration files and environment variables.

Operating-system environment variables — Container, shell, or orchestrator variables — SERVER_PORT — Frequently overrides packaged configuration in deployments.

Application configuration files — application.properties or application.yml — spring.datasource.url — Usually supplies a baseline value.

Profile-specific configuration files — application-production.yml — server.port — Applies only when the related profile is active and may override a general file.

Test property sources — Test annotations, test arguments, or test resource files — spring.datasource.url — Can override application configuration only in the test context.

Example: unexpected port

Suppose an application file sets server.port=8080, but the deployed application listens on another port. Query the property specifically:

curl -s http://localhost:8080/actuator/env/server.port

Inspect every matching property source. You might find the application file setting alongside SERVER_PORT=8081, a JVM system property, or a command-line argument. The source with the winning precedence explains the runtime port.

Example: unexpected active profile

Request the full endpoint and inspect both the profile summary and the sources containing spring.profiles.active:

curl -s http://localhost:8080/actuator/env

Compare profile settings from configuration files, environment variables, JVM arguments, and command-line arguments. An unexpected SPRING_PROFILES_ACTIVE value in a container is a common cause of a different profile being selected.

Querying one property

The property-specific route is /actuator/env/{propertyName}. It narrows the response to property sources containing the requested property, making it useful for diagnosing one setting without retrieving every source.

curl -s http://localhost:8080/actuator/env/spring.datasource.url

This can show where a datasource URL was supplied while allowing you to verify that any password or token remains sanitized. If a property name contains characters with special meaning in a URL, encode the path segment. For example, use a URL-aware client or percent-encode reserved characters rather than copying an ambiguous raw path.

Single-property lookup is especially useful for server.port, spring.profiles.active, and spring.datasource.url. It does not bypass authorization or sanitization.

Configuration names and relaxed binding

Relaxed binding lets Spring Boot map equivalent naming styles to configuration properties. The canonical name is normally written in lowercase dotted kebab case. Environment variables use uppercase letters and underscores because shells and container platforms conventionally represent names that way.

Canonical property name — Configuration-file form — Environment-variable form — Lookup note

server.port — server.port or server-port — SERVER_PORT — Look up the canonical key and then inspect sources for the environment-variable representation.

spring.profiles.active — spring.profiles.active — SPRING_PROFILES_ACTIVE — Compare the active profile summary with every matching source.

spring.datasource.url — spring.datasource.url — SPRING_DATASOURCE_URL — An environment variable can override a URL supplied by an application file.

For example, a container can provide:

SPRING_DATASOURCE_URL=jdbc:postgresql://db.example.internal:5432/app

Spring Boot maps that environment variable to spring.datasource.url. The source may display the environment variable using its original naming style even though application code refers to the canonical property name.

Camel case, dotted names, kebab case, underscores, and uppercase environment-variable forms may not appear identically in the response. When investigating an override, consider equivalent relaxed-binding forms rather than searching only for one spelling.

Sanitization and secret protection

Sanitization masks sensitive configuration values in endpoint output. Passwords, credentials, tokens, API keys, and similar secrets should never be intentionally revealed through an operational endpoint.

Spring Boot provides default sanitization behavior, and values whose property names match sensitive patterns may appear masked. Applications can add patterns with:

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

The exact default patterns and property behavior can vary by release. Review the documentation for the installed Spring Boot version and test the output with representative property names.

Sanitization affects presentation in the endpoint response. It does not remove the secret from the application, rotate it, prevent the application from using it, or protect other copies of the same secret. Masking must therefore be combined with a proper secret-management system, limited endpoint access, auditing, and credential rotation.

Secure production operations

Expose the env endpoint only to trusted administrative networks and authenticated operators. A sound deployment normally combines several controls:

Control — Why it matters — Example implementation

Explicit endpoint exposure — Prevents accidental publication of diagnostic endpoints — Include only the required endpoints, such as health,info, and add env only when justified.

Authentication and authorization — Ensures that only approved operators can read environment data — Integrate Actuator routes with Spring Security and require a narrowly scoped administrative authority.

Network restriction — Reduces the number of systems that can reach the endpoint — Use a trusted administrative network, firewall rules, private ingress, or a container network policy.

TLS — Protects credentials and diagnostic data in transit — Serve management traffic through HTTPS and validate client access appropriately.

Sanitization — Reduces accidental disclosure of sensitive values — Configure management.endpoint.env.keys-to-sanitize and verify masked output.

Disablement when unused — Removes an unnecessary attack surface — Set management.endpoint.env.enabled=false or omit it from HTTP exposure.

Spring Security integration is conceptually straightforward: authenticate the request, match the Actuator route, and authorize only an appropriate operator role or authority. Do not weaken security merely because a diagnostic request returns 401 or 403.

A separate management port can help isolate operational traffic, but it is not a complete security boundary by itself. Combine it with TLS, authentication, firewall restrictions, and least-privilege authorization.

Even fully masked responses can expose infrastructure topology, database hostnames, service names, deployment conventions, feature flags, and the names of sensitive configuration properties. Treat the endpoint as confidential operational data.

Troubleshooting

/actuator/env returns 404

  • Confirm that the Actuator dependency is on the application classpath.
  • Check whether management.endpoint.env.enabled is set to false.
  • Check the configured management.endpoints.web.base-path.
  • Check whether management traffic uses a different management.server.port.
  • Confirm that the endpoint is included in HTTP exposure and is not excluded.

The endpoint returns 401 or 403

  • Authenticate with authorized operational credentials in a non-public environment.
  • Review Spring Security endpoint rules and role mappings.
  • Check whether the authenticated user has the required Actuator authority.
  • Do not make the endpoint public just to simplify diagnosis.

The endpoint exists but is inaccessible over HTTP

  • Review management.endpoints.web.exposure.include.
  • Review management.endpoints.web.exposure.exclude.
  • Remember that enabled does not mean exposed over HTTP.
  • Check whether the endpoint is available through another management technology, such as JMX, rather than HTTP.

A value is masked

  • Treat masking as expected when the property name matches a sanitization rule.
  • Review the configured keys-to-sanitize patterns when diagnosing the behavior.
  • Do not broadly remove sanitization in production.

The configured value is not effective

  • Use the property-specific endpoint.
  • Compare all matching property sources.
  • Inspect active and default profiles.
  • Check deployment-provided environment variables and JVM system properties.
  • Check command-line arguments and test-specific sources.
  • Consider relaxed-binding equivalents such as spring.datasource.url and SPRING_DATASOURCE_URL.

Version considerations

Do not assume that every Spring Boot release produces the same env payload. Exact fields, endpoint enablement, default sanitization patterns, exposure defaults, property names, and security behavior can vary across versions.

When troubleshooting, consult the documentation for the application's installed Spring Boot version. Avoid applying older Actuator paths, deprecated configuration properties, or legacy security assumptions without verifying that they still apply.

Practical diagnostic workflow

  1. Confirm the management base path, management port, and HTTP exposure settings.
  2. Authenticate from a trusted administrative location.
  3. Start with a single-property request when one setting is in question.
  4. Use the full endpoint when you need profile information or broader source comparison.
  5. Record the property name, source names, and precedence reasoning, but do not copy secrets into diagnostic records.
  6. Correct the higher-precedence deployment source or profile rather than editing a lower-precedence file that cannot win.
  7. After diagnosis, reduce exposure or disable the endpoint if it is not continuously required.

For related Actuator diagnostics, see Spring Boot Actuator, the configprops endpoint, and the mappings endpoint. The env endpoint focuses on property sources and resolved environment data, while configprops focuses on configuration properties bound to application components.