Introduction

A Spring Boot application starts by building a Spring ApplicationContext, discovering configuration, and then applying a large set of conditional auto-configuration rules. What makes Boot feel “automatic” is not magic. It is a carefully ordered bootstrap sequence around SpringApplication, component scanning, external configuration, and classpath-driven configuration conditions.

The Entry Point: SpringApplication.run

A typical Spring Boot program starts with a main class like this:

1import org.springframework.boot.SpringApplication;
2import org.springframework.boot.autoconfigure.SpringBootApplication;
3
4@SpringBootApplication
5public class DemoApplication {
6    public static void main(String[] args) {
7        SpringApplication.run(DemoApplication.class, args);
8    }
9}

That single run call does a lot of work:

• prepares the application environment
• creates the application context
• loads bean definitions
• refreshes the context
• starts the embedded server if it is a web application
• invokes startup callbacks such as runners

Boot compresses a long startup process into one convenient entry point.

What @SpringBootApplication Really Means

@SpringBootApplication is a composed annotation. Conceptually, it combines:

• '@Configuration'
• '@EnableAutoConfiguration'
• '@ComponentScan'

That means your main class is simultaneously:

• a source of bean definitions
• a trigger for Boot’s auto-configuration machinery
• the root package for component scanning

This is why package structure matters. Classes placed under the main application package are much easier for Boot to discover automatically.

Environment and Configuration Loading

Before beans are created, Spring Boot prepares an Environment object. This is where application properties, YAML files, system properties, environment variables, and command-line arguments are merged into a unified configuration model.

Example configuration:

server.port=9090
spring.application.name=demo-app

A bean can then consume those values:

1import org.springframework.beans.factory.annotation.Value;
2import org.springframework.stereotype.Component;
3
4@Component
5public class AppInfo {
6    public AppInfo(@Value("${spring.application.name}") String name) {
7        System.out.println(name);
8    }
9}

The important internal point is that configuration is assembled before most beans are instantiated, so property injection and conditional logic can depend on it.

Auto-Configuration Is Conditional Bean Registration

Boot’s most famous feature is auto-configuration. Internally, this means Boot imports many configuration classes and activates only the ones whose conditions match the current application.

Typical conditions include:

• a certain class exists on the classpath
• a bean of a given type is missing or already present
• a property has a certain value
• the app is running in a web environment

For example, if a web starter is present, Boot can configure MVC infrastructure and an embedded servlet container. If a data source library is present, Boot can configure database-related beans.

This is why adding or removing dependencies changes behavior without changing much application code.

Bean Creation Still Belongs to Spring Core

Spring Boot does not replace Spring’s IoC container. It builds on top of it. Once configuration classes and component scans have registered bean definitions, the underlying Spring container still manages:

• bean instantiation
• dependency injection
• lifecycle callbacks
• proxy creation for features such as transactions

Example:

1import org.springframework.stereotype.Service;
2
3@Service
4public class GreetingService {
5    public String greet() {
6        return "hello";
7    }
8}

Boot makes this easy to discover and wire, but the actual dependency injection model is still standard Spring.

Embedded Server Startup

If the app is a web application, Boot creates the appropriate type of application context and starts an embedded server such as Tomcat, Jetty, or Undertow.

That is why a Boot web app can be launched with java -jar instead of being deployed manually to an external servlet container.

From the developer’s point of view, the server “just starts.” Internally, the web server bean is created during context refresh, and its lifecycle is tied to the application context lifecycle.

Startup Callbacks and Ready State

After the context is refreshed and the application is mostly initialized, Boot runs startup callbacks such as CommandLineRunner and ApplicationRunner.

1import org.springframework.boot.CommandLineRunner;
2import org.springframework.stereotype.Component;
3
4@Component
5public class StartupRunner implements CommandLineRunner {
6    @Override
7    public void run(String... args) {
8        System.out.println("Application started");
9    }
10}

These hooks run after the container is ready enough to execute application startup logic, which is why they are often used for warmup, sanity checks, or initialization tasks.

Common Pitfalls

The most common mistake is thinking Spring Boot “does everything automatically” without understanding that its behavior is driven by classpath contents, properties, and conditional configuration. Another is placing components outside the scanned package structure and then assuming Boot failed randomly. Developers also often confuse Spring Boot auto-configuration with ordinary Spring dependency injection, even though Boot mainly orchestrates setup while the core container still creates and wires beans. A final issue is forgetting that changes to dependencies can activate or disable auto-configurations because the startup process is intentionally classpath-sensitive.

Summary

• Spring Boot starts through SpringApplication.run, which orchestrates the bootstrap sequence.
• '@SpringBootApplication combines configuration, auto-configuration, and component scanning.'
• Boot prepares the environment before most bean creation begins.
• Auto-configuration is conditional bean registration based on classpath, properties, and existing beans.
• The underlying IoC container and lifecycle rules are still standard Spring, with Boot providing an opinionated startup layer on top.