Repository navigation
Migrate Dockerfile to Docker Hardened Images (DHI) #306
Description
Activity
- addedenhancementNew feature or requestNew feature or requestgood first issueGood for newcomersGood for newcomersjavaPull requests that update Java codePull requests that update Java codecontainersPull requests that update containers codePull requests that update containers codepriority:lowNice-to-have improvement. Can be deferred without blocking other work.Nice-to-have improvement. Can be deferred without blocking other work.
on Apr 8, 2026 🔗 Related PRs
#162 - chore(ci): simplify Java CI workflow [merged]
#171 - fix(ci): migrate workflow from adopt to temurin [merged]
#195 - feat: add multi-stage Dockerfile for building and running app [merged]
#287 - ci(release): implement named releases with tag-based deployment (#252) [merged]
📝 Issue Planner
Check the box below or use the
@coderabbitai plancommand to generate an implementation plan and prompts that you can use with your favorite coding assistant.- Create Plan
🧪 Issue enrichment is currently in open beta.
You can configure auto-planning by selecting labels in the issue_enrichment configuration.
To disable automatic issue enrichment, add the following to your
.coderabbit.yaml:issue_enrichment: auto_enrich: enabled: false
💬 Have feedback or questions? Drop into our discord!
After further review, we've decided not to implement this change.
The security and compliance benefits of Docker Hardened Images (SBOM, provenance attestations, SLSA Build Level 3) are well-suited for production systems with formal compliance requirements. However, this project is educational in nature — the primary artifact is the source code, not the container image. The tradeoff doesn't justify the added friction:
- Rebuilding the image locally requires a one-time
docker login dhi.io, since dhi.io requires authentication even for public images — unlike standard Docker Hub pulls - Two additional CI/CD secrets (
DHI_USERNAME/DHI_PASSWORD) to maintain across all six repos - Introduces a dependency on a third-party registry (
dhi.io) with its own availability surface
The existing Alpine-based images remain lean and sufficient for the project's goals. Closing as
wontfix.- Rebuilding the image locally requires a one-time
Problem
The current Dockerfile uses
maven:3.9-eclipse-temurin-25-alpine(builder) andeclipse-temurin:25-jdk-alpine(runtime). Using the full JDK at runtime ships compiler tooling,javac,jshell, and debug utilities that are never used, unnecessarily inflating the image and the attack surface.Pain points with the current approach:
Proposed Solution
Migrate to Docker Hardened Images (DHI), using a JRE-based runtime image (not JDK) to reduce both attack surface and image size in a single step.
DHI provides:
Suggested Approach
1. Update base images
Builder stage:
Runtime stage:
Switching from
jdktojrein the runtime is a direct size win bundled into this migration. For an even smaller image, see the dedicatedjlinkissue.2. Adapt health check
Verify
curlavailability in the DHI Alpine JRE variant. If unavailable:Option A: Replace with a Java-based HTTP check in
healthcheck.sh.Option B: Explicitly install
curlviaapk add --no-cache curl.3. Key files to modify
Dockerfile— update base images, verifyapk add curlcompatibilityscripts/healthcheck.sh— adapt if removing curl dependency.github/workflows/maven.yml— update CI/CD ifdhi.ioauthentication is needed4. Architecture considerations
springuser maintained/storagevolume mount unchangedsqlite-libs) still required viaapkNote: relationship to other Docker optimization issues
This issue focuses on security hardening. The
jlinkissue addresses the primary size reduction (full JDK → custom minimal JRE). Both can be implemented independently;jlinkprovides deeper size savings than the JDK→JRE switch bundled here.Acceptance Criteria
/storage) works correctlyspring) has correct permissionsdocker buildx imagetools inspect --format "{{json .SBOM}}")References