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:
dotcms/dotcms:23.05_e3c7a96e
or in the case of 23.01.2_lts,
dotcms/dotcms:23.01.2_lts_c2e012f0
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 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” 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.
| Method | Description | Additional Information |
|---|---|---|
| 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 | No longer supported | Deployment of static plugins in containerized environments has passed from Deprecated to Not Supported. In modern dotCMS instances, please use OSGi plugins. |
Permissions
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.
