Filesystem backend

I won't write a lot about this topic, because it has already been discussed in the previous examples. All of them have shown how to store property sources in the classpath. There is also the ability to load them from disk. By default, the Spring Cloud Config Server tries to locate files inside an application's working directory or the config subdirectory at this location. We can override the default location with the spring.cloud.config.server.native.searchLocations property. The search location path may contain placeholders for application, profile, and label. If you don't use any placeholders in the location path, the repository automatically appends the label parameter as a suffix.

As a consequence, the configuration files are loaded from each search location and a subdirectory with the same name as the label. For example, file:/home/example/config is the same as file:/home/example/config,file:/home/example/config/{label}. This behavior may be disabled by setting spring.cloud.config.server.native.addLabelLocations to false.

As I have already mentioned, a filesystem backend is not a good choice for a production deployment. If you place property sources in a classpath inside a JAR file, every change requires a recompilation of the application. On the other hand, using a filesystem outside of a JAR does not need recompilation, but this approach may be troublesome if you have more than one instance of a config service working in a high availability mode. In that case, share the filesystem across all of the instances or hold a copy of all of the property sources per running instance. The Git backend is free from such disadvantages, and that's why it is recommended for production use.