dotCMS core: a visual CMS with headless reach and floating release tracks

A visual editor and a headless API in one product

dotCMS describes itself as the Visual Headless Content Management System for Enterprises, and the leading universal content management system powering thousands of digital experiences for over 150 customers worldwide. The positioning is unusual and worth unpacking, because the usual headless CMS asks content teams to give up visual editing and work in structured fields instead. dotCMS keeps the page, with full featured page editing that works both headlessly and for server side rendered content, in your single page app or for web page rendering and delivery. Underneath, the architecture is described as tech-agnostic, and the stated benefit is that content and technical teams collaborate rather than hand work back and forth. The feature list is broad: REST and GraphQL APIs for instant endpoints over your content, custom content workflows, scriptable APIs, push and static publishing, custom roles and permissions, and an OSGi based plugin architecture. The code is Java with a TypeScript front end, and the project ships both a Docker image and a hosted cloud product, with a Cloud, Cloud Anywhere or Self-Hosted deployment choice.

Multi-tenancy, search and retrieval augmented generation

Two capabilities stand out because they are the ones a content platform either has or does not. The first is multi-tenancy, which means managing multiple sites in multiple languages, from microsites to brand sites to intranets and extranets or knowledge centers, all from a single instance. For an organisation running a campaign site, a documentation hub and an internal portal, that is one deployment rather than three. The second is search, and the description is unusually specific. dotCMS indexes all content and assets in Elasticsearch for real time search and facet based searches, and it can also vectorize all content and assets, which is what turns a search box into the retrieval layer for an AI application such as a chatbot or a knowledge center. That is a meaningfully different thing from adding a chat widget, because the content being retrieved is the same content the editors manage. The rest of the feature set covers the marketing side: personalization, rules and A and B testing, with the stated aim of empowering marketing teams to do their own targeting and content optimisation.

The licence is free below five million dollars of finances

dotCMS is licensed under the terms of the BSL 1.1 licence, and the readme states the condition plainly. All features are free to use by companies, individuals and organizations whose total finances are below 5,000,000 USD. That is a different kind of licence from the Apache or MIT grants most open source readers expect, and the difference is not the permissions, which are generous, but the trigger. A project with no revenue cap can be a foundation or a commercial product without a conversation with the vendor. A project with a revenue cap has a conversation with the vendor the moment it passes the line, or it uses the commercial terms. The readme calls the BSL 1.1 terms generous and says they make dotCMS free to use in many cases, and points to the BSL FAQ for the detail, which is where anyone making a procurement decision should read rather than the summary here. The licence file in the repository is the authoritative text, and the project also ships a security file and a contributing guide for people who want to work on the code.

CalVer releases and three floating Docker tracks

The release scheme is calendar versioning, and the shape of the version string is the format YY.0M.0D-NN, with 26.06.11-01 given as the example, which reads as the eleventh of June 2026, first build. On top of that linear stream the project publishes three floating Docker tags, called release tracks, and the readme is clear that the point is to let each environment receive a release of a chosen freshness. The dotcms/dotcms:latest tag is the newest GA release, tracking the latest release, roughly days old. The dotcms/dotcms:standard tag is about two weeks old and is meant for a short soak before you adopt a release. The dotcms/dotcms:trailing tag is about four weeks old and is the most conservative posture. You pin the track in your deployment manifest, for example image: dotcms/dotcms:standard, and you roll forward automatically as releases age into that track. If you never want automatic movement, pin an exact version instead, for example dotcms/dotcms:26.06.11-01. The trade-off is obvious, and worth stating plainly, because it is the kind of thing that is easy to get wrong in a deployment manifest.

Age comes from the version string, and a bad release can be tainted

The promotion engine lives under the evergreen-tracks directory in the GitHub actions, and it re-points every track tag by image digest on two triggers. The release pipeline moves latest on demand the moment a GA release ships, and a daily scheduled job ages standard and trailing forward. Two design choices underneath that are worth understanding, because they are the difference between a promotion system you can trust and one that surprises you. First, age is measured from the CalVer date in the version string, not from when the image was built or published, and the reason is emergency backports. If a patch of an older release is cut on short notice, it is built today but logically belongs to the older release line, and using the build date would make that patch look brand new and let it jump onto the standard and trailing tracks ahead of releases that are genuinely older. Second, a track never moves backward automatically, and a release can be tainted so that it will not advance onto tracks it has not yet reached, which means a known bad build can never propagate from latest down to standard and trailing. A track can also be held, frozen at a specific version, for incident response, and both controls live as marker tags in the registry with no separate datastore to keep in sync. There is a GitOps warning too, since the tags float, a tag reference alone will not trigger a redeploy, and the recommendation is Argo CD Image Updater or a periodic rollout refresh.

The repository: Maven, Node, OSGi and a justfile

The tree shows a large multi-module project and a small number of ways to drive it. The build is Maven, with the wrapper checked in as mvnw, and the front end is a separate build under core-web, with a nodejs-parent module and a web project that uses Angular and Nx, since the build scripts clear the .nx and .angular directories. There is a justfile at the root, and it is the nicest piece of developer ergonomics in the project, a command runner that wraps the long commands with useful aliases. The build target is a Maven install with tests skipped:

./mvnw -DskipTests clean install

and a sibling target clears the front end caches and disables the Maven build cache for when you want a cold build. The justfile also has a dependency check for macOS, install-all-mac-deps, and it notes that running all the tests needs a licence key dropped at a specific path, license.dat under the dotcms licence directory in your home. The tool itself is installed with:

brew install just

The rest of the tree is extensive and shows what a platform product accumulates: a bom for dependency management, an osgi-base module, independent projects, integration and Postman collections, a JMeter and a Karate test suite for performance and end to end checks, an environments directory, a starter project, and an examples directory with Angular, Angular SSR, Vue, Next.js, Astro and Next.js experiment projects, which is the quickest way to see how dotCMS delivers to a front end framework.

Where the project stands

The recent tags are v26.10.13-01 on 2026-10-13 and v26.10.19-01 on 2026-10-19, alongside a separate dotcms-cli release with the same version number, which tells you the command line tool ships in step with the platform. The last push was on 2026-10-20, so the tree is moving daily. The continuous integration badges at the top of the readme name three workflows that describe a mature process, a merge queue, a trunk workflow and a nightly build, which is the standard shape for a project that wants to merge many small changes without a release manager. The repository also carries an onboarding set that is unusual to see, ONBOARDING.md, dotBackendOnboarding.md, dotFrontendOnboarding.md and an Install_dotCMS_Release.md, alongside a .devcontainer, a .mcp.json, an .agents directory and a .claude directory, which shows the project expects both new contributors and coding assistants to work in it. The license file in the root is the one to read before a commercial deployment, since the summary above is a simplification of what the BSL actually says.

Editorial conclusion

dotCMS is a good fit for an enterprise team that wants editors working visually while delivery happens through APIs and single page apps, and that needs several sites and languages from one instance. It is the wrong choice if you need a permissive licence with no revenue condition at all, and it is the wrong choice if you want a headless CMS with no visual editing layer. Before you deploy, decide which floating track you want, pin an exact version if you cannot tolerate automatic movement, and read the BSL FAQ rather than the summary.

Frequently asked questions

Official sources

1. dotCMS/core on GitHub
2. Issues
3. Project website
4. README
5. Releases