Deploy Spring Boot Applications to Production Environments

Spring Boot’s executable JAR and WAR packaging options work across a wide range of deployment targets. This guide covers the most common production destinations and shows you the configuration each one requires.

Deploy as a Docker container

Spring Boot integrates with Cloud Native Buildpacks (CNB) to produce optimized OCI images without writing a Dockerfile. When you need more control, you can write your own Dockerfile instead.

Buildpacks (recommended)
Dockerfile

Buildpacks inspect your application and automatically configure layers for the JDK, your dependencies, and your application classes. The resulting image does not require Docker knowledge to produce.Maven:

./mvnw spring-boot:build-image

Gradle:

./gradlew bootBuildImage

Run the produced image:

docker run --rm -p 8080:8080 docker.io/library/myapp:0.0.1-SNAPSHOT

To publish directly to a registry, pass -Dspring-boot.build-image.publish=true (Maven) or set bootBuildImage.publish = true (Gradle) and configure registry credentials in your build settings.

For full control over the image contents, use a multi-stage Dockerfile that leverages the layered JAR to produce a cache-friendly image.First, extract the layers from the JAR:

java -Djarmode=tools -jar myapp.jar extract --layers --launcher --destination extracted

Then write a multi-stage Dockerfile:

Dockerfile

FROM eclipse-temurin:21-jre AS builder
WORKDIR /application
COPY myapp.jar application.jar
RUN java -Djarmode=tools -jar application.jar extract --layers --launcher

FROM eclipse-temurin:21-jre
WORKDIR /application
COPY --from=builder /application/application/dependencies/ ./
COPY --from=builder /application/application/spring-boot-loader/ ./
COPY --from=builder /application/application/snapshot-dependencies/ ./
COPY --from=builder /application/application/application/ ./
ENTRYPOINT ["java", "org.springframework.boot.loader.launch.JarLauncher"]

Build and run:

docker build -t myapp:latest .
docker run --rm -p 8080:8080 myapp:latest

Deploy to Kubernetes

Spring Boot auto-detects Kubernetes deployment environments by checking for *_SERVICE_HOST and *_SERVICE_PORT environment variables. The Actuator module exposes dedicated liveness and readiness endpoints that Kubernetes uses to manage pod lifecycle.

Add Actuator health probes

Add spring-boot-starter-actuator to your dependencies, then enable Kubernetes probes:

application.properties

management.endpoint.health.probes.enabled=true
management.health.livenessstate.enabled=true
management.health.readinessstate.enabled=true

Sample Kubernetes Deployment manifest

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: docker.io/library/myapp:0.0.1-SNAPSHOT
          ports:
            - containerPort: 8080
          livenessProbe:
            httpGet:
              path: /actuator/health/liveness
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /actuator/health/readiness
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5
          lifecycle:
            preStop:
              sleep:
                seconds: 10

The preStop sleep hook shown above requires Kubernetes 1.32 or later. On earlier versions, use an exec command instead:

lifecycle:
  preStop:
    exec:
      command: ["sh", "-c", "sleep 10"]

This sleep gives the load balancer time to stop routing new requests to the pod before Spring Boot’s graceful shutdown begins.

Graceful shutdown configuration

Configure Spring Boot’s graceful shutdown period to match your Kubernetes termination grace period:

application.properties

server.shutdown=graceful
spring.lifecycle.timeout-per-shutdown-phase=30s

If you increase spring.lifecycle.timeout-per-shutdown-phase beyond 30 seconds, you must also increase terminationGracePeriodSeconds in your pod spec. Otherwise, Kubernetes sends SIGKILL before Spring Boot has finished shutting down in-flight requests.

Deploy as a WAR to a traditional servlet container

WAR deployment is not supported for Spring WebFlux applications because WebFlux does not depend on the servlet API.

Extend SpringBootServletInitializer

Update your main application class to extend SpringBootServletInitializer and override configure:

MyApplication.java

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.builder.SpringApplicationBuilder;
import org.springframework.boot.web.servlet.support.SpringBootServletInitializer;

@SpringBootApplication
public class MyApplication extends SpringBootServletInitializer {

    @Override
    protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
        return application.sources(MyApplication.class);
    }

    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }

}

Change the packaging to WAR

Maven
Gradle

pom.xml

<packaging>war</packaging>

build.gradle

apply plugin: 'war'

Mark the embedded container as provided

The embedded Tomcat (or Jetty/Undertow) must not be bundled into the WAR since the external container provides it.

Maven
Gradle

pom.xml

<dependencies>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-tomcat</artifactId>
    <scope>provided</scope>
  </dependency>
</dependencies>

build.gradle

dependencies {
    providedRuntime 'org.springframework.boot:spring-boot-starter-tomcat'
}

Use providedRuntime rather than compileOnly. The compileOnly configuration excludes dependencies from the test classpath, which causes web integration tests to fail.

Build and deploy the WAR

# Maven
./mvnw package
cp target/myapp-0.0.1-SNAPSHOT.war $TOMCAT_HOME/webapps/

# Gradle
./gradlew war
cp build/libs/myapp-0.0.1-SNAPSHOT.war $TOMCAT_HOME/webapps/

When built with the Spring Boot plugin, the WAR file is also executable via java -jar, because lib-provided dependencies are packaged separately. You can run it on the command line and deploy it to a container with the same artifact.

Install as a Linux systemd service

Running Spring Boot as a systemd service gives you automatic restart on failure, log management through journald, and controlled startup ordering.

Place the JAR in a stable location

sudo mkdir -p /var/myapp
sudo cp target/myapp-0.0.1-SNAPSHOT.jar /var/myapp/myapp.jar
sudo useradd -r -s /bin/false myapp
sudo chown -R myapp:myapp /var/myapp

Create the systemd unit file

Create /etc/systemd/system/myapp.service:

myapp.service

[Unit]
Description=myapp
After=syslog.target network.target

[Service]
User=myapp
Group=myapp

Type=exec
ExecStart=/path/to/java/home/bin/java -jar /var/myapp/myapp.jar
WorkingDirectory=/var/myapp
SuccessExitStatus=143

[Install]
WantedBy=multi-user.target

Customize Description, User, Group, ExecStart, and WorkingDirectory for your application. The SuccessExitStatus=143 entry tells systemd that exit code 143 (SIGTERM) is a normal termination, not a failure.

Enable and start the service

sudo systemctl daemon-reload
sudo systemctl enable myapp.service
sudo systemctl start myapp.service
sudo systemctl status myapp.service

Deploy to Cloud Foundry

Cloud Foundry’s Java buildpack has first-class support for Spring Boot executable JARs.

Build your application

./mvnw clean package

cf login -a https://api.your-cf-instance.com
cf push acloudyspringtime -p target/demo-0.0.1-SNAPSHOT.jar

Verify the deployment

cf apps

You will see output similar to:

name                  requested state   instances   memory   disk   urls
acloudyspringtime     started           1/1         512M     1G     acloudyspringtime.cfapps.io

If your Cloud Foundry environment routes traffic through trusted proxies, forward headers are enabled automatically. If your platform does not guarantee that application instances are only accessible from a trusted network, set spring.forward-headers-strategy=none to avoid header spoofing.

Cloud Foundry exposes service binding credentials as environment variables prefixed with vcap. Spring Boot flattens these into the Spring Environment so you can access them with standard @Value or @ConfigurationProperties bindings.

Other cloud platforms

AWS Elastic Beanstalk

Elastic Beanstalk supports two options for Spring Boot:

Java SE platform — deploy an executable JAR directly. Follow the Java SE tutorial.
Tomcat platform — deploy a WAR file. Follow the Java on Tomcat tutorial.

Spring Boot auto-detects AWS ECS environments by checking for the AWS_EXECUTION_ENV variable. Override detection with the spring.main.cloud-platform property if needed.

Google App Engine Flex

Create an app.yaml in src/main/appengine/:

app.yaml

service: "default"

runtime: "java17"
env: "flex"

handlers:
- url: "/.*"
  script: "this field is required, but ignored"

manual_scaling:
  instances: 1

health_check:
  enable_health_check: false

Deploy with the App Engine Maven plugin:

pom.xml

<plugin>
  <groupId>com.google.cloud.tools</groupId>
  <artifactId>appengine-maven-plugin</artifactId>
  <version>2.4.4</version>
  <configuration>
    <project>myproject</project>
  </configuration>
</plugin>

mvn appengine:deploy

Heroku

Create a Procfile at the root of your repository that passes the $PORT environment variable:

web: java -Dserver.port=$PORT -jar target/demo-0.0.1-SNAPSHOT.jar

Deploy by pushing to the Heroku remote:

git push heroku main

Configuration

Data & Messaging

Web & API

Build & Deploy

Deploy Spring Boot Applications to Production Environments

Deploy as a Docker container

Deploy to Kubernetes

Add Actuator health probes

Sample Kubernetes Deployment manifest

Graceful shutdown configuration

Deploy as a WAR to a traditional servlet container

Install as a Linux systemd service

Deploy to Cloud Foundry

Other cloud platforms

Build docs developers (and LLMs) love

Configuration

Data & Messaging

Web & API

Build & Deploy

Documentation Index

​Deploy as a Docker container

​Deploy to Kubernetes

​Add Actuator health probes

​Sample Kubernetes Deployment manifest

​Graceful shutdown configuration

​Deploy as a WAR to a traditional servlet container

​Install as a Linux systemd service

​Deploy to Cloud Foundry

​Other cloud platforms

Build docs developers (and LLMs) love

Deploy as a Docker container

Deploy to Kubernetes

Add Actuator health probes

Sample Kubernetes Deployment manifest

Graceful shutdown configuration

Deploy as a WAR to a traditional servlet container

Install as a Linux systemd service

Deploy to Cloud Foundry

Other cloud platforms