This repository contains the Dockerfiles for the official Adoptium images of the Eclipse Temurin distribution (OpenJDK). These images are made available in Docker Hub.
If you are looking for the usage README then please head to the Official Docker Hub Documentation.
In general, we support Alpine, UBI, Ubuntu and Windows containers.
List of Supported Images By Tag
We maintain images for all LTS Java releases and the latest feature release. Older non-LTS releases are EOL and are removed from this repository and future Docker Hub manifests.
As these are official Docker Hub images, Docker Inc maintains the base image and so any critical CVEs in the base O/S layer gets updated by them in short order.
Note that the eclipse-temurin images include openssl as a prerequisite of
the wget and ca-certificates packages but they are NOT included in the
Ubuntu base image so updates to openssl will not necessarily trigger an
rebuild to pick up fixes. In general, low severity vulnerabilities can wait
until the next rebuild. See
this comment
for some details and also the
docker-library FAQ.
The Debian and Ubuntu images are generally also built periodically (about once a month) and may also be triggered by dockerhub if another high security vulnerability is detected, such as in openssl. Adoptium has no mechanism - other than putting an update to the Dockerfiles - to explicitly trigger a rebuild at dockerhub.
For JDK version updates, we update the dockerfiles and release on a quarterly cadence Temurin releases a Patch Set Update (PSU).
This section is for maintainers of the containers repository.
A Updater GitHub Action runs every 30 mins which triggers the
./generate_dockerfiles.py script to update the Dockerfiles by creating a Pull Request containing any changes. It uses the jinja templates defined in docker_templates to generate the docker updates. It uses the Adoptium API to fetch the latest artefacts for each release.
Generally this is not necessary but during a release you can also trigger the above process by running ./generate_dockerfiles.py manually by heading to The GitHub Action definition and clicking the Run Workflow button and making sure the main (default) branch is selected, then click the next Run Workflow button.
Once the PR from the hourly automated job is created you should review it (which itself tests all of the Docker Images that we have generate configuration for).
Once you've merged the PR, you can update the official Docker Hub manifest. This is done by running the following command in the containers repo on your local machine:
# Get the latest changes
git fetch --all
# Checkout the main branch
git checkout main
python3 dockerhub_doc_config_update.pyThis script will create a file called eclipse-temurin by default.
At the end it prints a publication-readiness summary for each Java version, checking JDK and JRE images against the configured architectures (including version-specific overrides). Missing Dockerfiles, missing architectures, pending upstream binary branches, and images still on an older release are reported as blockers. Deprecated and explicitly excluded configurations are not required. Release consistency is checked against the newest Java version found in the local Dockerfiles for that major version, not against live release assets.
The summary is an aligned table of Java releases, readiness status, and complete
image counts, followed by a table of grouped blockers and affected images.
READY means that Java version has an update relative to the official upstream
manifest and all its images are complete. UP TO DATE means the same releases
are already published; a different Git commit alone is not a new Java release.
New distro entries also count as updates. UNKNOWN means the upstream manifest
could not be fetched, so publication readiness cannot be confirmed.
Open eclipse-temurin PRs in docker-library/official-images are checked for
added manifest tags matching the exact release, rather than just a Java major
version in the PR title. Matching updates show PR OPEN, with the PR number and
link, and are not suggested for another PR. A failed GitHub lookup is reported
explicitly and makes otherwise-ready updates UNKNOWN. GH_TOKEN or
GITHUB_TOKEN can be used for authenticated GitHub API requests. If neither is
set, the script automatically uses your existing GitHub CLI login (gh auth login). Without either form of authentication, requests remain anonymous and
may hit GitHub's lower rate limit; a failed PR lookup still blocks publication.
Long cells wrap so the tables stay readable in terminal output.
The report is written to stderr, keeping stdout clean for tools that request the
manifest via python3 dockerhub_doc_config_update.py /dev/stdout.
Publish each READY Java version independently: every required image and
architecture for that version must be available at the same release, but other
Java versions need not be ready. The report is advisory; the script still writes
the full manifest, including pending architecture entries. Select only the ready
versions for the upstream PR, leaving other upstream entries unchanged.
To open one PR for all unpublished READY Java versions:
python3 dockerhub_doc_config_update.py --create-prNo version selection is needed. BLOCKED, UNKNOWN, UP TO DATE, and PR OPEN
versions are excluded. If Java 17 is the only unpublished ready version, the
PR updates only Java 17. Without the flag, the script only generates the
manifest and reports readiness, including when its output is /dev/stdout.
Preview the same PR without making changes:
python3 dockerhub_doc_config_update.py --dry-run
# Equivalent:
python3 dockerhub_doc_config_update.py --create-pr --dry-runDry runs show the proposed title, branch, and manifest diff on stderr. They do not write the local manifest, clone a repository, create a fork, push, or open a PR. They verify publication sources using read-only Git and GitHub API requests and do not require the GitHub CLI when an API token is provided.
PR creation requires Git and an authenticated GitHub CLI (gh auth login).
You can run the script from a feature branch, including one with changes to
the script, tests, or documentation. The distribution configuration and every
selected Dockerfile and entrypoint must exactly match published
adoptium/containers main; unmerged image or configuration changes are
rejected. Publication entries use that published commit, never the tooling
branch's unmerged commit. The script clones Official Images into a temporary directory, creates or reuses
your fork, and opens one PR containing only the selected versions' JDK/JRE
entries. Unready or already-published upstream entries and global manifest metadata are preserved.
Your current checkout is not used for the publication branch.
Immediately before creating the branch, the script checks again for matching
open publication PRs and refuses if the upstream manifest changed. Shared-tag
conflicts with unselected versions (such as moving latest from another Java
version) also stop publication rather than changing unrelated entries.
Command failures are reported and return a nonzero exit status; if pushing
succeeds but opening the PR fails, the publication branch remains in your fork.
The generated full local manifest is still advisory and must not be submitted
wholesale while other versions are unready.
Alternatively, replace the Manifest on Docker Hub with only the selected ready versions updated. This can be done using a fork of the code or via the GitHub UI as follows:
- Go to https://github.com/docker-library/official-images/blob/master/library/eclipse-temurin web UI
- Click edit(pencil button)
- Remove its content
- Copy-paste the manifest with only the ready versions replaced from eclipse-temurin, preserving all other upstream entries
- At the bottom of that edit screen' Propose changes section
- add title e.g [eclipse-temurin: XXXXX]
- add description for the commit
- click Propose Change button.
In the next screen click on the Create Pull Request button.
Once that PR has been created it will be automatically tested and reviewed by Docker Hub staff and eventually released.
It can be useful to look at the "Diff for XXX:" output created by one of the Docker Hub GitHub Actions on the Pull Request. This output should not be read as a traditional PR (since Docker Hub bots do move things around, so you may see what looks like odd deletions) but as a sanity check to make sure you see the platforms/architectures that you expect.
During a release, when linux and windows binaries are published to github, there is an "hourly" automated containers CI PR labeled "Update Dockerfiles", that will generate any updates required to the Dockerfiles for these new linux and windows binaries. The containers Dockerfiles are located within this repository under the folders <version>/<jdk|jre>/<alpine|ubi|ubuntu|windows>/<os_container_version>/Dockerfile.
It should be understood that no actual "pushing" of any information to dockerhub is done, the way it works is once all the necessary Dockerfiles have been updated for the new releases, the remote dockerhub Manifest is updated with the information. Then dockerhub "pulls" the new container Dockerfiles and builds the new images for the updated Manifest, once completed those new images are then available in dockerhub.
The "Release" process for updating dockerhub cannot start until all linux and windows binaries for all versions have been published, due to the Manifest setup.
- Have all linux and windows binaries been published for all versions?
- Verify that all the <version>/<jdk|jre>/<alpine|ubi|ubuntu|windows>/<os_container_version>/Dockerfile's have been updated by the auto-generated "Update Dockerfiles" PRs. Check there are not any left requiring "approval" to merge?
- Create and publish the dockerhub Manifest update PR following the instructions: Update Official Docker Hub Manifest