WebSphere Liberty 26.0.0.9 adds hardened UBI Micro container images

IBM has added official Red Hat Universal Base Image Micro support to WebSphere Liberty 26.0.0.9, giving Java teams a smaller runtime image with stricter defaults while retaining Liberty’s established container-build workflow. The new images are available now, according to IBM’s WebSphere Liberty announcement.

What changed

The UBI Micro variant deliberately excludes microdnf and other package-manager dependencies. IBM says that reduces the runtime software footprint and the number of components that must be maintained and scanned. The new image family uses tags ending in -ubi-micro; IBM’s example starts from icr.io/appcafe/websphere-liberty:kernel-java25-openj9-ubi-micro.

The image also changes two defaults. Plain HTTP is disabled, pushing deployments toward encrypted communication, and Liberty’s configuration-update trigger is disabled so changes to server configuration are not applied while the server is running. IBM says those defaults apply only to the new UBI Micro images, avoiding behavior changes for existing UBI Minimal and UBI Standard users.

Who it affects

This is chiefly a deployment choice for teams running WebSphere Liberty applications in containers, including on Kubernetes and Red Hat OpenShift. It is relevant where platform or security teams require minimal production images, fewer runtime utilities and controlled configuration changes.

The trade-off is intentional: teams cannot install extra operating-system packages inside the final image with a normal package-manager command. IBM provides package-helper.sh to resolve and stage packages in an intermediate build layer, then copy them into a later stage without carrying the package manager into production.

What to do

Existing Liberty users can evaluate the UBI Micro tag without replacing the familiar application-image process. IBM’s documented example still copies server.xml and application artifacts into the image, then runs features.sh and configure.sh to install Liberty features and optimize the runtime.

Before switching, teams should test assumptions that depend on the old defaults: health checks or local integrations using HTTP, workflows that expect live configuration reloads, and troubleshooting procedures that rely on shell utilities absent from UBI Micro. Applications requiring additional RPM content should move that work into a staged build using IBM’s package helper rather than trying to modify the final runtime image.

The release is a practical hardening option rather than a mandatory migration. Its value is clearest for production Java workloads where reducing image contents and making transport and configuration behavior explicit are worth the added build discipline.