Externalized Configuration
Spring Cloud Config: one central, versioned source of configuration for every service and environment.
On this page
One service has one application.yml. Twenty services across three environments have sixty
config files scattered everywhere - and changing a shared setting means editing and
redeploying them all. Spring Cloud Config centralizes configuration into one versioned
source that every service reads at startup.
One source of truth
A Config Server serves configuration (usually from a Git repository) to all your services. Each service, on startup, asks the config server for its settings by name and profile:
# in each service
spring:
config:
import: "configserver:http://config-server:8888"
application:
name: lending-service # the server returns lending-service.ymlThe config server reads lending-service.yml (plus lending-service-prod.yml for the
active profile) from the central Git repo and hands it over. Change a value in Git, and the
change is versioned, reviewable, and available to every service.
Imagine company policies written on sticky notes stuck to each employee's desk - to update one rule you'd visit every desk. A single, version-controlled handbook everyone consults fixes that: one edit, everyone gets the new rule. The config server is that handbook for your services' settings.
Config in Git = auditable and revertible
Backing the config server with Git means every configuration change has a history, an author, and a diff - and a bad change can be reverted like any commit. Secrets, though, still belong in a secrets manager, referenced from config, not committed in plain text.
Fifteen BookVault services all point at the same message broker, whose address must change. Contrast doing this with a per-service config file versus a Spring Cloud Config Server, and name one safety benefit of the Git-backed approach.
What does Spring Cloud Config provide?
Key takeaways
- Spring Cloud Config centralizes configuration into one source (usually Git) that all services read at startup.
- Each service requests its config by application name and profile via spring.config.import.
- A shared setting changes in one place instead of editing and redeploying every service.
- Git-backing gives configuration a full history, review, and easy revert.
- Secrets still go in a secrets manager, referenced from config - never committed in plain text.