Understanding Spring Boot Starters
Learn the spring-boot-starter-* naming convention, what is actually inside a starter, and how starters remove manual version management from your project.
Introduction
If you have looked at any Spring Boot pom.xml, you have seen dependencies named `spring-boot-starter-something`. These "starters" are the single most common type of dependency you will add to a Spring Boot project, and understanding what they actually are demystifies a lot of what feels like magic.
The Naming Convention
Every official Spring Boot starter follows the pattern `spring-boot-starter-*`, where the suffix describes the capability it adds: `spring-boot-starter-web` for web applications, `spring-boot-starter-data-jpa` for JPA-based persistence, `spring-boot-starter-security` for security, and so on. Third-party starters published by other projects often follow the inverse pattern, `*-spring-boot-starter` (for example, `mybatis-spring-boot-starter`), as a convention to distinguish "official" from "community" starters.
What Is Actually Inside a Starter
This is the key insight: a starter contains no code of its own. It is a POM (Project Object Model) file — just a list of other dependencies, grouped together because they are commonly needed together. Adding `spring-boot-starter-web` does not add "starter code"; it transitively pulls in Spring MVC, an embedded Tomcat server, Jackson for JSON, and validation support, because those are the libraries a typical web application needs.
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId></dependency>Click Run to see what this code prints.
Nearly every starter transitively includes the base `spring-boot-starter`, which itself brings in core auto-configuration support, Spring's core container, and a logging implementation (Logback by default). That is why even the smallest Spring Boot project already has structured logging working out of the box.
Common Starters Overview
| Starter | What It Is For |
|---|---|
| spring-boot-starter-web | Building REST APIs and web apps with Spring MVC and embedded Tomcat. |
| spring-boot-starter-webflux | Reactive, non-blocking web applications built on Project Reactor. |
| spring-boot-starter-data-jpa | ORM-based database access using Spring Data JPA and Hibernate. |
| spring-boot-starter-jdbc | Lower-level, direct JDBC access via JdbcTemplate. |
| spring-boot-starter-security | Authentication and authorization for web applications. |
| spring-boot-starter-test | Testing support: JUnit 5, Mockito, AssertJ, Spring Test. |
| spring-boot-starter-validation | Bean Validation (Jakarta Validation) support, e.g. @NotNull, @Size. |
| spring-boot-starter-actuator | Production-ready monitoring endpoints: health checks, metrics, info. |
Version Management via the Parent POM
Notice none of the examples above specify a `<version>` tag. That is intentional, and it is one of the biggest practical benefits of starters. A Spring Boot project typically inherits from the `spring-boot-starter-parent` POM (or imports the equivalent BOM), which centrally defines a tested, compatible version for every starter and its transitive dependencies.
<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>3.2.0</version></parent>Because the parent POM pins compatible versions for you, upgrading your entire dependency set is often just a matter of bumping the single `spring-boot-starter-parent` version — no need to manually chase down compatible versions for a dozen individual libraries.
Common Mistakes
- Manually pinning a version on a starter dependency, which can silently break the version compatibility the parent POM was managing for you.
- Assuming a starter itself contains business logic — it is only a dependency aggregator, all real functionality comes from the libraries it pulls in.
- Adding multiple overlapping starters (e.g. both -web and -webflux) without understanding they configure competing embedded servers.
Best Practices
- Always check the official Spring Boot starters list before assembling dependencies manually.
- Let the parent POM (or BOM) manage versions; only override a version when you have a specific, documented reason to.
- Use `mvn dependency:tree` to see exactly what a starter pulled in transitively when debugging classpath issues.
Frequently Asked Questions
No. A starter is purely a POM file listing other dependencies. All actual functionality comes from the libraries it transitively pulls in.
Yes. Organizations commonly build internal starters that bundle their own commonly reused configuration and dependencies, following the same *-spring-boot-starter convention as third-party starters.
You can instead import spring-boot-dependencies as a BOM inside <dependencyManagement>, which gives the same version management without requiring your project to inherit from a parent.
Key Takeaways
- A starter follows the spring-boot-starter-* naming pattern and contains no code — only a curated list of transitive dependencies.
- Starters remove the need to individually pick and version-match a dozen related libraries.
- The spring-boot-starter-parent POM (or its BOM) centrally manages compatible versions for every official starter.
Summary
Starters are the backbone of Spring Boot dependency management: bundles of related libraries with centrally managed, compatible versions. Next, you will see how Spring Boot actually reacts to the dependencies (and starters) you add through auto-configuration.