Introduction

A MongoSocketOpenException at Spring Boot startup usually means some Mongo-related auto-configuration is still active and is trying to create a client or repository bean. Excluding only MongoAutoConfiguration is often not enough because Spring Boot can also enable data and reactive Mongo auto-configuration depending on the dependencies on your classpath.

Why One Exclusion Often Fails

Spring Boot does not treat Mongo support as one single switch. A project may activate multiple configuration paths:

• core Mongo client configuration
• Mongo data configuration
• Mongo repositories
• reactive Mongo configuration

So this can still be incomplete:

1@SpringBootApplication(
2    exclude = [MongoAutoConfiguration::class]
3)
4class ApiApplication

If a second Mongo configuration path is still active, Spring may keep trying to wire beans and open a socket.

Exclude the Synchronous Mongo Stack

If the application should start with no Mongo support at all, exclude both the client and data layers.

1import org.springframework.boot.autoconfigure.SpringBootApplication
2import org.springframework.boot.autoconfigure.data.mongo.MongoDataAutoConfiguration
3import org.springframework.boot.autoconfigure.mongo.MongoAutoConfiguration
4import org.springframework.boot.runApplication
5
6@SpringBootApplication(
7    exclude = [
8        MongoAutoConfiguration::class,
9        MongoDataAutoConfiguration::class
10    ]
11)
12class ApiApplication
13
14fun main(args: Array<String>) {
15    runApplication<ApiApplication>(*args)
16}

That is the usual starting point for a non-reactive application that should boot without touching Mongo.

Add Reactive Exclusions When Reactive Mongo Is Present

If your dependency tree includes reactive Mongo support, exclude those auto-configurations too.

1import org.springframework.boot.autoconfigure.SpringBootApplication
2import org.springframework.boot.autoconfigure.data.mongo.MongoDataAutoConfiguration
3import org.springframework.boot.autoconfigure.data.mongo.MongoReactiveDataAutoConfiguration
4import org.springframework.boot.autoconfigure.mongo.MongoAutoConfiguration
5import org.springframework.boot.autoconfigure.mongo.MongoReactiveAutoConfiguration
6
7@SpringBootApplication(
8    exclude = [
9        MongoAutoConfiguration::class,
10        MongoDataAutoConfiguration::class,
11        MongoReactiveAutoConfiguration::class,
12        MongoReactiveDataAutoConfiguration::class
13    ]
14)
15class ApiApplication

Without these additional exclusions, a reactive bean path may still trigger connection attempts.

Use Profile-Specific Exclusion for Tests

If production needs Mongo but tests do not, do not disable it globally in the main application class. Instead, exclude it only in a test profile.

1spring:
2  autoconfigure:
3    exclude:
4      - org.springframework.boot.autoconfigure.mongo.MongoAutoConfiguration
5      - org.springframework.boot.autoconfigure.data.mongo.MongoDataAutoConfiguration

Then activate that profile for the test.

1import org.junit.jupiter.api.Test
2import org.springframework.boot.test.context.SpringBootTest
3import org.springframework.test.context.ActiveProfiles
4
5@SpringBootTest
6@ActiveProfiles("test")
7class ContextTest {
8    @Test
9    fun contextLoads() {
10    }
11}

That keeps production wiring intact while allowing lightweight test startup.

Check for Custom Beans and Repository Activation

If exclusions appear to have no effect, the problem may no longer be Boot auto-configuration. Check for:

• a custom MongoClient bean in your own code
• repository interfaces that still activate Mongo support
• transitive dependencies pulling in reactive or repository starters
• active properties still pointing at a Mongo host

At that point, adding more exclusion lines blindly is less useful than inspecting the actual bean graph and dependency tree.

Dependency Shape Matters in Kotlin Projects Too

Because Spring Boot auto-configuration is classpath-driven, the real fix is often not just an annotation. It may also be removing an unnecessary starter dependency. If a module should not use Mongo, the cleanest answer can be to remove the Mongo starter from that module entirely.

That is often a better long-term fix than accumulating exclusions that future contributors will not immediately understand.

Common Pitfalls

• Excluding only MongoAutoConfiguration and assuming that disables the whole Mongo stack.
• Disabling Mongo globally when only tests needed the exclusion.
• Forgetting that reactive Mongo auto-configuration is separate from the synchronous path.
• Looking only at Boot exclusions while a custom Mongo bean or repository still forces connection creation.
• Keeping unnecessary Mongo starters on the classpath and then fighting their auto-configuration effects.

Summary

• 'MongoSocketOpenException at startup usually means some Mongo configuration path is still active.'
• Excluding only MongoAutoConfiguration is often not enough.
• Add data and reactive exclusions when those parts of the stack are present.
• Use test-profile exclusions if only tests should avoid Mongo.
• Inspect dependencies, repositories, and custom beans if exclusions do not solve the problem.