dotCMS releases and maintains dotCMS Docker containers that are the foundation for hosting a dotCMS installation. dotCMS docker is the supported and recommended way to run dotCMS.
The dotCMS-provided container is intended to be used the foundation for your Docker deployments and offer a range of configurable parameters to meet most use cases. All dotCMS web properties run on the official Docker container, including our primary (production) site, our authoring environments, and the dotCMS Demo site.
Images and Versioning
The dotCMS Docker image is publicly available on Docker hub, and can be pulled by using the stable tag
dotcms/dotcms:latest or by the stable tag for a release number — e.g.
docker pull dotcms/dotcms:23.05.
See our Current Releases page for the latest and greatest versions, along with Docker tags and sample Docker Compose YAML files.
Stable vs. Unique Tags
dotCMS Docker images follow the concepts of unique tags and stable tags. A unique Docker tag is an immutable pointer to a build at a given time, which should never change. A stable tag — e.g.,
23.05 — is repointed based on the latest version or minor version of a new release.
All built images should be uniquely (immutably) tagged in Docker hub based on the dotCMS version number followed by an underscore and then the short git commit hash, e.g.
git log -1 --pretty=%h. So, when building, say, 23.05, the action would build the image and uniquely tag it:
or in the case of
and finally push the image and unique tags to Dockerhub.
If we rebuild the 23.01.2 image to include either changes to the Docker build process or to the dotCMS code, it will have a new git hash which would be reflected by a new unique tag — e.g.,
If the docker image you are building is for a new release, we build it and tag normally it with its unique tag and then we update the corresponding stable tags to this new image as well.
In the case of pushing a new Agile Release, say 23.05, we would build our uniquely tagged image
dotcms/dotcms:23.05_e3c7a96e and then point the stable tags:
23.05 to it. If/when we need to push out a point release
23.05.1, we again build a new uniquely tagged image
dotcms/dotcms:23.05.1_cd45d54 and repoint the stable tags
23.05 to this image.
We will maintain a stable tag for
latest; for each “major” agile version, such as
23.05; and for each LTS patch, such as
Repeatable Deployments for Production
When deploying for production, dotCMS recommends to always use a uniquely tagged image so that your image does not change inadvertently during deployments.
Configuration and Plugins
The dotCMS Docker containers have been designed to allow you to configure dotCMS without the need to modify the Docker images, via both configurations and dynamic plugins.
|Configuration||Many configuration options are available without the need for a configuration plugin.|
|OSGI Plugins||With a Docker image, you can load and manage OSGI plugins the same way as you would with any other dotCMS distribution.|
|Static Plugins||Note: Deploying static plugins in a dockerized environment has been deprecated and support will be removed in a future version.|
The dotcms user and group (65001:65001) should own /data/shared/assets and /data/shared/felix/. We don't typically modify the permissions of those directories once they have been created by dotcms. However, as long as the user has rwx and the group has at least rx, it shouldn't be an issue.
The dotcms user should be executing the entrypoint script.
For EFS specifically, we generally use access points and specify the POSIX User and Root directory creation permissions with 65001 for the UID and GID. Additionally, you can use 0755 for POSIX permissions to apply to the root directory path to be safe since only that specific dotCMS environment should be accessing the files in the path anyway.