Introduction

Redeploying a Spring Boot application in Docker usually means rebuilding the application image and replacing the running container with one based on the new image. The exact commands depend on whether you are using plain Docker, Docker Compose, or an orchestrator, but the principle is the same: a container is treated as disposable, while the image is the versioned artifact you replace.

The Basic Redeploy Flow

A straightforward redeploy has these steps:

1. build the new Spring Boot jar
2. build a new Docker image
3. stop and remove the old container
4. start a new container from the new image

That is the common local and small-server workflow.

Build the Spring Boot Application First

For Maven:

./mvnw clean package

For Gradle:

./gradlew clean bootJar

That produces the updated application artifact, usually under target/ or build/libs/.

Example Dockerfile

A simple Spring Boot Dockerfile looks like this:

1FROM eclipse-temurin:21-jre
2WORKDIR /app
3COPY target/app.jar app.jar
4EXPOSE 8080
5ENTRYPOINT ["java", "-jar", "app.jar"]

After rebuilding the jar, rebuild the image:

docker build -t my-spring-app:latest .

That image now contains the new application version.

Replace the Running Container

If you are using raw Docker commands:

1docker stop my-spring-app || true
2docker rm my-spring-app || true
3
4docker run -d \
5  --name my-spring-app \
6  -p 8080:8080 \
7  my-spring-app:latest

This is the standard replace-the-container workflow. You do not "update the container" in place. You replace it with a new one built from the new image.

Docker Compose Redeploy

If the app is managed by Compose, the usual redeploy command is even simpler:

docker compose up -d --build

This rebuilds the image if needed and recreates the service container.

A minimal Compose example:

1services:
2  app:
3    build: .
4    ports:
5      - "8080:8080"

Compose is often the easiest option when the app also depends on services such as Postgres, Redis, or another internal API.

Keep Configuration Outside the Image

A redeploy becomes much cleaner when configuration is externalized through environment variables, bind mounts, or secrets rather than baked into the image.

Example:

1docker run -d \
2  --name my-spring-app \
3  -p 8080:8080 \
4  -e SPRING_PROFILES_ACTIVE=prod \
5  -e SPRING_DATASOURCE_URL=jdbc:postgresql://db/app \
6  my-spring-app:latest

That way, rebuilding the app image does not require rewriting environment-specific configuration inside the container filesystem.

What About Zero-Downtime Deployment

The stop-remove-run sequence causes a brief interruption. For development or internal tools, that is often acceptable. For production traffic, you usually want a safer rollout pattern such as:

• blue-green deployment
• rolling replacement behind a load balancer
• orchestrated updates in Kubernetes or another platform

The key point is that Docker alone gives you container replacement, but higher-level deployment guarantees usually come from surrounding infrastructure.

Verify the New Deployment

After redeploying, check both container state and application health.

docker ps
docker logs my-spring-app
curl http://localhost:8080/actuator/health

This helps distinguish:

• image built successfully
• container started successfully
• Spring Boot application actually became healthy

Those are not the same thing.

Common Pitfalls

• Rebuilding the jar but forgetting to rebuild the Docker image.
• Restarting the old container and expecting new code to appear magically.
• Baking environment-specific settings into the image instead of externalizing them.
• Treating redeploy as an in-place container mutation instead of an image replacement.
• Skipping post-deploy health checks and assuming a running container means a healthy app.

Summary

• Redeploying a Spring Boot app in Docker means building a new image and replacing the running container.
• With plain Docker, the common flow is build, stop, remove, and run.
• With Docker Compose, docker compose up -d --build is the usual shortcut.
• Keep configuration outside the image so redeploys stay clean and repeatable.
• Always verify both container status and application health after the replacement.