Reading configurations from the class path location of Spring Cloud Config Server

1. Introduction

In this tutorial, we’ll learn how to read configurations from the class path location of Spring Cloud Config Server. By default, the Config server uses “Git’ to load config. There is a native profile in the Config server that loads the config files from the local classpath or file system. You can specify the search location (any static URL) with spring.cloud.config.server.native.searchLocations.

Note that the application.properties from the server is not exposed to all clients, because any property sources present in the server are removed before being sent to the client.

The approach to load config from the filesystem is great for getting started quickly. But in production, you should ensure that the file system is reliable and shared across all instances of the Config Server.

The search locations can contain placeholders for {application}, {profile}, and {label}. By doing so, you have the option to organize the directories within the path and adopt a strategy that aligns with your preferences, such as organizing by subdirectory for each application or subdirectory for each profile.

2. Steps to read configurations from the class path

With the help of an example, we’ll explore the steps to read configurations from the class path.

2.1 Add dependency

The Spring Cloud Config server can be embedded in the Spring Boot application. You need to add the following dependency in your pom.xml:


2.2 Add ‘@EnableConfigServer’ annotation

You need to add @EnableConfigServer annotation to the Spring Boot application.

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.config.server.EnableConfigServer;

public class ConfigserverApplication {

	public static void main(String[] args) {
		SpringApplication.run(ConfigserverApplication.class, args);


2.3 Add configuration files

For demonstration purpose, create folder with name as config in the resources folder. In this folder, we’ll add configurations for two services, service1 and service2. Each service can have multiple profiles. For each profile, we’ll add a file.

  • service1.yml
  • service1-prod.yml
  • service1-qa.yml
  • service2.yml
  • service2-prod.yml
  • service2-qa.yml

Following is the content of service1 files.


  version: 1.1
  message: Service1 message - Default


  version: 1.1
  message: Service1 application message - Prod environment


  version: 1.1
  message: Service1 application message - QA environment

Similarly, you can create configuration files for service2.

2.4 Update application.yml

As discussed earlier, spring.profiles.active=native enables you to load from the filesystem instead of Git. Next, you have to specify the search locations for the files. The application.yml should look like the following:

    name: configserver
    active: native
          search-locations: "classpath:/config"

2.5 Run the application

After all these steps, you can start the server. You can access the ‘default’, ‘prod’ and ‘qa’ configurations for the service1 using the following endpoints:

  • http://localhost:8080/service1/default
  • http://localhost:8080/service1/qa
  • http://localhost:8080/service1/prod

The ‘prod’ configurations returned by the Spring Cloud Config Server are:

    "name": "service1",
    "profiles": [
    "label": null,
    "version": null,
    "state": null,
    "propertySources": [
            "name": "classpath:/config/service1-prod.yml",
            "source": {
                "build.version": 1.1,
                "application.message": "Service1 application message - Prod environment"
            "name": "classpath:/config/service1.yml",
            "source": {
                "build.version": 1.1,
                "application.message": "Service1 message - Default"

3. Conclusion

In this tutorial, we explored the approach of fetching configurations directly from the classpath of the Spring Cloud Config Server.