# docker-library/tomcat packages Apache Tomcat as a Docker Official Image > This repository is the build source for the Docker Official Image of Apache Tomcat, not the application itself. It holds a Dockerfile template, one directory per Tomcat major version and a set of shell and jq scripts that generate the published tags. **docker-library/tomcat** — Docker Official Image packaging for Apache Tomcat - Repository: https://github.com/docker-library/tomcat - Website: https://tomcat.apache.org - Stars: 636 · Forks: 743 - Language: Shell - License: Apache-2.0 - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/docker-library-tomcat ## This repository builds images and never runs Tomcat itself The first thing to get straight is what lives here and what does not. This is the git repository for the Docker Official Image named tomcat, and the repository description says as much: it is Docker Official Image packaging for Apache Tomcat. The primary language is Shell, which tells you the nature of the work. There is no application source code, no Java project, no web.xml. The deliverables are Dockerfiles and the machinery that produces them. A reader who opens this repo expecting to find servlet container internals will find instead a Dockerfile.template at the top level and a set of scripts that expand that template into concrete images. The actual Tomcat binaries are not built here. They are pulled at image build time from the upstream Apache release, and the homepage recorded for the project is tomcat.apache.org, which is where the server itself is documented. ## One directory per Tomcat major version, plus a single template The top level listing shows version directories named 9.0, 10.1 and 11.0, which is where the per-version build inputs live, alongside Dockerfile.template and a small set of scripts: apply-templates.sh, update.sh, versions.sh, generate-stackbrew-library.sh, from.jq and shared.jq. The naming suggests the division of labour, though the documentation is silent on the internals of each script. What can be confirmed from the layout is that image generation is driven from one shared template rather than from separate hand maintained Dockerfiles for every Tomcat release, and that the versions.json and versions.sh files hold the mapping between Tomcat versions and image tags. The .jq files are the query language used to read and reshape that JSON, and generate-stackbrew-library.sh is named for producing the library index used by the Docker Hub stackbrew format. Two things are conspicuously absent from the listing: no test suite directory and no CI configuration beyond the .github/ directory, so verification of an image happens elsewhere in the official-images workflow rather than inside this repository. ## Where to get the image and where its usage notes live There is no install command in this repository, and there is a reason for it. The README describes this as the git repo of the Docker Official Image for tomcat and links to the Docker Hub page for the full readme on how to use this Docker image, plus information regarding contributing and issues. The Docker Hub tag is hub.docker.com/_/tomcat/, and that page, not this README, is where you find the environment variables, ports and volume mounts for running the container. The README here is a generated stub: it names the docker-library/docs repository as the place where the full image description is maintained, specifically the tomcat directory, and it closes with a marker line reading THIS FILE IS GENERATED BY https://github.com/docker-library/docs/blob/master/generate-repo-stub-readme.sh, carried as plain text inside an HTML comment rather than a runnable command. The repository address is the starting point for anyone tracing that path: ```bash # https://github.com/docker-library/tomcat ``` The practical consequence is that any question about how to run the image has to be answered from Docker Hub, and any question about how the image is built has to be answered from the files here. ## Three repositories decide what a published tag contains The build pipeline is deliberately distributed, and understanding it explains why changes here do not show up on Docker Hub right away. The documentation describes this as the official images change lifecycle and links to a FAQ entry titled An image's source changed in Git, now what?. The flow runs from this repository, where the template and version directories live, through the official-images repository, which the README calls the current source of truth for the tomcat image by way of the library/tomcat file, and finally to Docker Hub, where the tag becomes pullable. Pull requests for the image are tracked separately, with outstanding tomcat image pull requests carrying the library/tomcat label on the official-images repository. So the pipeline is: change a Dockerfile.template or a version directory here, open a pull request against official-images, and let that process publish. That indirection is the price of a consistent Official Image pipeline, and it is also why a merged change may take time to appear in your registry. ## No releases means you must read tags, not versions The repository has no GitHub releases, which is normal for an official-images source repo but has a practical consequence: there is no release page, no changelog and no version history to browse. Maintenance instead shows up in the commit history, and the last push was on 2026-10-12. The project is not archived, so it is still receiving changes. But the image tags you pull are not versioned by this repository in the way a normal release would be, and nothing in the README tells you which Tomcat version a given tag corresponds to. That mapping lives in versions.json and the per-version directories, which means you have to inspect the repository content to answer a question that a normal release process would answer for you. If you need to audit which upstream Tomcat build ended up in a given image, you have to read the Dockerfile for that version directory and check the source it pulls, since the README provides no per-tag explanation. ## The licence covers the packaging, not the server it ships The repository is licensed under Apache-2.0, with the LICENSE file present at the top level. That licence covers the packaging work in this repository, the templates and the scripts. It is separate from the licensing of Apache Tomcat itself, which the packaging downloads at build time and which carries its own terms. If you are assessing a licence position for a container image you distribute, the honest answer is that two licences are in play and the repository's own field only speaks to one of them. The project also ships .gitattributes, .gitignore and a .github/ directory, which is the usual furniture of a GitHub hosted template repo rather than something operationally significant. One more constraint deserves mention for anyone building on this: the project explicitly frames itself as the community maintained image, so if you need a supported vendor image with a support contract, this repository is not the thing that provides it. ## Conclusion Adopt docker-library/tomcat when you want the community maintained Official Image and accept that its tags are produced by a template pipeline rather than hand written Dockerfiles per release. It is the wrong place to look for Tomcat tuning advice, since the real usage documentation lives on the Docker Hub page and in the docker-library/docs repository. Before you pin a tag, check the library/tomcat file in the official-images repository to see which source the published tag was generated from, and read the Dockerfile.template and the versions.json file in this repository to see what tags exist and how each one is built. ## FAQ ### Where is the documentation for the docker-library/tomcat image? The usage documentation lives on the Docker Hub page at hub.docker.com/_/tomcat/ and is generated from the tomcat directory of the docker-library/docs repository. The README in this repository is a generated stub that points there, so the full readme on how to use the image is not kept in the git repo. ### How does a change to a Dockerfile in docker-library/tomcat reach Docker Hub? The image source of truth for tomcat is the library/tomcat file in the official-images repository, and pull requests for the image are tracked there under the library/tomcat label. A change merged in this repository therefore passes through the official-images change lifecycle before a new tag is published to Docker Hub. ### Which Tomcat versions does the docker-library/tomcat repository build images for? The top level of the repository contains version directories named 9.0, 10.1 and 11.0, and the versions.json and versions.sh files hold the version to tag mapping. The README does not list the published tags, so the mapping has to be read from those files. ### Who maintains the docker-library/tomcat image? The README states that the image is maintained by the Docker Community, and it explicitly notes that it is not to be confused with any official tomcat image provided by tomcat upstream. The homepage recorded for the repository is tomcat.apache.org, which is the Apache project's own site. ### What licence applies to the docker-library/tomcat repository? The repository is licensed under Apache-2.0, with the LICENSE file at the top level. That licence covers the packaging files in this repository; the Apache Tomcat binaries that the images download at build time carry their own separate terms. ## Sources - [docker-library/tomcat on GitHub](https://github.com/docker-library/tomcat) - [Issues](https://github.com/docker-library/tomcat/issues) - [License: Apache-2.0](https://github.com/docker-library/tomcat/blob/master/LICENSE) - [Project website](https://tomcat.apache.org) - [README](https://github.com/docker-library/tomcat/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/docker-library-tomcat