skip to content

How does a Spring Boot application connect to a Spring Cloud Config Server using spring.config.import, and what does the configserver: prefix do?

level: juniorimportance: must knowfreq 78%

answer

  1. spring.config.import=configserver:
  2. spring-cloud-starter-config dependency
  3. default URI localhost:8888
  4. name + profile + label resolve config
  5. optional: prefix to tolerate missing server

basics

~10 s

Add the spring-cloud-starter-config dependency, then set spring.config.import=configserver:http://localhost:8888 in application.yml. On startup the app fetches its properties from that Config Server before creating beans.

solid answer

~40 s

Since Spring Boot 2.4 / Spring Cloud 2020.0, you add spring-cloud-starter-config and declare spring.config.import=configserver: in application.properties or application.yml. The configserver: prefix is a ConfigData location handled by Spring Cloud; it tells Boot to reach out to the Config Server during the normal environment-loading phase and pull down that application's property sources. The URL can be given inline (configserver:http://config:8888) or omitted, in which case spring.cloud.config.uri (default http://localhost:8888) is used. The server resolves which properties to send using the app's name (spring.application.name), active profiles, and label. This replaced the old bootstrap.yml approach — no separate bootstrap context is needed anymore; it all happens through Boot's standard ConfigData import mechanism.

code

yaml · 11 lines
yaml
# application.yml (client)
spring:
  application:
    name: orders          # -> server serves orders-<profile>.yml
  profiles:
    active: prod
  config:
    import: "configserver:http://config-server:8888"
  cloud:
    config:
      label: main          # git branch/tag on the server

go deeper

for a junior

Know the property name spring.config.import=configserver: and that the starter dependency is required.

for a middle

Explain how name/profile/label select the returned config and the optional: prefix.

for a senior

Contrast the ConfigData import with the legacy bootstrap approach and know the resolver/loader classes involved.

for a principal

Reason about failure modes at startup, default URIs across environments, and standardizing the import config across a fleet of services.

## What problem this solves Spring Cloud Config **Server** is a central service that stores configuration (typically backed by a Git repo). A **Config Client** is any Spring Boot app that fetches its properties from that server at startup instead of hard-coding them locally. This gives you one place to manage config across many services and environments. ## The modern mechanism: spring.config.import Starting with **Spring Boot 2.4** and **Spring Cloud 2020.0 (Ilford)**, the client connects using Boot's **ConfigData API** via the property: ``` spring.config.import=configserver:http://localhost:8888 ``` - `spring.config.import` is a **core Spring Boot** property for importing additional configuration from external locations (files, config trees, and — with Spring Cloud on the classpath — a Config Server). - The `configserver:` prefix is a **ConfigData location**. Spring Cloud Config registers a `ConfigServerConfigDataLocationResolver` and a `ConfigServerConfigDataLoader` (through `META-INF/spring.factories`) that recognize this prefix and know how to call the server. - Everything happens during Boot's **normal Environment preparation** — no separate application context. ## Required dependency ``` org.springframework.cloud:spring-cloud-starter-config ``` Without it, `configserver:` is an unknown location and startup fails. ## How the server picks what to return The server resolves configuration from three coordinates the client sends: - **application** = `spring.application.name` (defaults to `application`) - **profile** = active profiles (`spring.profiles.active`) - **label** = Git branch/tag (`spring.cloud.config.label`, default is the server's configured default, often `main`) So an app named `orders` with profile `prod` receives properties merged from files like `orders-prod.yml`, `orders.yml`, `application-prod.yml`, `application.yml` on the server side. ## The URL - Inline: `spring.config.import=configserver:http://config:8888` - Or leave it empty (`configserver:`) and set `spring.cloud.config.uri=http://config:8888`. The default URI is `http://localhost:8888`. ## Optional import By default, if the location can't be loaded the app **fails to start**. Prefix with `optional:` to tolerate a missing/unreachable server: ``` spring.config.import=optional:configserver:http://localhost:8888 ``` ## Gotcha: this is NOT bootstrap anymore Older tutorials put config in `bootstrap.yml` and rely on a bootstrap context. Since 2.4 that is legacy and off by default. If you see `bootstrap.yml`, the project is either using the legacy mechanism (re-enabled explicitly) or is following outdated docs.

  • What replaced bootstrap.yml, and why was the change made?
    The spring.config.import mechanism (Boot 2.4 / Cloud 2020.0). It removed the need for a separate bootstrap ApplicationContext, unifying remote config loading into Spring Boot's standard ConfigData environment-preparation lifecycle, which is simpler and more predictable.
  • If you set spring.config.import=configserver: with no URL, where does it connect?
    To spring.cloud.config.uri, which defaults to http://localhost:8888.

saying these in an interview costs you the question

  • Claiming you still must use bootstrap.yml in current Spring Cloud versions
  • Thinking the client reads Git directly instead of calling the Config Server over HTTP
  • Forgetting spring-cloud-starter-config is required for the configserver: prefix to work

context

resolving links…