What Are Docker Official Images?
Docker Official Images are a curated set of base images maintained through the docker-library/official-images repository. They are reviewed by Docker staff, kept current with security patches, and available under a namespace-free name — meaning you can pull azul-zulu directly rather than azul/zulu-openjdk.
For enterprise teams, the distinction matters. Official images:
- Undergo a structured review process.
- Are continuously scanned for vulnerabilities.
- Automatically rebuild whenever upstream base images are patched.
- Are cryptographically signed with Azul’s GPG key.
Azul provides the Dockerfiles and validates each build, while Docker reviews and builds the final images on its own infrastructure. This separation of responsibilities is an intentional part of what makes the program trustworthy.
The review covers build reproducibility, update cadence, documentation completeness, tag naming conventions, and security posture of the base image. Getting Azul Zulu into the program required over two years of collaboration and back-and-forth with Docker’s team, starting with a pull request opened in January 2024 and merged on March 17, 2026. The source of truth for all Dockerfiles is the public repository at github.com/AzulSystems/azul-zulu-images.
Azul also commits to supporting all Java versions in the Official Images — not only Long Term Support (LTS) releases. Developers working with Short Term Support (STS) releases and feature-preview code are covered alongside those running Java 8, 11, 17, 21, and 25 LTS.
Understanding Community Availability vs. Subscriber Availability
All Azul Zulu container images are built on one of two flavors:
Community Availability (CA) builds are free to download and use under open-source licensing terms, with no account or license agreement required beyond the open-source terms. CA images are appropriate for evaluation, development, and open-source projects.
Subscriber Availability (SA) builds are commercially supported releases available exclusively to Azul customers. SA offers:
- Immediately deployable security-only updates and out-of-cycle updates to address AI-era vulnerability exploits.
- Extended platform and configuration support (such as 32-bit platforms).
- Software Bill of Materials (SBOMs) and Federal Information Processing Standards (FIPS) builds to meet regulatory requirements.
- Enterprise-ready Coordinated Restore at Checkpoint (CRaC) support.
- And more…
SA customers also have access to Azul Support engineers averaging over 20 years of Java experience.
Azul Container Image Options
CA: Docker Official Images
The recommended starting point for any new project. Pull directly from Docker Hub using the azul-zulu name:
docker pull azul-zulu:21
docker pull azul-zulu:21-jre
docker pull azul-zulu:25
Available tags cover Java 8, 11, 17, 21, and 25, with JDK, JRE, and headless variants for each major version, as well as the current STS release. The full tag listing is documented in Zulu CA Docker Official Tags.
For implementation details on using these images, see Running Azul Zulu CA in a Docker Container.
CA: Legacy Docker Hub Images
The original Azul images under the azul/zulu-openjdk-* namespace remain currently available and cover a wider range of base OS combinations, including Ubuntu, Debian, Alpine, CentOS, and distroless variants. These images are planned for deprecation later in 2026 as the Official Images expand to cover the same ground. If you are currently using azul/zulu-openjdk, plan your migration to azul-zulu accordingly.
The full tag listing is documented in Zulu CA Docker Tags.
SA: Azul Customer Registry
SA images are hosted on Azul’s private container registry at sa.registry.azul.com and require authentication with an access token. Customers can manage their access tokens through access.azul.com. Available base OS options include Ubuntu, Alpine, Debian, Distroless, and Rocky Linux. Currently supported Java versions include 8, 11, 17, 21, 25, and 26.
CPU vs. PSU update tracks
SA images are available in two update types that reflect different risk profiles for production deployments and are both aligned with OpenJDK’s quarterly release schedule:
- CPU (Critical Patch Updates): Security fixes and critical bug fixes, and last quarter’s stabilized non-security updates only. These are the lower-risk options for applying urgent security patches with minimal change surface.
- PSU (Patch Set Updates): All CPU fixes plus additional non-security bug fixes, feature enhancements, and more.
The Zulu minor version in the tag identifies the track:
- An odd minor (e.g.,
21.43) indicates CPU. - An even minor (e.g.,
21.44) indicates PSU.
For the complete tag listing and tagging scheme, see Zulu SA Docker Tags.
For full setup and configuration, see Running Azul Zulu SA in a Docker Container.
SA: Chainguard Images
For environments with strict supply chain security requirements, Azul Zulu SA is also available through Chainguard’s registry. These images are built on Wolfi, a purpose-built Linux undistro designed for minimal, secure containers, ideal for the cloud-native era.
Chainguard Zulu images are rebuilt daily, include high-quality build-time SBOMs attesting to the provenance of all artifacts, carry verifiable container image signatures via Cosign, and are built reproducibly using apko (read more about reproducibility here). Access to the Chainguard registry requires authentication.
For setup instructions, see Running Azul Zulu SA in a Chainguard Container.
Choosing the Right Image
| If you are… | Use… |
| Evaluating Azul, building open-source projects, or developing locally | Docker Official Image (azul-zulu) |
| Running in production with a commercial support contract | SA Private Registry (sa.registry.azul.com) |
| In a high-security environment requiring SBOMs, signed images, and minimal attack surface | Chainguard (cgr.dev) |
| Currently using legacy Docker Hub images | Migrate to azul-zulu before the 2026 deprecation |
Reducing Container Image Size
Starting with a trusted base image is the first step; keeping that image lean is the second. Three approaches are available, each trading build complexity for image size reduction.
Single-stage build (not recommended for production): Building and running in one image ships your source code, build tool, full JDK, and OS tooling alongside your application. For a 2.2 KB JAR, this approach can produce an image over 500 MB.
Multi-stage build with JRE: A multi-stage Dockerfile separates the build environment from the runtime image. The first stage builds the application using the full JDK and Maven; the second stage copies only the JAR into a JRE-based image. The JRE is a stripped-down version of the JDK containing only the tools needed to run applications. This approach typically reduces image size by 30–40% compared to a single-stage build.
Custom runtime with jdeps and jlink: The JRE still includes every Java module, including those your application does not use. jdeps analyzes your application’s bytecode to identify exactly which modules are required; jlink then assembles a minimal JRE containing only those modules. This approach can reduce image size to around 140 MB for a simple application — roughly a 75% reduction compared to a single-stage build.
Note for Spring Boot and Hibernate users: These frameworks rely heavily on reflection and classpath scanning. jdeps may not capture all required modules at static analysis time. Manually add any missing modules and test the resulting container thoroughly before using jlink in production.
For Dockerfile examples demonstrating each approach, see the companion blog post Using the Azul Zulu Docker Official Images: From Simple Pull to Lean Container.
Building Containers Without a Dockerfile: Paketo Buildpacks
Dockerfile-based builds are not the only way to containerize a Java application with Azul Zulu. Paketo Buildpacks implement the Cloud Native Buildpacks (CNB) specification and assemble a layered OCI image without requiring a Dockerfile. The buildpack inspects your application source, decides what is needed to run it, and layers the JVM, application code, and launch helpers independently. This means each concern can be updated independently.
The Paketo Buildpack for Azul Zulu (buildpack ID: paketo-buildpacks/azul-zulu) supplies the JVM layer using Azul Zulu CA builds. It integrates directly into the Paketo Java buildpack and is actively maintained, with new Zulu versions typically integrated within days of a security update release.
Spring Boot users who run spring-boot:build-image already use Paketo implicitly. Adding paketobuildpacks/azul-zulu to the buildpacks list in the Spring Boot Maven Plugin configuration switches the JVM to Azul Zulu. The buildpack supports configuration via environment variables for Java version (BP_JVM_VERSION), runtime type (BP_JVM_TYPE: JRE or JDK), jlink-based custom runtimes (BP_JVM_JLINK_ENABLED), and observability features including JFR, JMX, and remote debugging.
Non-Spring-Boot teams can use the pack CLI directly to build any JVM application with Azul Zulu as the runtime, passing the same BP_ configuration variables as command-line arguments.
Typical container sizes using Paketo with Azul Zulu are comparable to Dockerfile-based builds:
| Build approach | Approximate image size |
| Spring Boot plugin, JRE | ~270 MB |
| Spring Boot plugin, jlink | ~135 MB |
pack CLI, no configuration |
~260 MB |
pack CLI, jlink |
~135 MB |
For a full walkthrough including configuration options and a demo project, see Building Java Containers Without a Dockerfile: Azul Zulu and Paketo Buildpacks.
Documentation References
- CA Docker images: docs.azul.com/core/install/linux-ca-docker
- SA Docker images: docs.azul.com/core/install/linux-sa-docker
- SA Chainguard images: docs.azul.com/core/install/linux-sa-docker-chainguard
- All image tags: docs.azul.com/core/docker-image-tags
- Azul Zulu on Docker Hub: hub.docker.com/_/azul-zulu
- Azul Zulu Dockerfiles on GitHub: github.com/AzulSystems/azul-zulu-images
