Introduction

A Spring Boot console application is still a normal Spring Boot application. The difference is that it does not start a web server or expose HTTP endpoints. Instead, it boots the Spring context, creates beans, wires dependencies, and then runs command-line logic through components such as CommandLineRunner or ApplicationRunner.

What Boot Still Does for a Console App

Even without a web server, Spring Boot still provides the same core infrastructure:

• dependency injection
• auto-configuration
• externalized configuration
• lifecycle management
• logging and profiles

That means a console app can still use @Configuration, @Service, @Component, @Value, Environment, database access, and all the other Spring features you would expect.

The main difference is which starter dependencies you include and what work you do after the context starts.

A Minimal Console Application

The usual pattern is a main class plus a CommandLineRunner bean.

1import org.springframework.boot.CommandLineRunner;
2import org.springframework.boot.SpringApplication;
3import org.springframework.boot.autoconfigure.SpringBootApplication;
4import org.springframework.context.annotation.Bean;
5
6@SpringBootApplication
7public class DemoApplication {
8
9    public static void main(String[] args) {
10        SpringApplication.run(DemoApplication.class, args);
11    }
12
13    @Bean
14    CommandLineRunner run() {
15        return args -> {
16            System.out.println("Spring Boot console app started");
17            for (String arg : args) {
18                System.out.println("arg = " + arg);
19            }
20        };
21    }
22}

Run it like this:

java -jar app.jar hello world

Spring Boot starts the application context first, and only then invokes the runner with the command-line arguments.

CommandLineRunner Versus ApplicationRunner

Both are valid. The difference is mostly about how arguments are presented.

• 'CommandLineRunner gives you a plain String[]'
• 'ApplicationRunner gives you an ApplicationArguments object with option parsing helpers'

If you want access to option names and non-option arguments separately, ApplicationRunner is often cleaner.

1import org.springframework.boot.ApplicationArguments;
2import org.springframework.boot.ApplicationRunner;
3import org.springframework.context.annotation.Bean;
4
5@Bean
6ApplicationRunner appRunner() {
7    return (ApplicationArguments args) -> {
8        System.out.println(args.getOptionNames());
9        System.out.println(args.getNonOptionArgs());
10    };
11}

This is helpful for batch jobs and CLI tools that accept structured options.

Why No Web Server Starts

A console Spring Boot application usually omits the web starter. Without the servlet or reactive web stack on the classpath, Boot configures a non-web application context.

So while the code still calls SpringApplication.run(...), Boot does not spin up Tomcat or Netty unless the dependencies and application type tell it to do so.

That is why the same framework can power both a command-line job and a REST API. The startup entry point looks similar, but the classpath and configuration drive what gets created.

Typical Use Cases

Console-based Spring Boot apps are a strong fit for:

• scheduled jobs launched externally
• ETL or batch-processing tools
• admin utilities
• one-off data repair tasks
• messaging consumers without an HTTP interface

The advantage is that you keep Spring's configuration and wiring model while shipping a process that behaves like a CLI or batch job rather than a web service.

Exiting Cleanly

A console app does not have to run forever. Some start, do one unit of work, and exit. Others keep running because they listen to queues or polls.

If your app is a short-lived batch process, think about:

• exit codes
• exception handling
• shutdown hooks
• transactional boundaries

Spring Boot supports explicit exit handling through SpringApplication.exit(...) if needed, which is useful when integration with schedulers or shell scripts depends on process status.

Common Pitfalls

The most common mistake is accidentally including a web starter and then wondering why an embedded server appears in a tool that should just run in the console.

Another mistake is putting business logic directly in main instead of letting Spring manage it as beans and runners.

A third pitfall is forgetting that the application context starts before your runner executes, so bean initialization problems can fail the app before any command-line logic begins.

Summary

• A Spring Boot console application is a normal Boot app without the web runtime.
• 'SpringApplication.run(...) still starts the Spring context and dependency injection.'
• Use CommandLineRunner or ApplicationRunner for startup logic.
• Omit web starters unless you actually want an embedded server.
• Console Boot apps are useful for batch jobs, admin tools, and non-HTTP workers.