Java container image best practices with Docker

Java container image best practices with Docker

Help teams build secure, reproducible, and maintainable Docker container images for Java applications without coupling the guidance to Spring Boot, Quarkus, or Micronaut.

What is covered in this Skill?

• Dockerfile structure for Java applications: multi-stage builds, Maven dependency caching, deterministic artifact copies, jlink custom runtimes, and .dockerignore
• Runtime image selection: micro distributions such as Alpaquita, minimal JRE images, pinned versions or digests where appropriate, image labels, and explicit entrypoints
• JVM container ergonomics: memory percentage flags, startup behavior, graceful shutdown signals, time zones, and predictable runtime options
• Security defaults: non-root users, least privilege, no secrets in layers, reduced package managers, vulnerability scanning, SBOM awareness, and avoiding privileged containers
• Operational readiness: health checks when suitable, stdout/stderr logging, port declaration, image size control, build reproducibility, and CI verification

Scope: Framework-agnostic Docker and container-image quality for Java projects. For framework runtime wiring, defer to the matching Spring Boot, Quarkus, or Micronaut skill. For Testcontainers-based tests, defer to the relevant testing skill.

Constraints

Keep recommendations at the Dockerfile, image-build, and runtime-container layer unless the user explicitly asks for framework-specific configuration. After editing this repository's XML sources, regenerate skills and verify the build.

• MANDATORY: Run ./mvnw compile or mvn compile before proposing Java or Maven changes in the same change set
• SECRETS: Never bake credentials, tokens, private keys, Maven settings with secrets, or environment-specific secrets into image layers, labels, arguments, or logs
• SECURITY: Prefer non-root execution, least-privilege filesystem permissions, micro runtime images, and explicit container capabilities over privileged defaults
• JLINK: Prefer jlink custom runtimes for production images when the module graph is known, validated at runtime, and compatible with the application's dependencies
• REPRODUCIBILITY: Pin base image versions intentionally, document digest trade-offs, keep build inputs explicit, and avoid network-dependent runtime startup steps
• JVM: Account for container memory and CPU limits with JVM flags, graceful shutdown behavior, and observable startup failures before claiming production readiness
• BOUNDARIES: Defer Spring Boot runtime behavior to @301-frameworks-spring-boot-core, Quarkus runtime behavior to @401-frameworks-quarkus-core, Micronaut runtime behavior to @501-frameworks-micronaut-core, and Testcontainers setup to the matching testing skill
• VERIFY: Run ./mvnw clean verify or mvn clean verify before promoting changes
• EDGE CASE: If the target Java version, build tool, deployment platform, base-image policy, registry policy, or security scanner is missing and affects the recommendation, ask a clarifying question before editing container artifacts
• EDGE CASE: If requested changes conflict with security policy, image provenance, air-gapped builds, or runtime platform constraints, explain the trade-off and ask for confirmation

When to use this skill

• Review Java Dockerfile
• Improve Docker image security
• Add jlink runtime to a Java container
• Add containerization to a Java project
• Optimize Java container image size
• Review Docker build reproducibility

Workflow