Config Server

Centralize configuration for all microservices with Spring Cloud Config Server — manage environment-specific properties from a Git repository without redeployment.

Last reviewed: January 2025

·Spring Boot 3.xSpring Cloud 2023.x
✅
Quick Understanding: Spring Cloud Config Server is a centralized configuration service. All microservices pull their configuration from it at startup instead of having local application.properties. Config is stored in a Git repository — change a property, commit, and services pick it up on next restart (or immediately with @RefreshScope + Spring Cloud Bus).

🔍 What Is It?

Spring Cloud Config Server provides server-side and client-side support for externalized configuration.

Architecture:

  • →Config Server — a Spring Boot app that serves config from a Git repo
  • →Config Client — each microservice fetches its config from the server at startup
  • →Git backend — stores config files (application.yml, order-service.yml, etc.)

Config file resolution:

For order-service with profile prod, the server serves (in priority order):

  1. order-service-prod.yml
  2. order-service.yml
  3. application-prod.yml
  4. application.yml

Dynamic refresh:

  • →@RefreshScope on beans that should reload when config changes
  • →POST /actuator/refresh triggers refresh on one instance
  • →Spring Cloud Bus (Kafka/RabbitMQ) broadcasts refresh to all instances

🎯 Why Do We Need It?

In a microservices architecture with 20 services across dev/staging/prod, managing configuration is complex:

  • →20 services × 3 environments = 60 config files to maintain
  • →Changing a shared property requires updating all services
  • →No audit trail for config changes

Config Server centralizes this: one Git repo, all services pull from it, Git history tracks all changes.

🏗️ What Happens in Real Projects?

Enterprise config management:

  • →Database URLs per environment in Git
  • →Feature flags managed centrally
  • →Secrets via Spring Cloud Vault (not in Git)
  • →Config changes without redeployment via @RefreshScope

⚙️ How It Works

Config Server clones the Git repo and serves config files via REST API. Clients call the server at startup (before the ApplicationContext is fully initialized) via bootstrap.yml or spring.config.import. The fetched properties are merged with local properties (local takes priority).

💻 Example

Config Server Setup — Server setup, client configuration, and dynamic refresh.

java
@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConfigServerApplication.class, args);
    }
}

// application.yml for Config Server:
// server:
//   port: 8888
// spring:
//   cloud:
//     config:
//       server:
//         git:
//           uri: https://github.com/company/microservices-config
//           default-label: main
//           search-paths: '{application}'  # per-service subdirectory
//           username: ${GIT_USERNAME}
//           password: ${GIT_TOKEN}

🤔 Common Confusions

❓ Should I put secrets in the Config Server Git repo?

No. Secrets (passwords, API keys) should not be in Git, even in a private repo. Use Spring Cloud Vault (HashiCorp Vault) for secrets, or environment variables from Kubernetes Secrets. Config Server can be configured to use Vault as a backend alongside Git — non-sensitive config from Git, secrets from Vault.

❓ What happens if the Config Server is down when a service starts?

With fail-fast: true, the service fails to start — which is correct. A service without its config might behave incorrectly. Configure retry to attempt multiple times before failing. In production, run multiple Config Server instances behind a load balancer for high availability.

🚨 Common Production Issues

Config Server single point of failure — run multiple instances

Git repo credentials in Config Server properties — use environment variables

@RefreshScope not applied to @Configuration beans — those require restart

✅ Best Practices

Run multiple Config Server instances for high availability

Use Vault for secrets, Git for non-sensitive config

Tag Git commits for config changes — enables rollback

Use Spring Cloud Bus for broadcasting refresh to all instances

Test config changes in dev/staging before applying to production

🏛️ Architect's Note

Senior Architect's Perspective

Config Server is powerful but adds operational complexity. For Kubernetes-native deployments, ConfigMaps and Secrets provide similar functionality without the extra service. Use Config Server when you need: centralized config across non-Kubernetes environments, config history/audit via Git, or dynamic config refresh without restart. For simple Kubernetes deployments, ConfigMaps may be sufficient.

💬 Frequently Asked Questions

How do I handle config encryption?

Spring Cloud Config Server supports symmetric (AES) and asymmetric (RSA) encryption. Encrypt sensitive values with the /encrypt endpoint, store the cipher text in Git ({cipher}...), and the server decrypts on delivery. Better approach: use Vault for secrets and skip encryption in Git entirely.

🎯 Key Takeaways

1Config Server serves centralized config from a Git repository
2Clients use spring.config.import=configserver: to fetch config at startup
3@RefreshScope enables dynamic bean recreation when config changes
4Never put secrets in Git — use Vault or Kubernetes Secrets
5Run multiple Config Server instances for high availability
6Spring Cloud Bus broadcasts config refresh to all instances simultaneously

🎯 Practice this topic in interviews

↗ Where this topic fits

Sources

Sources / References

Use these Spring Boot references to verify the concept in official docs and continue into the most relevant SplashRide pages.

Related SplashRide pages

SplashRide Spring Boot learning path

Browse the full Spring Boot topic collection and learning order on SplashRide.

Spring Boot Interview Prep

Practice Spring Boot interview questions and scenario-based answers.

Backend Engineer Career Path

A structured journey through Core Java, Spring Boot, production backend engineering, and interview preparation.

Full Stack Java Developer Career Path

A guided route through frontend foundations, Java backend engineering, delivery workflows, and interview readiness.

API Gateway

Implement an API Gateway with Spring Cloud Gateway — the single entry point for all microservices that handles routing, authentication, rate limiting, and cross-cutting concerns.

Service Discovery

Implement service discovery with Spring Cloud Eureka — enabling microservices to find each other dynamically without hardcoded URLs.