Where to Find the Spring Boot and Spring Cloud Compatibility Matrix

Apr 23, 2026

I was setting up a new Spring Cloud microservices project recently. I added Spring Boot 1.5.2.RELEASE and Spring Cloud Camden.SR5 to my pom.xml, started the application, and boom—NoClassDefFoundError on startup. The error made no sense to me. All the dependencies were there. What went wrong?

The Problem: Version Mismatch

After hours of debugging, I realized the issue: I had mixed incompatible versions of Spring Boot and Spring Cloud. Spring Cloud Camden was designed for Spring Boot 1.4.x, and while SR5 added some 1.5.x support, there were still compatibility issues.

This is a common mistake. The Stack Overflow question about this compatibility matrix has been viewed over 243,000 times. One commenter even said in 2026: “it’s still a bit tedious to find the exact latest matching versions.”

The Solution: Official Compatibility Matrix

The official Spring Boot and Spring Cloud compatibility matrix is available at:

https://spring.io/projects/spring-cloud

Scroll down to the “Release Train Spring Boot Compatibility” section. There you’ll find a table mapping each Spring Cloud release train to compatible Spring Boot versions.

Currently Supported Versions (OSS)

| Spring Cloud Release Train | Spring Boot Version |
|---------------------------|---------------------|
| 2025.1.x (Oakwood)        | 4.0.x               |
| 2025.0.x (Northfields)    | 3.5.x               |
| 2024.0.x (Moorgate)       | 3.4.x               |
| 2023.0.x (Leyton)         | 3.2.x, 3.3.x        |
| 2021.0.x (Jubilee)        | 2.6.x, 2.7.x        |

Enterprise Support Available

| Spring Cloud Release Train | Spring Boot Version |
|---------------------------|---------------------|
| 2022.0.x (Kilburn)        | 3.0.x, 3.1.x        |
| 2020.0.x (Ilford)         | 2.4.x, 2.5.x        |

End of Life Versions

| Spring Cloud Release Train | Spring Boot Version |
|---------------------------|---------------------|
| Hoxton                    | 2.2.x, 2.3.x        |
| Greenwich                 | 2.1.x               |
| Finchley                  | 2.0.x               |
| Edgware/Dalston           | 1.5.x               |
| Camden                    | 1.4.x (SR5+ also 1.5.x) |
| Brixton                   | 1.3.x, 1.4.x        |
| Angel                     | 1.2.x               |

Why Does This Matter?

Spring Cloud is not a single library. It’s a collection of modules: Spring Cloud Netflix (Eureka, Ribbon, Hystrix), Spring Cloud Config, Spring Cloud Gateway, Spring Cloud OpenFeign, and more. Each module has internal dependencies on specific versions of Spring Boot components.

When you mix incompatible versions, you get:

NoClassDefFoundError at startup
ClassNotFoundException for Spring Cloud classes
Weird runtime behavior in production
Hard-to-debug issues in microservices communication

The Correct Configuration

Here’s how I fixed my pom.xml:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>3.2.5</version>
    <relativePath/>
</parent>

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>2023.0.3</version> <!-- Leyton for Boot 3.2.x -->
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

The key is the dependencyManagement section. By importing spring-cloud-dependencies as a BOM (Bill of Materials), all Spring Cloud module versions are automatically managed for you. You don’t need to specify versions for individual Spring Cloud modules.

Understanding the Naming Convention

Spring Cloud release trains are named after London Underground stations, in alphabetical order:

Angel → Brixton → Camden → Dalston → Edgware → Finchley
      → Greenwich → Hoxton → Ilford → Jubilee → Kilburn
      → Leyton → Moorgate → Northfields → Oakwood

This naming convention helps you understand the chronological order. Angel was the first, Oakwood is one of the latest.

The “SR” suffix means “Service Release”—these are patch releases within a major version. Camden.SR5 is the 5th service release of Camden.

Getting the Latest Mappings Programmatically

You can also query the Spring Initializr API for the latest compatibility information:

curl https://start.spring.io/actuator/info | jq '.spring-cloud'

This returns exact version ranges for each Spring Cloud release train, useful for CI/CD scripts or automated setup.

Common Mistakes to Avoid

Ignoring the release train name: Camden sounds similar to Cambridge, but they’re different things
Not checking SR versions: Camden.SR5 has different compatibility than Camden.RELEASE
Assuming backward compatibility: Spring Cloud 2021.0.x doesn’t work with Spring Boot 3.x
Mixing major versions: Spring Boot 2.x with Spring Cloud 2023.0.x will fail

What I Learned

The hard way. I now always check the compatibility matrix before starting any Spring Cloud project. It saves hours of debugging and prevents embarrassing production issues.

The official documentation is your friend:

Final Thoughts

Version compatibility in the Spring ecosystem is critical for microservices. Spring Cloud release trains are tightly coupled to specific Spring Boot versions. When in doubt, check the official matrix at spring.io/projects/spring-cloud or query the Spring Initializr API. It takes 30 seconds and saves hours of frustration.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!