Introduction

If bootstrap.yml suddenly stopped affecting your application after upgrading to Spring Cloud 2020.0, the behavior is usually intentional rather than broken. Spring Boot 2.4 introduced a new config data mechanism, and Spring Cloud 2020.0 moved toward that model instead of always creating the old bootstrap context automatically.

Why bootstrap.yml stopped being processed

In older Spring Cloud releases, bootstrap.yml was read in a separate bootstrap phase before the main application context started. That early phase was useful for settings such as Config Server connection details, encrypted property support, and remote property sources that had to exist before normal bean creation.

Spring Boot 2.4 changed configuration loading through the Config Data API. Spring Cloud 2020.0 followed that direction, so simply dropping a bootstrap.yml file into the project is no longer enough in many setups. The most visible symptom is that values from Config Server, Vault, or similar sources never appear, even though the file still exists and looks correct.

The practical rule is simple: if your application depends on remote configuration, express that dependency explicitly through spring.config.import, or opt back into legacy bootstrap behavior on purpose.

Migrate to spring.config.import

For most applications, the cleanest fix is to move the important startup settings into application.yml and declare the remote source there. A small working example for Spring Cloud Config looks like this:

1spring:
2  application:
3    name: billing-service
4  config:
5    import: "optional:configserver:"
6  cloud:
7    config:
8      uri: http://localhost:8888
9      fail-fast: true

This tells Spring Boot to import configuration from a Config Server during config data processing. The optional: prefix means startup may continue if the server is unavailable. If remote config is required in every environment, remove optional: so the application fails early and loudly.

A matching config repository file could look like this:

1feature:
2  invoices:
3    enabled: true
4service:
5  timeout-seconds: 15

When billing-service starts, Spring Cloud requests the remote properties for that application name and merges them into the environment. That makes the startup order explicit, which is the main reason the new model is easier to reason about than the old implicit bootstrap phase.

When legacy bootstrap mode still makes sense

Some older integrations still expect the bootstrap context. If you are working in a codebase that was built around that model and a quick migration is not realistic, you can restore the older behavior with the bootstrap starter:

1<dependency>
2  <groupId>org.springframework.cloud</groupId>
3  <artifactId>spring-cloud-starter-bootstrap</artifactId>
4</dependency>

Then a legacy bootstrap.yml can still hold early properties:

1spring:
2  application:
3    name: billing-service
4  cloud:
5    config:
6      uri: http://localhost:8888

This is useful as a compatibility step, but it should usually be treated as a bridge rather than the long-term design. Newer Spring Cloud applications are easier to maintain when the import flow is visible in application.yml instead of hidden in a bootstrap phase that only some team members remember.

Common Pitfalls

The most common mistake is leaving spring.cloud.config.uri in bootstrap.yml and expecting Spring Cloud 2020.0 to discover it automatically. If you do not explicitly enable bootstrap mode or add spring.config.import, the remote source may never be contacted.

Another frequent issue is putting spring.config.import in the wrong file. If the import itself controls whether a remote source gets loaded, it belongs in a configuration file that is already part of the normal startup path, usually application.yml.

Teams also get tripped up by optional:configserver:. It is convenient for local development, but it can hide real deployment problems because the service starts with defaults when the Config Server is down. Use it deliberately, not by habit.

Finally, do not assume property precedence stayed identical after the migration. If local overrides, profile files, and remote properties interact in surprising ways, check the effective environment through actuator endpoints or startup logs rather than guessing.

Summary

• Spring Cloud 2020.0 no longer assumes the old bootstrap.yml processing model in many setups.
• The preferred modern fix is to use spring.config.import in application.yml.
• Add spring-cloud-starter-bootstrap only when you intentionally want legacy bootstrap behavior.
• 'optional:configserver: changes failure behavior, so choose it based on operational needs.'
• If values still look wrong, inspect final property precedence instead of focusing only on file presence.