dotCMS is the leading Universal content management system powering thousands of digital experiences for over 150 customers worldwide.
With powerful visual editing tools, multi-tenancy and a tech-agnostic architecture dotCMS empowers technical and content teams to collaborate efficiently and deliver content globally, on any stack, and at any scale.
- BSL Licensed - Generous BSL 1.1 licensing terms makes dotCMS free to use in many cases.
- Universal Visual Editing - Full featured page editing that works both headlessly and for SSR content, in your SPA or for web page rendering and delivery.
- Multi-tenancy - Manage multiple sites in multiple languages, from microsites to brand sites to intranet/extranets or knowledge centers all from a single instance.
- REST & GraphQL APIs - instant endpoints for your all your content
- Search & RAG Built in - dotCMS indexes all content and assets in Elasticsearch for real time search-abiliity and facet based searches. dotCMS can also vectorize all content and assets, offering semantic content searching to power AI applications such as chatbots or knowledge centers.
- Personalization, Rules & A/B Testing - Empower your marketing teams with targeting and content optimizations.
- Cloud, Cloud Anywhere or Self-Hosted - Flexible deployment works with your IT/cloud strategies.
- Feature Rich - Custom content workflows, scriptable APIs, push and static publishing, custom roles and permissions, osgi based plugin architecture. Do more with more.
dotCMS is available as a docker image or as a cloud based product.
dotCMS is licensed under the terms of the BSL 1.1 license and all features are free to use by companies, individuals and organizations whose total finances are below $5,000,000 USD. For more information about the BSL license terms, see the dotCMS BSL FAQ.
For a complete list of requirements, see this page.
| Source | Location |
|---|---|
| Installation | Installation |
| Documentation | Documentation |
| Videos | Helpful Videos |
| Merge Queue | Merge Queue |
| Forums/Listserv | via Google Groups |
| @dotCMS | |
| Main Site | dotCMS.com |
dotCMS GA releases follow CalVer (YY.0M.0D-NN, e.g. 26.06.11-01). On top of that linear
release stream we publish three floating Docker tags — release tracks — so you can pick
how fresh a release each environment receives:
| Tag | Age of release | Use for |
|---|---|---|
dotcms/dotcms:latest |
newest GA (~days) | tracking the latest release |
dotcms/dotcms:standard |
~2 weeks old | a short soak before adopting a release |
dotcms/dotcms:trailing |
~4 weeks old | the most conservative posture |
Pin the track you want in your deployment manifest, e.g. image: dotcms/dotcms:standard, and
you will roll forward automatically as releases age into that track. Pin an exact version
(dotcms/dotcms:26.06.11-01) instead if you never want automatic movement.
One engine (under cicd/evergreen-tracks/) re-points every track tag
by image digest, on two triggers: the release pipeline moves latest on-demand the moment a GA
ships, and a daily scheduled job ages standard/trailing forward. Two design choices are worth
understanding:
- Age is measured from the CalVer date in the version string, not from when the image was
built or published. This protects emergency backports: if we cut a patch of an older
release on short notice, it is built today but logically belongs to the older release line.
Using the build/publish date would make that patch look brand new and let it jump onto the
standard/trailingtracks ahead of releases that are genuinely older. Anchoring to the embedded CalVer date keeps every release in its true place on the timeline. - A track never moves backward automatically, and a release can be "tainted". If a bad
release is found, it is tainted so it will not advance onto tracks it has not yet reached —
a known-bad build can never propagate from
latestdown tostandard/trailing. A track can also be held (frozen) at a specific version for incident response. Both controls live as marker tags in the registry; there is no separate datastore.
GitOps / Argo note: because these tags float (the same tag is re-pointed to newer digests over time), a tag reference alone will not trigger a redeploy. Use Argo CD Image Updater or a periodic rollout refresh to pick up track movements.
The promotion engine and its scheduled/admin workflows live under
cicd/evergreen-tracks/.