Last Updated: May 17, 2024
documentation for the dotCMS Content Management System

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., latest or 23.05 — is repointed based on the latest version or minor version of a new release.

Unique Tags

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 23.01.2_lts,


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., dotcms/dotcms:23.01.2_71f7361.

Stable Tags

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: latest and 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 latest and 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 23.01.2.

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.

MethodDescriptionAdditional Information
ConfigurationMany configuration options are available without the need for a configuration plugin.
  • Please see the Docker image documentation to see what options are available. Additionally, most dotCMS configuration variables can be overriden by the use of environmental variables. See changing configuration properties for more information
OSGi PluginsWith a Docker image, you can load and manage OSGi plugins the same way as you would with any other dotCMS distribution.
  • Please see the OSGi Plugins documentation for more information.
Static PluginsNo longer supportedDeployment of static plugins in containerized environments has passed from Deprecated to Not Supported. In modern dotCMS instances, please use OSGi plugins.


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.

On this page


We Dig Feedback

Selected excerpt: