Externalized Configuration

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.

{cipher} marks a property value as encrypted at rest in the config repo. By default the Config Server decrypts it and sends the plain value to the client, so the secret never sits in git as plaintext.

Spring Cloud Kubernetes reads a Kubernetes ConfigMap (named after your app) and adds its key/value entries to the Spring Environment as a PropertySource, so @Value and @ConfigurationProperties see them like any other property.

@RefreshScope marks a bean so it can pick up new configuration at runtime. Calling POST /actuator/refresh reloads the configuration and recreates those beans, so they see the new property values without restarting the app.

It 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.

Spring Cloud Vault reads secrets from HashiCorp Vault at startup and adds them to Spring's Environment as a property source, so @Value and @ConfigurationProperties inject them just like application.yml values.

The instance you call publishes a RefreshRemoteApplicationEvent onto the shared broker topic. Every instance on the Bus receives it and does a local refresh — re-reading config and rebinding @RefreshScope / @ConfigurationProperties beans, exactly like calling /actuator/refresh on each one.

fail-fast=true makes the app refuse to start if it cannot reach the Config Server. Adding spring-retry and Spring AOP lets it retry the connection a few times (with backoff) before giving up, controlled by spring.cloud.config.retry.* properties.

@ConfigurationProperties beans are automatically rebound with new values on refresh, no annotation needed. A bean using @Value only picks up new values if you also put @RefreshScope on it.

application is the client's spring.application.name, profile is its active profile(s), and label is the git branch/tag (defaults to main). The server maps these to files like {application}-{profile}.yml on that branch and returns their merged properties.

Enable spring.cloud.kubernetes.reload.enabled=true. In event (watch) mode it watches ConfigMaps/Secrets via the Kubernetes API and reacts instantly; in polling mode it re-reads them on a fixed period. A detected change fires a refresh that rebinds beans.

Dynamic secrets come with a lease (a TTL). A SecretLeaseContainer renews the lease before it expires and, when it can't renew, requests fresh secrets (rotation). To use rotated values, your beans must be in @RefreshScope so they're recreated with the new values.

Add one broker starter — spring-cloud-starter-bus-amqp (RabbitMQ) or spring-cloud-starter-bus-kafka — plus Actuator, point the app at a running broker, and expose the endpoint with management.endpoints.web.exposure.include=busrefresh. Then POST /actuator/busrefresh.

POST the plaintext to the Config Server's /encrypt endpoint; it returns ciphertext. You paste that into the repo prefixed with {cipher}. POST ciphertext to /decrypt to reverse it. Both need a configured key.

It contributes a Secrets PropertySource so Secret keys become Spring properties. Secret values are base64-decoded automatically. Reading Secrets via the Kubernetes API is opt-in (enableApi); by default it reads Secrets from mounted file paths.

Common backends are git (default, versioned), native (files on the classpath or filesystem, handy for local dev), and Vault (secrets). Git needs spring.cloud.config.server.git.uri; native is enabled with the 'native' profile and search-locations.

KV v1 stores a single current value per key; KV v2 adds versioning (history, soft-delete) and uses a different read path with a /data/ segment. Spring Cloud Vault handles the path difference when you set the backend version.

The Bus doesn't talk to the broker directly — it rides on Spring Cloud Stream, publishing to a shared destination called springCloudBus. To broadcast (not load-balance) it gives each instance a distinct identity (spring.cloud.bus.id) so every instance receives its own copy of the event.

Old versions created a separate 'bootstrap' application context from bootstrap.yml to fetch config before the main app. Since Spring Boot 2.4 that's replaced by spring.config.import handled inside the normal startup. To use the old way you add spring-cloud-starter-bootstrap or set spring.cloud.bootstrap.enabled=true.

By default the Config Server's properties take precedence over the client's local application.yml, so central config overrides local defaults. You can flip this with flags like spring.cloud.config.override-none=true so local values win instead.

Set spring.cloud.config.server.encrypt.enabled=false on the server so it passes {cipher} values through untouched. Each client must then hold the key and decrypt them itself. You'd do this so plaintext secrets never leave the client boundary or transit the network.

Symmetric uses a single shared secret in encrypt.key — simple but the same key encrypts and decrypts. An RSA keystore uses a public/private key pair (encrypt.keyStore.*) so encryption and decryption can be separated, giving stronger, more manageable at-rest protection.

The reload watcher detects the ConfigMap change and publishes a RefreshEvent. Spring Cloud's ContextRefresher rebuilds the Environment, re-binds @ConfigurationProperties beans, and destroys @RefreshScope beans so they are recreated with the new values on next use.

First the Environment is reloaded and an EnvironmentChangeEvent is published carrying the set of changed property keys. Then the refresh scope is cleared and a RefreshScopeRefreshedEvent is published to signal that refresh-scoped beans were evicted.

A refresh evicts the bean but recreation is lazy, so a request already running keeps the old instance. On recreation, the old bean's @PreDestroy runs and the new bean's @PostConstruct runs again. Beans that open connections or pools get torn down and rebuilt, which can be costly.

EnvironmentRepository is the interface every Config Server backend implements. Its findOne(application, profile, label) method reads the backend and returns an Environment object holding an ordered list of PropertySources for that app/profile/label, which the client merges.

Profiles pick which -{profile} files to include and how they layer (more specific wins over shared/base files). The label selects the git branch/tag/commit to read from; if the client sends none, the server's default-label (main, historically master) is used.

Vault's database engine generates a unique, short-lived DB username/password per request. Spring Cloud Vault reads database/creds/<role> and exposes them as spring.datasource.username/password, so your DataSource connects with generated credentials that Vault renews or rotates via leases.

Enable reload with event+refresh for fast, zero-downtime changes to refresh-safe values, scope watches to each app's own ConfigMap/Secret with least-privilege RBAC, and use restart_context/shutdown (with replicas + probes) for structural changes. Guard against instant bad config with validation and rollout controls.