What is Spring Cloud Config Server, and how do you turn a Spring Boot application into one?
answer
- @EnableConfigServer + config-server starter
- central versioned config, git/native/vault backend
- serves /{application}/{profile}/{label} over HTTP
- client: spring.config.import=configserver:...
- read-side only; refresh & encryption are separate
basics
~10 sIt is a central server that stores application configuration (usually in git) and serves it to client apps over HTTP. You add the spring-cloud-config-server dependency and put @EnableConfigServer on the main class.
solid answer
~40 sSpring Cloud Config Server externalizes configuration into a central, versioned place (git, filesystem, or Vault) instead of baking it into each service. Client applications fetch their properties from it over HTTP at startup, so many services share one source of truth and you can change config without rebuilding. You create it by adding the spring-cloud-config-server starter and annotating a @SpringBootApplication class with @EnableConfigServer, then pointing it at a backend, e.g. spring.cloud.config.server.git.uri. Clients declare spring.config.import=configserver:http://host:8888 (or the older bootstrap approach). The server exposes REST endpoints like /{application}/{profile}/{label} that return the merged property sources for that app, and it is the read side only — @RefreshScope reloading and encryption are separate concerns.
code
java · 19 lines// build.gradle: implementation 'org.springframework.cloud:spring-cloud-config-server'
@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {
public static void main(String[] args) {
SpringApplication.run(ConfigServerApplication.class, args);
}
}
// application.yml
// server:
// port: 8888
// spring:
// cloud:
// config:
// server:
// git:
// uri: https://github.com/acme/config-repogo deeper
Know it centralizes config in git and that @EnableConfigServer + the starter creates the server; a client fetches its own properties by name.
Explain server-vs-client split, the git.uri backend, and the client using spring.config.import; know it returns ordered property sources.
Discuss why (single source of truth, versioning, central change control) and the scope boundary vs refresh/encryption; know EnvironmentController + EnvironmentRepository are what @EnableConfigServer wires.
Weigh Config Server against alternatives (Kubernetes ConfigMaps, env vars, Consul), operational concerns like HA/caching, and when NOT to introduce it.
**The problem it solves.** In a microservice system every service needs configuration (DB URLs, feature flags, timeouts). Copying that into each deployable is fragile: no single source of truth, no history, and changing a value means rebuilding. Spring Cloud Config Server centralizes configuration in one place, keeps it versioned (git gives you history, diffs, rollback), and serves it to any number of client services over HTTP. **Server vs client.** There are two sides. The **Config Server** is a standalone Spring Boot app that reads a backend and exposes config over REST. **Config clients** are your normal services; at startup they call the server, download their properties, and add them to their own Spring `Environment`. **Making a server.** 1. Add the dependency `org.springframework.cloud:spring-cloud-config-server`. 2. Put `@EnableConfigServer` on a `@SpringBootApplication` class. This annotation imports the auto-configuration that wires up the `EnvironmentController` (the REST endpoints) and an `EnvironmentRepository` (the thing that actually reads the backend). 3. Configure a backend. The most common is git: `spring.cloud.config.server.git.uri=https://github.com/acme/config-repo`. Other backends: `native` (classpath/filesystem, good for local dev), `vault` (HashiCorp Vault for secrets), plus jdbc/redis. 4. Give the server a port, conventionally `server.port=8888`. **Making a client.** In Spring Boot 2.4+ the client adds `spring-cloud-starter-config` and sets `spring.config.import=configserver:http://localhost:8888` (older style used a `bootstrap.yml` with `spring.cloud.config.uri`). The client's `spring.application.name` becomes the `{application}` the server looks up, and its active Spring profiles become `{profile}`. **What the server returns.** For a request it produces an `Environment` object (a Spring Cloud DTO, not the core `org.springframework.core.env.Environment`) containing an ordered list of `PropertySource`s. The client merges these into its own environment following normal Spring precedence. **Scope boundaries (common confusion).** The Config Server is only the *serving* mechanism. Making a running client pick up changed values without a restart is `@RefreshScope` / the `/actuator/refresh` and bus — a separate feature. Encrypting/decrypting secret values (`{cipher}`) is also separate. This question is only about standing up the server and what it serves. **When to use.** Multiple services sharing config, needing audit history and central change control. For a single app, plain externalized `application.yml` or environment variables are simpler — don't add a Config Server just for one service.
- How does a client know which configuration to request?Its spring.application.name maps to {application} and its active Spring profiles map to {profile}; it points at the server via spring.config.import=configserver:http://host:8888 (or older bootstrap spring.cloud.config.uri).
- What happens on the server if you forget @EnableConfigServer?The config-server auto-configuration (EnvironmentController and EnvironmentRepository) is never imported, so the /{application}/{profile} endpoints don't exist and it behaves like an ordinary Boot app.
saying these in an interview costs you the question
- Thinking @EnableConfigServer also live-reloads client beans (that is @RefreshScope).
- Believing config can only live in git — native and Vault backends exist.
- Confusing the Spring Cloud Environment DTO with core Spring Environment.