Spring Boot: Production-Ready Spring Applications

What Spring Boot is

Spring Boot is the Spring team's opinionated way to build stand-alone, production-grade applications on the Spring platform. The repository README describes the goal as helping you create Spring-powered applications and services "with absolute minimum fuss", by taking an opinionated view of the Spring platform and third-party libraries so that new and existing users can get to the parts they need quickly. The reference documentation adds that most Spring Boot applications need very little Spring configuration.

The result is a Java application that you can start with java -jar, or package as a more traditional WAR for deployment to a servlet container. The project lists four primary goals:

• A much faster and widely accessible getting-started experience for all Spring development.
• Being opinionated out of the box, but getting out of the way quickly as requirements diverge from the defaults.
• A range of non-functional features common to large classes of projects, such as embedded servers, security, metrics, health checks and externalized configuration.
• No code generation (when not targeting native image) and no requirement for XML configuration.

The audience is Java developers building web applications, REST APIs, batch jobs and services on Spring Framework, and platform teams who want a consistent, supported set of dependencies and operational endpoints across many services. Spring Boot builds on many other Spring projects, so the docs point newcomers to the guides on spring.io for the Spring basics. The code lives at github.com/spring-projects/spring-boot under the Apache-2.0 licence.

How Spring Boot works

Starters and dependency management

Every Spring Boot release ships a curated list of dependencies that it supports, published as a standard bill of materials called spring-boot-dependencies. You normally do not give versions for these libraries in your build; Spring Boot manages them, and when you upgrade Spring Boot the whole set moves together in a consistent way. You can still override a version when you need to, but the docs warn that each release is tied to a base version of Spring Framework and "highly" recommend not specifying that version yourself.

On top of the BOM sit starters: dependency descriptors that pull in everything needed for a particular kind of application. Adding spring-boot-starter-data-jpa, for example, brings in Spring and JPA for database access with a consistent set of managed transitive dependencies. Official starters follow the spring-boot-starter-* naming pattern, and the docs reserve the spring-boot prefix for official artifacts, so a third-party starter should be named like thirdpartyproject-spring-boot-starter. Beyond application starters there are production starters (for Actuator) and technical starters for swapping facets such as the web server or logging system.

Auto-configuration

Auto-configuration is the core mechanism. Spring Boot tries to configure your application based on the jars on the classpath: if HSQLDB is present and you have not defined any database connection beans, for instance, it configures an in-memory database. You opt in by adding @SpringBootApplication or @EnableAutoConfiguration to one @Configuration class, ideally your primary one. @SpringBootApplication is a meta-annotation that combines @SpringBootConfiguration, @EnableAutoConfiguration and @ComponentScan.

Under the hood, auto-configuration classes are annotated with @AutoConfiguration (itself meta-annotated with @Configuration) and listed in a META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports file in the jar that provides them. They are guarded by conditions, usually @ConditionalOnClass and @ConditionalOnMissingBean, so they only apply when the relevant classes are present and you have not declared your own beans. That is why the docs call auto-configuration non-invasive: define your own DataSource bean and the embedded database support backs away. Start the application with the --debug switch to log a conditions report showing what was applied and why, and use the exclude or excludeName attributes, or the spring.autoconfigure.exclude property, to switch specific auto-configurations off. Libraries can ship their own auto-configuration and starters using the same mechanism.

Externalized configuration

Spring Boot lets the same code run in different environments by reading configuration from properties files, YAML files, environment variables, command-line arguments and more. Values can be injected with @Value, read through the Environment abstraction, or bound to structured objects with @ConfigurationProperties. Sources follow a documented precedence order in which later sources override earlier ones; command-line arguments, for example, override application.properties, and an application.properties outside the packaged jar overrides one inside it. Profile-specific files such as application-{profile}.properties slot into the same order. For environments where property names are awkward, a whole block of properties can be passed as JSON:

$ SPRING_APPLICATION_JSON='{"my":{"name":"test"}}' java -jar myapp.jar

Executable jars and embedded servers

Java has no standard way to load jars nested inside another jar. Rather than flattening every dependency into one "uber jar", Spring Boot's spring-boot-loader modules let it nest dependency jars directly inside an executable jar or war. The Maven and Gradle plugins produce these archives automatically. The application embeds its web server: the system requirements page lists Tomcat 11.0.x and Jetty 12.1.x as supported embedded servlet containers (Servlet 6.1), and you can also deploy to any Servlet 6.1+ compatible container.

Key features

• Curated dependency management. The spring-boot-dependencies BOM and the spring-boot-starter-parent POM remove most version management from your build.
• Starters. Single dependencies such as spring-boot-starter-webmvc or spring-boot-starter-actuator pull in a supported set of libraries for a given job.
• Conditional auto-configuration. Sensible defaults based on the classpath, which back off as soon as you define your own beans.
• Externalized configuration. Properties and YAML files, profiles, environment variables, JSON blocks and command-line overrides with a documented precedence order, plus type-safe @ConfigurationProperties binding.
• Actuator. Production-ready endpoints for health, metrics, loggers, environment, beans, mappings, thread dumps, heap dumps, Prometheus scraping and more, exposed over HTTP or JMX.
• Executable jars and efficient deployment. Nested-jar executables, plus a tools jar mode that extracts the application into a layout the docs describe as AOT cache and CDS friendly.
• Container images. Built-in Cloud Native Buildpacks support in the Maven and Gradle plugins, producing Docker-compatible images with a single command.
• GraalVM native images. Spring ahead-of-time (AOT) processing generates source code, proxies and GraalVM hint files so applications can be compiled into native executables.
• Developer tools. The spring-boot-devtools module adds automatic restart when classpath files change and development-friendly property defaults, such as disabled template caching.
• Spring Boot CLI. A command-line tool that can bootstrap a new project from start.spring.io or encode a password.

Getting started

Spring Boot needs Java 17 or later; the system requirements page says it is compatible with versions up to and including Java 27. Explicit build support covers Maven 3.6.3 or later and Gradle 8.x (8.14 or later) and 9.x. Check your Java installation first:

$ java -version

The quickest route, according to the tutorial, is to generate a project at start.spring.io with the "Web" starter. If you build the project by hand with Maven, inherit from spring-boot-starter-parent and add the web starter:

<dependencies>
	<dependency>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-webmvc</artifactId>
	</dependency>
</dependencies>

With Gradle, apply the org.springframework.boot and io.spring.dependency-management plugins and declare:

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-webmvc'
}

The README's teaser shows a complete application in one Java class:

@RestController
@SpringBootApplication
public class Example {

	@RequestMapping("/")
	String home() {
		return "Hello World!";
	}

	public static void main(String[] args) {
		SpringApplication.run(Example.class, args);
	}

}

Run it with the build plugin's goal, either mvn spring-boot:run or gradle bootRun, and open http://localhost:8080:

$ mvn spring-boot:run
$ gradle bootRun

To package a self-contained executable jar, add spring-boot-maven-plugin to the POM and run mvn package (or run gradle bootJar), then start it with plain Java. The tutorial notes the resulting jar is around 18 MB:

$ java -jar target/myproject-0.0.1-SNAPSHOT.jar

The Spring Boot CLI is optional. It can be installed with SDKMAN!, Homebrew, MacPorts or Scoop, or from a downloaded archive. With Homebrew:

$ brew tap spring-io/tap
$ brew install spring-boot

To add production endpoints, include the Actuator starter:

<dependency>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-actuator</artifactId>
	</dependency>

For production, the efficient deployments page recommends running from an extracted layout rather than the nested jar, because loading classes from nested jars has a small startup cost:

$ java -Djarmode=tools -jar my-app.jar extract
$ java -jar my-app/my-app.jar

To build a native executable with GraalVM Native Build Tools, or a native container image with buildpacks, the native image how-to uses:

$ mvn -Pnative native:compile
$ gradle nativeCompile
$ mvn -Pnative spring-boot:build-image
$ gradle bootBuildImage

Building Spring Boot itself from source is not required to use it; the README says it uses the Gradle wrapper and needs JDK 25:

$ ./gradlew publishToMavenLocal

Use cases

• REST APIs and web applications. The web starter brings in Spring MVC and embedded Tomcat, so a service is a single class plus a build file, runnable with java -jar.
• Fleets of microservices. A shared BOM, consistent starters and the same externalized configuration model make services look alike, and Actuator gives each one health, metrics and logger endpoints that monitoring systems such as Prometheus can scrape.
• Containerized deployment. Buildpacks support in the Maven and Gradle plugins turns an application into a Docker-compatible image without writing a Dockerfile, and the extracted jar layout suits container images and AOT caching.
• Fast-starting and serverless workloads. The native image docs say GraalVM native images generally have a smaller memory footprint and start faster than their JVM counterparts, and are especially interesting for container deployments and function-as-a-service platforms.
• Shared internal libraries. Platform teams can publish their own auto-configuration and custom starters so that adding one dependency wires up company-standard clients, security or observability with overridable defaults.

How Spring Boot compares

The comparison the documentation itself draws is with plain Spring Framework. Spring Boot does not replace Spring; it builds on it, adding dependency curation, auto-configuration, embedded servers and production features so that you write less configuration. The Spring MVC annotations in the tutorial, such as @RestController and @RequestMapping, are Spring Framework annotations rather than Spring Boot ones. Choosing Spring Boot is therefore mostly a choice of the Spring programming model plus Boot's conventions on top of it.

The docs also contrast Spring Boot's nested executable jars with the common uber-jar approach, which flattens all classes into one archive and makes it hard to see which libraries an application contains or to cope with clashing file names. Native image support is positioned as an alternative deployment mode rather than a default: you trade the dynamic runtime behaviour that auto-configuration normally relies on for faster startup and lower memory use. For other Java frameworks in the same space, compare on your own workloads; the Spring Boot documentation does not publish head-to-head benchmarks.

Things to know before adopting

• Java and toolchain baseline. Spring Boot requires at least Java 17 and a matching Spring Framework version, and third-party integrations may have higher requirements. Maven 3.6.3+ and Gradle 8.14+ or 9.x are the supported build tools; other build systems such as Ant can work but are "not particularly well supported". Building native container images with buildpacks requires at least JDK 25, and building Spring Boot from source requires JDK 25.
• Actuator endpoints can leak sensitive data. By default only the health endpoint is exposed over HTTP and JMX, and access to every endpoint except shutdown and heapdump is unrestricted once exposed. The docs warn that endpoints may contain sensitive information and that, before widening management.endpoints.web.exposure.include, you should make sure exposed endpoints carry no sensitive data, sit behind a firewall, or are secured with something like Spring Security. Values from /env, /configprops and /quartz are fully sanitized by default.
• Security auto-configuration backs off completely. With Spring Security on the classpath and no custom SecurityFilterChain, all actuators other than /health are secured automatically. As soon as you define any SecurityFilterChain bean, that auto-configuration backs off entirely, so you must write rules for both the actuator endpoints and the rest of the application. CSRF protection stays on by default, so actuator endpoints that need POST, PUT or DELETE return 403 under the default security configuration.
• Be careful with "*" exposure. Exposing all endpoints is a single property, shown in the docs for applications deployed behind a firewall. The exclude list takes precedence over include, and * must be quoted in YAML:

  management:
    endpoints:
      web:
        exposure:
          include: "*"
          exclude: "env,beans"

• Devtools is for development only. Developer tools are disabled automatically when the application is launched with java -jar, and repackaged archives exclude them by default. Forcing them on with -Dspring.devtools.restart.enabled=true "must not be done in a production environment where running devtools is a security risk". Remote devtools support is opt-in for the same reason and is not supported for Spring WebFlux. Devtools' two-classloader restart can also cause classloading issues, particularly in multi-module projects, and the LiveReload feature is deprecated as of Spring Boot 4.1.0 with no replacement.
• Native images impose a closed world. The classpath is fixed at build time, unreachable code is removed, GraalVM must be told about reflection, resources, serialization and dynamic proxies, and there is no lazy class loading. Spring AOT adds further limits: beans cannot change at runtime, profiles and profile-specific configuration have limitations, and properties that decide whether a bean is created, such as @ConditionalOnProperty and .enabled properties, are not supported. On macOS the docs recommend giving Docker at least 8GB of memory for native builds.
• Treat auto-configuration internals as private. Auto-configuration classes are public, but the docs state that only the class name, which you use to exclude it, counts as public API. Do not call their nested configuration classes or bean methods directly.
• Upgrades rename properties. Feature releases may rename or remove configuration properties. The spring-boot-properties-migrator runtime dependency reports, and temporarily migrates, such properties at startup, but it ignores properties added late (for example through @PropertySource) and should be removed once migration is done. Upgrade instructions live in the release notes on the project wiki, with migration guides for moves from 1.x, 2.x and 3.x; if you skip releases, read the notes for each version you jump.
• Buildpacks can alter file metadata. For reproducible builds and caching, buildpacks may change resource metadata such as last-modified times, so applications should not rely on that information at runtime.

Project activity

As of November 2026 the repository has about 81,800 stars and more than 43,000 forks. It was created in October 2012, is written mainly in Java and is licensed under Apache-2.0. The documentation itself is open source and lives in the same repository, and the project tracks bugs and feature requests with GitHub issues and monitors Stack Overflow questions tagged spring-boot.

Source code and issues are at github.com/spring-projects/spring-boot, the project page is at spring.io/projects/spring-boot, and the reference documentation is published at docs.spring.io/spring-boot.

[![Featured on TechLogHub](https://techloghub.com/badge-neutral.svg)](https://techloghub.com/open-source/spring-boot?utm_source=techloghub_badge&utm_medium=referral&utm_campaign=readme)