This version is still in development and is not considered stable yet. For the latest stable version, please use Spring Cloud Config 5.0.4!

Embedding the Config Server

The Config Server runs best as a standalone application. However, if need be, you can embed it in another application. To do so, use the @EnableConfigServer annotation. An optional property named spring.cloud.config.server.bootstrap can be useful in this case. It is a flag to indicate whether the server should configure itself from its own remote repository. By default, the flag is off, because it can delay startup. However, when embedded in another application, it makes sense to initialize the same way as any other application. When setting spring.cloud.config.server.bootstrap to true you must also use a composite environment repository configuration. For example

spring:
  application:
    name: configserver
  profiles:
    active: composite
  cloud:
    config:
      server:
        composite:
          - type: native
            search-locations: ${HOME}/Desktop/config
        bootstrap: true

If you use the bootstrap flag, the config server needs to have its name and repository URI configured in bootstrap.yml.

To change the location of the server endpoints, you can (optionally) set spring.cloud.config.server.prefix (for example, /config), to serve the resources under a prefix. The prefix should start but not end with a /. It is applied to the @RequestMappings in the Config Server (that is, underneath the Spring Boot server.servletPath and server.contextPath prefixes).

If you want to read the configuration for an application directly from the backend repository (instead of from the config server), you basically want an embedded config server with no endpoints. You can switch off the endpoints entirely by not using the @EnableConfigServer annotation (set spring.cloud.config.server.bootstrap=true).

Embedded vs. Standalone: Choosing the Right Deployment Model

The choice between embedding the Config Server and running it as a standalone service depends on the scale and security requirements of your architecture. The following table summarizes the key trade-offs:

Concern	Embedded Config Server	Standalone Config Server
Operational overhead	None — no additional service to deploy or monitor	Requires deploying, operating, and monitoring a dedicated service
Git credentials	Every application that embeds the server must hold its own Git credentials (SSH keys or username/password)	Credentials are held in one place; client applications need only the Config Server URL
Encryption keys	Every application holds its own encryption/decryption keys	Keys are managed centrally on the Config Server
Configuration drift	Each embedding application may run a slightly different version or configuration of the server	Centralized control ensures all clients see the same configuration
High availability	HA falls on each application; no shared point of failure	The Config Server itself becomes a shared point of failure (mitigated by clustering or multiple instances)
Network round-trips	Zero — configuration is resolved in-process	Adds a network call per startup (and per refresh)
Security isolation	Each application has access to all configurations held in its repository; no per-application access control at the server layer	The standalone server can enforce per-application access control (see Security)
Suitable for	Single-application or monolith deployments, local development, or cases where reducing operational overhead outweighs centralization benefits	Microservice environments with many applications that share configuration, strict security requirements, or centralized secrets management

Concern

Embedded Config Server

Standalone Config Server

Operational overhead

None — no additional service to deploy or monitor

Requires deploying, operating, and monitoring a dedicated service

Git credentials

Every application that embeds the server must hold its own Git credentials (SSH keys or username/password)

Credentials are held in one place; client applications need only the Config Server URL

Encryption keys

Every application holds its own encryption/decryption keys

Keys are managed centrally on the Config Server

Configuration drift

Each embedding application may run a slightly different version or configuration of the server

Centralized control ensures all clients see the same configuration

High availability

HA falls on each application; no shared point of failure

The Config Server itself becomes a shared point of failure (mitigated by clustering or multiple instances)

Network round-trips

Zero — configuration is resolved in-process

Adds a network call per startup (and per refresh)

Security isolation

Each application has access to all configurations held in its repository; no per-application access control at the server layer

The standalone server can enforce per-application access control (see Security)

Suitable for

Single-application or monolith deployments, local development, or cases where reducing operational overhead outweighs centralization benefits

Microservice environments with many applications that share configuration, strict security requirements, or centralized secrets management

When embedding the Config Server in a multi-application environment (for example, if each microservice embeds its own Config Server), each application independently connects to the Git repository. This means each application must possess valid Git credentials and encryption keys, which can complicate secret rotation and auditing.