• notice
  • Congratulations on the launch of the Sought Tech site

Using Spring Cloud Config without Git

1. Introduction

Spring Cloud Config is a library that makes it easy to externalize the configuration of Spring applications. It allows us to expose configuration data as a service, which can be easily fetched from any other application with an HTTP client.

In this tutorial, we will see how to use Spring Cloud Config without git.

2. Spring Cloud Configuration Overview

The Spring Cloud Config library is a typical client-server model . A centralized server (or servers) reads configuration data from some external data source. These servers expose various HTTP endpoints that allow any other application to query configuration data.

using-spring-cloud-config-without-git (1).jpg

Spring Cloud Configuration Overview

Spring Cloud Config also makes it very easy to automatically connect to a configuration server from a Spring Boot application. The server-provided configuration data can then be used like any other property source in the client application .

3. Git provider

The most common use case for Spring Cloud Config is to store configuration data in a git repository . This type of setup has several advantages:

  • Flexibility: A git repository can hold various file types, including binary files.

  • Security: Easy to control read and write access at a granular level.

  • Auditing: Robust history tracking allows easy auditing of configuration changes.

  • Standardized: Git operations are standard regardless of provider, which means we can self-host or use any number of third-party providers.

  • Distributed: Git was designed from the ground up to be distributed, making it ideal for cloud-native and microservices architectures.

However, despite all the benefits listed above, git may not always be the best choice for storing configuration data . For example, our organization may have placed configuration data in another data store, such as a relational database. In this case, it might not be worth migrating it to git.

In the next section, we'll take a closer look at using Spring Cloud Config without git.

4. Using Spring Cloud Config without Git

When we talk about using something other than git in Spring Cloud Config, we actually mean the server component. Our choice of data storage does not affect client-side components. Only the server is affected.

In the Spring Cloud Config Server library, there is an EnvironmentRepositoryinterface called , which is used to define configuration sources. All configuration sources, git or otherwise, must implement this interface .

Let's look at some of the provided implementations.

3.1 File system

Spring Cloud Config supports using the file system as a configuration source. application.propertiesTo enable this feature, we must specify the following values in the config server's file:


By default, the search location takes the classpath resource. If we want to use arbitrary files, we simply include a file resource prefix:


In addition to this property, the config server needs to run with native config files enabled:


It's important to remember that when using a filesystem to configure a source, we need to make sure that the filesystem is available wherever the config server will run . This might mean using a distributed filesystem such as NFS.

3.2. JDBC

Spring Cloud Config can also load configuration data via JDBC using a relational database. This is done through JdbcEnvironmentRepositoryclasses. To enable this class, we have to follow a few steps.

First, spring-jdbcthe library must exist on the classpath. If we are already using Spring Data JDBC or other dependency library then it is already there. Otherwise, we can always specify it manually:


Second, we need to specify how to connect to the database:


In this case we are using MySQL, but any JDBC compliant driver will work.

Next, the database must contain a PROPERTIEStable named with the following columns:

  • application

  • contour

  • Label

  • key

  • value

Finally, we need to specify the JDBC configuration file for the configuration server:


3.3. Redis

Spring Cloud Config also supports Redis as a configuration source. This is done using RedisEnvironmentRepositoryclasses. Similar to the JDBC source, we need to follow a few steps to enable it.

First, we need to add a dependency to Spring Data Redis :


Second, we need to set some properties for how to connect to Redis:


Next, we have to make sure that our properties are properly stored in Redis. We can use the HMSETcommand to store some example properties:

HMSET application sample.property.name1 "somevalue" sample.property.name2 "anothervalue"

If we were to echo these properties, we should see the following data:

HGETALL application
"sample.property.name1": "somevalue",
"sample.property.name2": "anothervalue"

Finally, we have to enable the Redis configuration file for the Spring Cloud Config server:


Using Redis as a configuration source also supports different configuration files. To do this, we simply add the profile name to the end of the application:

HMSET application-dev sample.property.name1 "somevalue" sample.property.name2 "anothervalue"

In this example, we will devcreate a new set of properties under a configuration file named .

3.4. Secrets

A popular feature of many cloud providers is secrets. Secrets allow us to securely store sensitive data as part of our cloud infrastructure. These are great for things like usernames, hostnames, and passwords that we want to have as part of our application configuration.

Spring Cloud Config provides support for many different cloud secret providers. Next, we'll look at AWS, which uses AwsSecretsManagerEnvironmentRepositoryclasses to load AWS secrets into property sources.

This class relies on AWSSecretsManagerclasses to do the heavy lifting of communicating with AWS. While we can manually create it ourselves, a more straightforward solution is to use the Spring starter :


This module contains an auto-configuration that will create an AWSSecretsManagerinstance for us. All we have to do is bootstrap.ymlspecify a set of properties in the file:

default-context: application
prefix: /config
profile-separator: _
fail-fast: true
name: ConfigServerApplication
enabled: true

Now, let's say we want to store our database credentials in a secret and make it available to the config server. We just /config/application/database_credentialscreate a new key at the path. Internally, we will store the necessary key/value pairs needed to connect to the database.

This construct also supports different profiles. For example, if we have a development database server, we can also create a separate secret for it. we named it/config/application/database_credentials_dev.

3.5. S3

Another convenient way to store configurations is to use cloud file services. Let's see how to use AWS S3 as a configuration source.

First, we need to add the AWS SDK to our project:


Then, we need to provide some values to configure the connection to the S3 bucket containing our properties file:


Also, we need to provide specific properties for the AWS S3 configuration provider:

region: us-east-1
bucket: config-bucket

We also need to set up the configuration file to ensure that the AWS S3 configuration source is loaded:


All that's left is to create the properties files we want in the bucket, including any profile-specific files. Note that the config server is assumed to be when the application has no config file default. Therefore, we should include a file with this suffix and any other file with a specific profile name .

3.6. Custom configuration source

If any of the provided configuration sources do not meet our needs, we can always choose to implement our own. Typically, this involves creating a new class that implements EnvironmentRepositoryand :Ordered

public class CustomConfigurationRepository implements EnvironmentRepository, Ordered {
public Environment findOne(String application, String profile, String label) {
// Return a new Environment that is populated from
// our desired source (DB, NoSQL store, etc)
public int getOrder() {
// Define our order relative to other configuration repositories
return 0;

Then, we simply instantiate this class as a new Spring bean:

public CustomConfigurationRepository customConfigurationRepository() {
return new CustomConfigurationRepository();

4. Multiple configuration sources

In some cases, it may be necessary to run Spring Cloud Config with multiple configuration sources. In this case, we have to specify several pieces of data.

Suppose we want to use both JDBC and Redis as configuration sources. The first thing we need to do is bootstrap.ymldefine the order of each source in the file:

order: 2
order: 1

This allows us to specify the priority of which configuration sources should be used before other configuration sources. Because the ordering follows normal Spring Orderedannotation processing, lower number of sources will be checked first .

Additionally, we need to define two configuration files for the server:


Note that we can also specify the active profile in YAML. Also, the same pattern can be used to define any number of configuration sources .

5 Conclusion

In this article, we introduced various configuration sources that can be used with Spring Cloud Config. While git is a good default source for many projects, it may not always be the best choice. We've seen that Spring Cloud Config offers a variety of options, as well as the ability to create custom providers.


Technical otaku

Sought technology together

Related Topic


Leave a Reply