Build small Spring Boot Docker images that start fast in production

Ready to move your Spring Boot service from laptop hero to containerized citizen of the cloud The plan is simple and practical with a little bit of ruthless trimming to keep images small and startups speedy This guide covers the build artifact setup multi stage image design JVM tuning local verification and registry publishing for CI friendly workflows

Make a reproducible executable jar

Use Maven or Gradle and enable the Spring Boot packaging plugin so you get a single artifact that contains classes and dependencies That way the container only needs one file to run the app and you avoid shipping build tools into production

• With Maven run mvn clean package and use the Spring Boot maven plugin to repackage the jar
• With Gradle run gradle bootJar which produces the executable jar
• Prefer deterministic builds so your image can be reproduced by CI and by your future self who will be grateful

Use a multi stage Dockerfile to keep images tiny

Build in one stage and run in another The build stage uses Maven or Gradle to assemble the jar The final stage copies the jar into a small runtime image like a slim Java runtime or a distroless base The idea is to avoid shipping compilers or build caches into your runtime image

• Stage one runs the build and emits the jar into a build output folder
• Stage two copies that jar into a minimal runtime image and sets the command to run Java with the jar

Quick note on layered jars

Spring Boot supports layered jars which let Docker cache layers for dependencies independently from your code This speeds up iterative builds and reduces CI network bill shock

Tune the JVM for containers

Containers are not magical They still need sensible JVM flags Use environment variables to pass options so the same image adapts across environments Use either JAVA_OPTS or JAVA_TOOL_OPTIONS to supply flags at runtime

• Set a reasonable heap with an xmx flag to avoid OOM surprises
• Enable container awareness which modern JVMs do by default but double check for older versions
• Prefer server mode for faster throughput when latency is not the main villain

Build the image and verify locally

From your project root run the docker build command with a clear tag name for reproducibility For example run docker build with a tag such as myapp latest This gives you a simple image name to use in local tests and in CI

Run the container locally and map ports to test endpoints Use curl or a browser to check health and logs Verify that logging and health endpoints behave the same as on your laptop

Publish to a registry and integrate with CI

Push images to an authenticated registry and use immutable tags for releases Avoid the classic latest trap which is an invitation to surprise rollbacks Use your CI pipeline to build the jar run tests build the image and push a versioned image that your deployment system can rely on

Checklist and parting sarcasm

• Produce a single executable jar with Maven or Gradle
• Use a multi stage Dockerfile to separate build from runtime
• Tune the JVM with environment variables so images remain portable
• Validate locally before you unleash onto the staging herd
• Push versioned images to a registry and let CI do the heavy lifting

Follow these steps and you will get smaller images faster startups and fewer surprises when you move services from a developer laptop into containers in production Also you will have fewer meetings about why the app worked on one machine and not on another and that is worth the effort