Page History

...

In addition to application.properties files, profile-specific properties can also be defined using the naming convention application-{profile}.properties. You are advised to only use lower case filenames and lower case profile names because Spring profile names are case sensitive. The Environment has a set of default profiles (by default [default]) which are used if no active profiles are set (i.e. if no profiles are explicitly activated then properties from application-default.properties are loaded).

...

Spring profiles can be activated via JVM argument 'spring.profiles.active'. When a 'spring.config.location' is set the active profiles can also be set by placing a 'bootstrap.properties' in the config location directory. The 'bootstrap.properties' should then contain the 'spring.profiles.active' property, do not use the two mechanisms (JVM argument and 'bootstrap.properties') at the same time. The application server must be restarted after changing the active Spring profiles.

File System Backend

There is also a "native" profile in the Config Server that doesn’t use Git, but just loads the config files from the local classpath or file system (any static URL you want to point to with "spring.cloud.config.server.native.searchLocations"). To use the native profile just launch the Config Server with "spring.profiles.active=native".
Remember to use the "file:" prefix for file resources (the default without a prefix is usually the classpath). Just as with any Spring Boot configuration you can embed ${}-style environment placeholders, but remember that absolute paths in Windows require an extra "/", e.g. file:///${user.home}/config-repo
The Config Server runs best as a standalone application, but if you need to you can embed it in another application. Just use the @EnableConfigServer annotation. An optional property that can be useful in this case is spring.cloud.config.server.bootstrap which is a flag to indicate that the server should configure itself from its own remote repository. The flag is off by default because it can delay startup, but when embedded in another application it makes sense to initialize the same way as any other application.
If you want to read the configuration for an application directly from the backend repository (instead of from the config server) that’s basically an embedded config server with no endpoints. You can switch off the endpoints entirely if you don’t use the @EnableConfigServer annotation (just set spring.cloud.config.server.bootstrap=true).

...