Gone are the days of installing backends—databases, message buses, you name it—on our own machines. Docker containers made that obsolete, replacing each unique "experience" with a simple docker run.

Then, Docker Compose upped the game, replacing imperative docker run commands with a declarative configuration that was willed into existence with a single docker compose up. For those of us who remember the old days, this is pretty fantastic.

And now... I can hear Chandler Bing in my head asking, "Can it BE any easier?"

Spring Boot says, "Why, yes! Yes. It. Can."

Self-Sufficient Applications

As of Spring Boot 3.1, using either Docker Compose or Testcontainers, your Spring Boot application will start its own containers before kicking off the main application code. Boom.

Docker Compose, Hands Off

If you have a docker-compose.yml file already, this is a no-brainer. Add the new spring-boot-docker-compose starter to your list of dependencies and skip straight to app startup. Spring Boot will find the file and save you a terminal command.

Spring Boot and Testcontainers for Dev

Testcontainers, a long-time fave for starting containers for testing, can now be used for development, too. The docker-compose.yml is replaced by simple beans annotated as @ServiceConnection, and application control is handed from a Main class in the test package to the Main class in the main package after containers are started. One advantage of this approach is that ports are dynamically assigned to containers, thereby eliminating any risk or annoyance of port conflicts.

How Is This Even Possible?

Spring Boot did a little "abstraction magic" so that it could obtain connection info from different providers. This simplifies how Spring Boot feeds connection info to your app, and it enables different providers to "plug in" to Spring Boot. Enter Docker Compose and Testcontainers!

More than a little nostalgic, I can still hear Chandler. "Can it BE any easier?" For now, this is where we are. And it's pretty darn easy.