Spring Boot is an opinionated extension of the Spring Framework that removes boilerplate configuration through auto-configuration, starter dependencies, and an embedded server, so you can build stand-alone, production-ready applications with minimal setup.

Spring Framework requires manual configuration of beans, dispatcher servlets, and XML or Java config. Spring Boot auto-configures sensible defaults based on the classpath, letting you override only what you need. It also bundles an embedded servlet container (Tomcat, Jetty, or Undertow), so apps run as a single executable JAR without deploying to an external server.

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

Spring Boot Starters are curated sets of dependency descriptors that bundle all the libraries needed for a specific feature, such as spring-boot-starter-web for building REST APIs or spring-boot-starter-data-jpa for JPA-based persistence.

Instead of manually resolving compatible versions of many related libraries, a starter pulls in a tested, compatible set with one dependency, reducing version-conflict issues and speeding up project setup. Starters follow the naming convention spring-boot-starter-*, and third-party libraries often publish their own starters following the same pattern.

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

Auto-Configuration automatically configures Spring beans based on the JAR dependencies present on the classpath, existing beans, and property values, removing the need for explicit XML or Java configuration for common setups.

It is triggered by @EnableAutoConfiguration, included inside @SpringBootApplication. Spring Boot scans classes listed in META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports, and each auto-configuration class is guarded by conditional annotations such as @ConditionalOnClass, @ConditionalOnMissingBean, and @ConditionalOnProperty so it only applies when appropriate.

@Configuration
@ConditionalOnClass(DataSource.class)
@ConditionalOnMissingBean(DataSource.class)
public class DataSourceAutoConfiguration {
    // auto-configured bean definitions
}

@SpringBootApplication is a convenience meta-annotation that combines three annotations: @Configuration, which marks the class as a source of bean definitions; @EnableAutoConfiguration, which triggers auto-configuration; and @ComponentScan, which scans the current package and sub-packages for Spring-managed components.

Placing it on the main class means a single annotation sets up configuration, auto-configuration, and component scanning together, which is why the main application class is conventionally placed in the root package.

@SpringBootApplication
// equivalent to:
// @Configuration
// @EnableAutoConfiguration
// @ComponentScan
public class DemoApplication { }

Spring Boot Actuator is a sub-project that adds production-ready features for monitoring and managing an application, exposing operational information through HTTP endpoints or JMX.

It provides built-in endpoints such as /actuator/health for health checks, /actuator/metrics for JVM and application metrics, /actuator/env for environment properties, and /actuator/info for build metadata. Endpoints are individually enabled or disabled through configuration, and sensitive endpoints can be secured with Spring Security.

management.endpoints.web.exposure.include=health,metrics,info
management.endpoint.health.show-details=always

Spring Boot embeds a servlet container directly inside the executable JAR instead of requiring deployment to an external application server.

spring-boot-starter-web pulls in Tomcat by default; the container is auto-configured and started when SpringApplication.run() executes, bound to the port defined by server.port. Because the server is part of the JAR, the app runs with a single java -jar command, simplifying containerization. Switching to Jetty or Undertow only requires excluding the Tomcat starter and adding the alternative starter.

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-web</artifactId>
  <exclusions>
    <exclusion>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-tomcat</artifactId>
    </exclusion>
  </exclusions>
</dependency>
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-undertow</artifactId>
</dependency>

Both files configure a Spring Boot application externally, but application.properties uses flat key=value pairs, while application.yml uses YAML's indentation-based hierarchy, which reads more cleanly for nested and list-based configuration.

YAML also supports multiple profile documents in a single file separated by ---, whereas properties files typically need separate profile-specific files. Functionally they are equivalent and mapped to the same underlying Environment abstraction, so the choice is largely a readability and team-convention preference.

# application.yml
spring:
  datasource:
    url: jdbc:mysql://localhost:3306/db
    username: root

# application.properties
spring.datasource.url=jdbc:mysql://localhost:3306/db
spring.datasource.username=root

Profiles let you define environment-specific beans and configuration, such as separate settings for dev, test, and production, and activate only one set at runtime.

Profile-specific properties live in files like application-dev.properties, and profile-specific beans are marked with @Profile("dev"). The active profile is set through the spring.profiles.active property, an environment variable, or a JVM argument, and Spring Boot merges the profile-specific file over the base application.properties.

@Service
@Profile("dev")
public class MockPaymentService implements PaymentService { }

// activate: --spring.profiles.active=dev

A custom auto-configuration is a @Configuration class registered so Spring Boot picks it up automatically when the library is on the classpath.

It is typically guarded with conditional annotations like @ConditionalOnClass and @ConditionalOnProperty so it only activates when relevant dependencies or properties are present, and its beans are usually paired with @ConditionalOnMissingBean so users can override them. The class is registered by listing its fully qualified name in META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports.

@Configuration
@ConditionalOnClass(MyService.class)
public class MyServiceAutoConfiguration {
    @Bean
    @ConditionalOnMissingBean
    public MyService myService() {
        return new MyServiceImpl();
    }
}

Spring Boot DevTools is a development-time dependency that improves the development workflow through automatic application restarts when code on the classpath changes, LiveReload browser refresh support, and sensible development-time property defaults such as disabled template caching.

Restarts triggered by DevTools use two classloaders so only the changed classes are reloaded, making restarts much faster than a full JVM restart. DevTools is automatically excluded from a production build when packaged with Maven or Gradle, so it never ships to production by default.

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-devtools</artifactId>
  <optional>true</optional>
</dependency>