Spring Cloud Config & Discovery Dependencies
Learn how to centralize configuration and register services for discovery using Spring Cloud Config and Netflix Eureka dependencies.
Introduction
A microservices system might have dozens of services, each needing configuration and each needing to find the others at runtime. Spring Cloud provides two dependency pairs to solve this: Config Server/Client for centralized configuration, and Eureka Server/Client for service discovery.
- Why microservices need centralized config and service discovery.
- How to run a Config Server and connect a client to it.
- How to run a Eureka Server and register a client with @EnableDiscoveryClient.
- How these four dependencies fit together in a real microservices setup.
Why Externalized Config and Discovery?
Use case: instead of every microservice carrying its own copy of database URLs, feature flags, and secrets, a Config Server hosts them centrally (often backed by a Git repository), and services pull their config at startup. Similarly, instead of hardcoding "order-service is at http://10.0.0.5:8081", a discovery server like Eureka lets services register themselves by name and look each other up dynamically.
Config Server: spring-cloud-config-server
This dependency turns a Spring Boot application into a Config Server — a central place that serves configuration files (typically backed by a Git repository) to every other service in the system.
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-config-server</artifactId></dependency>@SpringBootApplication@EnableConfigServerpublic class ConfigServerApplication { public static void main(String[] args) { SpringApplication.run(ConfigServerApplication.class, args); }}server.port=8888spring.cloud.config.server.git.uri=https://github.com/your-org/config-repoConfig Client: spring-cloud-starter-config
Any other service adds spring-cloud-starter-config to pull its configuration from the Config Server at startup instead of relying only on its local application.properties.
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-config</artifactId></dependency>Point the client at the Config Server using spring.config.import (the modern approach, replacing the older bootstrap.yml pattern).
spring.application.name=order-servicespring.config.import=optional:configserver:http://localhost:8888Older Spring Cloud versions required a separate bootstrap.yml file to load config-server settings before the rest of the application context started. Modern Spring Boot (2.4+) replaces this with the simpler spring.config.import property shown above — prefer it for new projects.
Eureka Server: spring-cloud-starter-netflix-eureka-server
This dependency turns a Spring Boot application into a Eureka Server — a registry that every other service reports its location to, and that services query to find each other.
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId></dependency>@SpringBootApplication@EnableEurekaServerpublic class EurekaServerApplication { public static void main(String[] args) { SpringApplication.run(EurekaServerApplication.class, args); }}Eureka Client: spring-cloud-starter-netflix-eureka-client
Any service that should be discoverable adds this dependency and registers itself with the Eureka Server on startup.
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId></dependency>@SpringBootApplication@EnableDiscoveryClientpublic class OrderServiceApplication { public static void main(String[] args) { SpringApplication.run(OrderServiceApplication.class, args); }}eureka.client.service-url.defaultZone=http://localhost:8761/eureka/Click Run to see what this code prints.
Common Mistakes
- Forgetting spring.application.name — Eureka and Config Server both key off this to identify a service.
- Confusing the client and server starters (e.g. adding eureka-server to a regular microservice by mistake).
- Hardcoding the Config Server or Eureka Server URL without an "optional:" prefix, which fails startup entirely if that server is briefly unavailable.
- Not securing the Config Server, which can expose secrets if the Git repository contains real credentials.
Best Practices
- Give every service a unique, stable spring.application.name.
- Keep environment-specific secrets out of the Config Server's Git repo — use a vault or encrypted properties instead.
- Run Config Server and Eureka Server as their own small, independent Spring Boot applications.
- Use optional:configserver: so a service can still start with local defaults if the Config Server is temporarily down.
Frequently Asked Questions
It remains widely used and well-documented, though alternatives like Consul and Kubernetes' built-in service discovery are also common, especially in container-orchestrated environments.
No. They solve independent problems — you can use one without the other, though most non-trivial microservices systems end up using both.
Yes, this is a common pattern — register the Config Server with Eureka too, so clients can look it up by name instead of a hardcoded URL.
Summary
spring-cloud-config-server/starter-config centralize configuration across services, while the Eureka server/client dependencies let services register themselves and discover each other by name instead of hardcoded addresses.
- You understand why microservices need centralized config and discovery.
- You configured a Config Server and a client that pulls from it.
- You configured a Eureka Server and a client that registers with it.