Introduction

Starting a Spring Boot application with embedded Tomcat does not automatically mean there is a login prompt or a built-in admin account. The answer depends on whether Spring Security is on the classpath and how your application is configured. The important distinction is that Tomcat is the servlet container, while authentication behavior usually comes from Spring Security or your own application code.

Embedded Tomcat Does Not Create App Credentials by Itself

If you run a normal Spring Boot web application with embedded Tomcat and no security configuration, there is no default username and password for your application endpoints.

For example, this application starts an HTTP server, but it does not create any login:

1import org.springframework.boot.SpringApplication;
2import org.springframework.boot.autoconfigure.SpringBootApplication;
3import org.springframework.web.bind.annotation.GetMapping;
4import org.springframework.web.bind.annotation.RestController;
5
6@SpringBootApplication
7public class DemoApplication {
8    public static void main(String[] args) {
9        SpringApplication.run(DemoApplication.class, args);
10    }
11}
12
13@RestController
14class HelloController {
15    @GetMapping("/")
16    String home() {
17        return "ok";
18    }
19}

In this case, Tomcat is just hosting the application. It does not invent application credentials for you.

When Spring Security Is Present

If spring-boot-starter-security is on the classpath and you have not defined your own security setup, Spring Boot creates a default in-memory user.

The default values are:

• username: user
• password: a random generated password printed in the application logs at startup

Typical startup output looks like this:

Using generated security password: 78fa095d-3f4c-48b1-ad50-e24c31d5cf35

That generated password is intended for development only. It gives you a quick way to log in while building the application, but it should not be relied on for production.

A common source of confusion is blaming Tomcat for these credentials. Tomcat is not choosing them. Spring Boot’s security auto-configuration is.

Set an Explicit Username and Password

If you want stable credentials for local development, define them in configuration:

spring.security.user.name=admin
spring.security.user.password=secret123

With those properties, the generated password is replaced by your fixed values.

You can then start the app as usual:

./mvnw spring-boot:run

or

java -jar app.jar

At that point the login prompt, if your routes are protected, expects admin and secret123.

Define Your Own Security Configuration

For anything beyond a demo, you should usually provide your own security rules and users. In modern Spring Security, that often means defining a SecurityFilterChain bean.

1import org.springframework.context.annotation.Bean;
2import org.springframework.context.annotation.Configuration;
3import org.springframework.security.config.Customizer;
4import org.springframework.security.config.annotation.web.builders.HttpSecurity;
5import org.springframework.security.core.userdetails.User;
6import org.springframework.security.core.userdetails.UserDetails;
7import org.springframework.security.provisioning.InMemoryUserDetailsManager;
8import org.springframework.security.web.SecurityFilterChain;
9
10@Configuration
11class SecurityConfig {
12    @Bean
13    SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
14        http
15            .authorizeHttpRequests(auth -> auth
16                .requestMatchers("/public").permitAll()
17                .anyRequest().authenticated()
18            )
19            .httpBasic(Customizer.withDefaults());
20
21        return http.build();
22    }
23
24    @Bean
25    InMemoryUserDetailsManager users() {
26        UserDetails user = User.withUsername("admin")
27            .password("{noop}secret123")
28            .roles("USER")
29            .build();
30
31        return new InMemoryUserDetailsManager(user);
32    }
33}

That replaces the default generated-user behavior with your own application-defined rules.

Do Not Confuse This with Tomcat Manager Credentials

If you deploy a WAR file to a standalone Tomcat server, you may also hear about Tomcat manager credentials stored in tomcat-users.xml. Those credentials are for Tomcat’s administrative applications, not for your Spring Boot application.

That is a different environment from the usual Spring Boot model where Tomcat is embedded inside your executable app.

Common Pitfalls

The most common mistake is assuming embedded Tomcat itself has a default admin login. It does not.

Another mistake is missing the generated Spring Security password in the logs. If logging levels are changed or startup logs scroll past quickly, developers often think the app is broken when the real issue is that the generated password was never copied.

Using the generated password in shared or production environments is also a bad idea. Replace it with explicit configuration or a proper user store.

Finally, make sure you know whether you are dealing with application authentication or Tomcat administration. Those are separate concerns and use different configuration sources.

Summary

• Embedded Tomcat alone does not create a default username and password for your application.
• If Spring Security is on the classpath, Spring Boot creates a default user named user.
• The default password is randomly generated and printed in the startup logs.
• You can override the credentials with spring.security.user.name and spring.security.user.password.
• For real applications, define your own SecurityFilterChain and user management instead of relying on defaults.