Skip to content

Application- and profile-specific configuration usage - undocumented or not meant to be used? #1868

Closed

Description

@filpano

We are currently using a feature of the Spring Cloud Config server that I find quite neat, which is using an application- and profile-specific .yml file on the Config server side that is named ${spring.application.name}-<profile>.yml.

This is allowed through the use of the:

@RequestMapping(path = "/{name}/{profiles}/{label:.*}",
		produces = EnvironmentMediaType.V2_JSON)
public Environment labelledIncludeOrigin(@PathVariable String name,
		@PathVariable String profiles, @PathVariable String label) {
	return getEnvironment(name, profiles, label, true);
}

endpoint. This feature allows some very nice configuration setups (e.g. separate DataSource properties for separate applications, neatly separated from each other). So, for example:

config/
    application.yml                     # Standard properties
    application-${profile}.yml          # Profile relevant settings
    book-service.yml                    # Standard properties for "book-service" only
    book-service-${profile}.yml         # Profile-specific settings for "book-service" only

However, I cannot find any documentation for this feature. Seeing how the endpoint exists, I am assuming that it was meant to be used. Is this a documentation oversight (which I can gladly make a PR for), or was there an intention to deprecate this endpoint at some time?

Activity

  1. filpano commented on Apr 28, 2021

    @filpano
    Author

    According to these two:

    #1856 (comment)
    #1856 (comment)

    comments, it seems this is a indeed a supported feature. I'll get a PR to enhance the documentation up within the next few days.

  2. ChiragMoradiya commented on May 23, 2021

    @ChiragMoradiya

    I needed to validate behavior to understand which one is given more preference than other. My finding is as follows:

    Configurations are used in the following orders:

    • book-service-${profile}.yml
    • application-${profile}.yml
    • book-service.yml
    • application.yml

    So, when the configuration property is available in book-service-${profile}.yml it's used at the top priority. If it doesn't exist there, then application-${profile}.yml is searched, and so on.

  3. sharanggupta commented on Oct 15, 2026

    @sharanggupta
    Contributor

    I opened #3347 with an ordered list of these files in the Environment Repository docs, and a test that pins the order: {application}-{profile} first, then application-{profile}, then {application}, then application, with the last listed profile ranking highest. That matches what @ChiragMoradiya observed above.

  4. added this to the 5.1.0-RC1 milestone on Oct 15, 2026
  5. moved this from Todo to In Progress in 2026.0.0-RC1on Oct 15, 2026
  6. moved this from In Progress to Done in 2026.0.0-RC1on Oct 15, 2026
  7. added a commit that references this issue on Oct 16, 2026
    c08df45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions