dotCMS

Content types are built on base types (Content, Page, File, Widget, dotAsset) with 22 documented field types, including JSON, Key/Value, Block Editor (storyblock), Relationship, Category, Tag, Site-or-Folder, Date/Time and Custom fields rendered with Velocity or React. Types can be managed in the UI, through the Content Type REST API and pulled/pushed as files through the dotCMS CLI, which gives a practical schema-as-code path. Held below 75 because there is no union/polymorphic field type and min/max or enumeration constraints exist only through select/radio values or regex.

Relationship fields support one-to-one, one-to-many, many-to-one and many-to-many cardinality, self-relations, multiple relationships between the same two types, and linking an 'existing' relationship onto the second type so it is editable and queryable from both ends. Relationships are searchable and resolve in REST depth queries and GraphQL; the September 2026 release rebuilt the relationship picker on the shared search surface. Not 80+ because each relationship targets a single content type (no polymorphic references) and the model is not graph-native.

The Tiptap-based Block Editor stores content as JSON blocks and can embed any contentlet (dotContent), images, videos, tables and a two-column Grid block whose columns hold arbitrary blocks; per-field Allowed Blocks restrict what editors can insert, and Block Editor v3 (beta in 26.05.08-01) added a slash menu and richer table editing. Pages compose contentlets into containers within layout rows and columns. Capped at 70 because nesting depth is shallow (a fixed two-column grid, no recursive component trees) and composition on pages is bound to the container/template model.

Fields support required, unique and a validation regex with eight presets (email, numbers, letters, alphanumeric, US zip, US phone, URL, no HTML) plus free-form custom expressions; select/radio/checkbox fields constrain values to a list and Image/File fields and asset pickers enforce allowed file types. Anything beyond that, such as cross-field rules, means custom fields, workflow Velocity sub-actions or OSGi actionlets written by developers. Standard built-in validation with code-level extensibility puts it at 60.

Every save creates a new version (same identifier, new inode) with a History tab showing author and date, and any version can be viewed, deleted or restored; publish and expire dates plus schedule-enabled workflow steps handle timed publishing, and the UVE's Future Time Machine previews how a page will look on a future date. Versions are reachable through the Content API by inode. Held at 72 because there is no content branching and no side-by-side field-level diff in the editor.

The Universal Visual Editor gives marketers drag-and-drop placement from a Content Palette (existing contentlets or new ones by type), drag-to-reorder within containers, layout editing, inline WYSIWYG and Block Editor editing, Quick Edit, a per-content-type Style Editor, persona and language switching, and device previews, and it works the same for traditional and headless (Next.js, Angular, React) front ends; the Real-Time Canvas arrived in 26.04.20-01. Not 80+ because layout changes stay within template rows and containers that developers define, and the September 2026 releases were still fixing canvas regressions in headless mode.

The Block Editor (Tiptap/ProseMirror) stores rich text as a documented JSON node tree with embedded contentlets, images, videos, tables, grids and dotAI generation blocks, and the React and Angular SDKs ship block renderers with per-block overrides, including a new native Angular renderer that emits clean semantic HTML (26.06.01-01). The classic TinyMCE WYSIWYG field with an accessibility checker remains for HTML use. Just short of 75 because custom node types require a remote extension rather than configuration, and several 2026 releases fixed data-loss bugs on unknown marks and links.

Files are content: File Assets and dotAssets carry custom fields, extracted metadata, permissions and workflow, organized in folders and tags and browsed through the new Content Drive (bulk upload, folder duplication and status filters added August to October 2026). The Image API transforms by URL, with resize, crop, a focal point parameter, WebP conversion, browser-aware auto-compression and other filters, and there is an in-browser image editor. Held at 74 because AVIF output is not documented and there is no responsive variant or DAM-grade rights management.

Content uses explicit locking (lock/unlock in the editor, a Locked status filter in Content Drive), so a second editor cannot overwrite someone else's checked-out item, and workflow actions can require comments that build an audit note on the task. There is no simultaneous co-editing, no presence indicators and no inline commenting on fields. Pessimistic locking plus workflow comments lands it just above last-write-wins.

Workflow Schemes are assigned per content type and hold any number of steps and actions, with role- and permission-gated actions, sub-actions (multiple approvers, push publish, set value, translate, Velocity script), tasks with assignment and comments, schedule-enabled steps that escalate or act automatically, a workflow REST API, and workflow execution from inside the UVE. This is among the more configurable editorial workflow engines in the dataset. Not higher because conditional branching is built from sub-actions and scripts rather than a visual designer.

dotCMS exposes both REST (Content API with Lucene/Elasticsearch queries, depth-resolved relationships, Page API returning full layout as a service, Navigation API) and GraphQL with typed collections, page/offset pagination with a Pagination type, sorting and language filtering; the September 2026 release made Image and File fields interface-typed in GraphQL. The SDK client wraps both. Kept at 76 because delivery and management share one authenticated API layer with no separate read-only delivery contract, and filtering is Lucene strings rather than typed arguments.

dotCMS Cloud customers get the dotCDN service with cache invalidation wired to push publishing, and docs give header guidance and a Velocity scriptlet for URL purges with other CDNs; static push publishing to S3 is also an option. Self-hosted installs (hostingModel is Both) bring their own CDN and must build invalidation themselves. Held at 62 because there is no documented tag-based or sub-second purge and no edge compute or edge-side personalization.

dotCMS's own webhook documentation has outbound calls built as a Velocity Script sub-action on a workflow action ($json.fetch / $json.put) or as push-publish listeners and OSGi actionlets, which ties them to whichever workflow actions an admin edits. Internal system events exist and were made reliable in clustered installs in September 2026. There is no webhook registry, event catalog, HMAC signing, retry policy or delivery log, which puts it at the low end of the basic band.

dotCMS is API-first with traditional Velocity rendering alongside: content is reachable through REST and GraphQL, Block Editor output is JSON, and official JavaScript SDKs cover a client library, React, Angular, UVE, types and the new unified @dotcms/events package (26.10.07-01), with an alpha PHP SDK and example projects for Next.js, Astro, .NET, Laravel, Symfony and Spring Boot. Above the 'traditional CMS with API added' band, but held at 66 because the maintained SDKs are web/JavaScript only, with no native mobile SDKs, and the Page API remains page-centric.

dotCMS ships native Personas (with key tags and tag-based visitor scoring) and a Rules engine that evaluates request conditions such as geolocation, referrer, page visits, cookies, device and visited URLs to assign personas in real time. That is a genuine CMS-side segmentation engine, but it is rule- and session-based with no firmographic data, no unified profile store and no packaged CDP connector, so it stays below 70.

Containers on a page can be personalized per persona, so editors place different contentlets for each persona and preview each variant in the Universal Visual Editor with the persona switcher; the Rules engine adds redirects and header actions. This is native, editor-facing variant delivery, but targeting is limited to personas rather than arbitrary segment logic per component, which keeps it in the low 60s.

dotCMS Experiments provides built-in A/B testing of page variants created in the editor, with traffic allocation, goals (such as bounce rate, exit rate, reaching a page or clicking an element) and Bayesian results reporting. It depends on the dotCMS analytics infrastructure, which has historically meant dotCMS Cloud only, and there is no multivariate testing, so it sits just under 70.

There is no built-in algorithmic recommendation engine for content; related content is assembled from tags, categories and relationships through Velocity or API queries, optionally weighted by persona tags. Semantic similarity through dotAI embeddings belongs to AI enablement and is not counted here. Tag-driven curation with no ML lands at the top of the manual band.

Every dotCMS install runs on an embedded Elasticsearch/OpenSearch index: content is queryable with Lucene syntax and raw ES queries (including aggregations for facets) through the Content and ES Search APIs, and a Site Search tool crawls and indexes rendered pages on a schedule. Faceting and relevance control are available but have to be built into queries by developers, with no merchandiser-style relevance tuning or autocomplete UI, which holds it below 70.

External search engines can be fed through workflow sub-actions, push-publish listeners or OSGi plugins, and the exposed ES query endpoint lets teams build on the built-in index. No official, maintained Algolia, Coveo or similar connector with documented sync patterns is known, and dotCMS lacks a first-class webhook service, so this is custom-integration territory.

dotCMS has no product catalog engine, cart, checkout, pricing or inventory; commerce is positioned as an integration use case. It scores at the floor band for platforms without commerce features.

dotCMS positions itself for headless commerce storefronts and partners have built Shopify, Salesforce Commerce and commercetools integrations, but no maintained first-party connector with a product picker or live API federation is documented. Integrations are custom builds over REST, GraphQL and OSGi, which places it below the product-picker band.

The flexible content type system (22 field types, relationships, categories, key/value and JSON fields, file and image fields) can model product content with variants and rich attributes, and multilingual versions apply. These are generic content types repurposed for products with no product-specific patterns or SKU linkage, so it fits the 40 to 55 band.

dotCMS Content Analytics collects page views, sessions, events and conversions into a hosted analytics store and surfaces dashboards and a query API, and it powers Experiments reporting. It is tied to dotCMS Cloud and is younger and lighter than dedicated analytics, with little author productivity or content health reporting, so it lands in the low 50s.

GA4, GTM and similar tags are added through templates, Velocity or headless front ends, and the Rules engine can set headers or cookies for tracking. There is no packaged GA4, Segment or Amplitude connector and no content-operations event stream beyond workflow scripts, which keeps it in the webhook/custom band.

Multi-tenancy is core to dotCMS: one instance runs many Sites, each with its own folders, templates and permissions, while the System Host lets content types, containers and contentlets be shared across all sites and content can be related across sites. Site variables, thumbnails and a site switcher are standard. It is a strong native model, held at 80 because cross-site governance relies on permission inheritance rather than dedicated dashboards.

Languages are first-class: each contentlet can have a version per language under one identifier, with per-language publishing, workflow and a default-language fallback that is configurable separately for content, pages and widgets; Language Variables handle UI strings. Translation is document-level rather than field-level (non-translatable fields are not shared automatically), so it sits at the top of the document-level band.

A Translate workflow sub-action machine-translates contentlets into target languages through a configured translation service, and content can be exported and imported for manual translation. No official Phrase, Smartling, Lokalise or Crowdin integration is documented, so TMS connections are custom builds.

Brands map to Sites, with shared content types, containers, themes and templates on the System Host, hierarchical role permissions and per-site workflow schemes. That gives central control of building blocks and access, but there is no cross-brand policy dashboard or brand-level approval orchestration, so it sits above the organization-level band without reaching native governance tooling.

Assets are contentlets (File Assets and dotAssets) with custom metadata fields, extracted file metadata, tags, folders, full version history, permissions and workflow, browsed and bulk-uploaded through the new Content Drive. That covers library, metadata schemas and versioning, but rights and expiry management are limited to generic publish/expire dates and usage tracking across content is weak, so it stops short of 70.

The Image API transforms on the fly by URL, with resize, crop, focal point, WebP conversion, quality and browser-aware auto-compression filters, and dotCMS Cloud fronts delivery with dotCDN. AVIF is not documented, responsive srcset generation is left to the front end, and self-hosted installs bring their own CDN, so it falls just below 70.

Video and audio files can be stored as assets and embedded through the Block Editor video block, but there is no native transcoding, adaptive bitrate streaming or captions management. Real video delivery means YouTube, Vimeo or a video platform, which places it in the no-native-video band.

The Universal Visual Editor provides drag-and-drop from a Content Palette, reordering within containers, layout editing, inline editing, a Style Editor, device and persona previews and the Real-Time Canvas, and it works for both Velocity sites and headless Next.js, Angular and React front ends. Layout freedom is bounded by developer-defined templates and containers, which keeps it just under 80.

Workflow Schemes per content type support unlimited custom steps and actions, role and permission gating, task assignment with comments, a multiple-approvers sub-action, schedule-enabled steps that escalate or act automatically, notifications, a workflow history on each task and a REST API. This is among the most configurable approval engines in the dataset; it misses 80 for lack of a visual designer and native SLA due dates.

Content types can carry publish and expire date fields for scheduled go-live and auto-unpublish, schedule-enabled workflow steps automate timed actions, Push Publishing bundles move many items atomically to receiving environments, and Future Time Machine previews a page at a future date. There is no editorial calendar view, which keeps it below 70 despite strong embargo and bundle support.

Collaboration relies on explicit content locking, workflow task comments and per-version author history. There is no simultaneous co-editing, no presence indicators and no inline field comments or mentions, so it is only slightly above the locking-only band.

dotCMS includes a Form Builder where forms are content types, submissions are stored as contentlets with workflow (email notification, push to external systems via script sub-actions), and reCAPTCHA can be added. Conditional logic, multi-step forms and progressive profiling are not native, which keeps it in the basic form builder band.

dotCMS can send transactional email from workflow sub-actions and Velocity, but there is no native campaign email and no maintained connector for HubSpot, Marketo, Salesforce Marketing Cloud or Mailchimp. Email content reuse relies on API pulls built by the team.

The Rules engine can react to visitor behavior on the site (set persona, redirect, set header), but there are no drip campaigns, lead scoring, nurture flows or lifecycle stages, and no packaged automation-tool integration. That is minimal automation capability.

Visitor context lives in session-level personas and Rules, and Content Analytics captures events, but there is no packaged Segment, Tealium, mParticle or Salesforce Data Cloud integration that syncs profiles or audiences into personalization. CDP connections are custom work.

dotCMS offers an Apps screen with a modest set of first-party integrations (such as dotAI, SAML, Google Translate and analytics configuration) and OSGi plugins published on GitHub, plus a small partner network. There is no large, browsable marketplace of installable third-party apps, which places it in the small-directory band.

Outbound calls are built as Velocity Script sub-actions on workflow actions, push-publish listeners or OSGi actionlets, so any workflow event can trigger them but each must be scripted. There is no webhook registry, event filtering UI, signed payloads, retries or delivery logs, so it sits at the top of the basic band.

The Universal Visual Editor previews draft content inside headless front ends configured per site, with persona, language, device and Future Time Machine previews, and Push Publishing promotes content between authoring and receiving environments. Shareable external preview links and per-branch preview environments are not first-class, which holds it in the good-draft-preview band.

dotCMS has a granular, inheritable permission model on sites, folders, content types and individual contentlets with hierarchical custom roles, workflow action permissions and SAML/OpenID SSO through the Apps screen. Field-level permissions and SCIM provisioning are not available, so it sits at the top of the content-type ACL band rather than above 70.

dotCMS exposes a broad REST surface (Content API, Page API / Layout as a Service, Workflow REST, Navigation, Content Type REST) plus a GraphQL endpoint with pagination, collections and a playground, and an Elasticsearch query passthrough. Release v26.09.28-01 moved GraphQL Image and File fields to interface-based types, showing the schema is still being refined. Held at 70 because querying still leans on Lucene syntax and there is no dedicated, purpose-built delivery API separate from the authoring APIs.

dotCMS Cloud fronts delivery with dotCDN and push-publish listeners handle cache invalidation, and Cloud Anywhere runs on an autoscaling Kubernetes cluster. No published rate limits, latency targets, pagination ceilings or delta/sync API for large-dataset incremental pulls were found (dev.dotcms.com/docs/rest-api-limits returns 404). Self-hosted CDN integration is left to the customer, so this sits in the adequate-but-undocumented band.

Official SDKs are JavaScript-family only but actively maintained and versioned in lockstep with the platform: @dotcms/client, @dotcms/react, @dotcms/angular, @dotcms/uve, @dotcms/types (latest 26.10.8-1) and the new @dotcms/events (v26.10.07-01); @dotcms/client pulls about 14.4k npm downloads a month. A PHP library exists but is labeled alpha, and .NET, Laravel and Symfony coverage is example projects rather than SDKs. Two official language ecosystems at best keeps this in the 55 to 60 band.

dotCMS has no public integration marketplace: dotcms.com/marketplace resolves to the homepage. Pre-built integrations are delivered through the in-product Apps tool (SAML, dotAI, and a small set of service connectors) and OSGi plugins published in the dotCMS GitHub organization. No first-party commerce, ESP, TMS or CDP connectors were identified, so coverage gaps across key categories keep this below 50.

The OSGi plugin framework lets teams hot-deploy custom REST endpoints, workflow actionlets, viewtools, servlets and portlets without a rebuild, and Velocity scripting endpoints add server-side logic in-app. Custom fields can be built in React and the UVE supports headless front-ends, giving UI extension points. Held below 75 because UI extensions are limited to custom fields and portlets rather than a sandboxed app framework with sidebar widgets, and custom Block Editor blocks need remote extensions.

SAML SSO is configured through the SAML App with documented guides for Okta, Azure AD, Google, Amazon, RSA and Shibboleth, supports per-site configuration and maps IdP roles onto dotCMS roles; LDAP/Active Directory is also supported, MFA is advertised, and REST calls use JWT API tokens scoped to the issuing user. SAML is delivered as an Enterprise App and no native OIDC or SCIM provisioning was found, keeping this in the Enterprise-gated band.

dotCMS has one of the more granular permission models in the traditional DXP set: custom roles, permission inheritance down the site and folder tree, and per-object permissions on individual contentlets, pages, templates, forms and sites, with the same model enforced on REST responses and on AI agents. The security page claims access can be restricted to field level, but no field-level permission documentation was found, so this stays just below 80.

dotCMS holds SOC 2 Type II (security, availability, confidentiality; report via the Trust Center), ISO/IEC 27001:2022, ISO/IEC 42001:2023 for AI governance and TX-RAMP Level II, publishes a CSA CAIQ, and maintains a GDPR policy and HIPAA-ready healthcare positioning. Cloud Anywhere lets customers deploy in the AWS, Azure or GCP region of their choice for residency. This clears the 80+ bar; a published HIPAA BAA and FedRAMP were not found.

dotCMS publishes a Responsible Disclosure Policy and a Known Security Issues page and issues its own CVEs, which is good communication practice. However, NVD lists a run of critical vulnerabilities in the past 14 months: CVE-2025-8311 (9.4, blind SQLi in /api/v1/contenttype), CVE-2025-11165 (9.9, Velocity sandbox escape), CVE-2026-8054 (10.0, SQLi in Publish Audit API) and CVE-2026-16337 (9.4, improper authorization in ToolGroupResource/RoleAjax, 21.02 through 26.06.22), following the 2022 unauthenticated file-upload RCE. No bug bounty program was found, so the recent critical-CVE cadence is penalized significantly.

Three deployment models: dotCMS Cloud (fully managed on dotCMS's AWS infrastructure since 2009), Cloud Anywhere (fully managed by dotCMS inside the customer's own AWS, Azure or GCP sub-account and region), and self-hosted on-prem or in any cloud, all under the same certified governance model. Customer-owned managed hosting is a strong answer for regulated buyers, which lifts this above the standard both-available band.

Cloud Anywhere advertises a 99.95% uptime SLA with 24/7 monitoring, and dotCMS Cloud runs multi-node environments behind redundant load balancers and firewalls. A public status page could not be reached (status.dotcms.com did not resolve) and the dotCMS Cloud SLA terms are not published, so incident transparency is unverified. Self-hosted customers own their own uptime.

dotCMS runs clustered authoring and delivery tiers, Cloud Anywhere uses an autoscaling Kubernetes cluster with shared database, search and file storage scaling across environments, and dotCDN handles edge delivery. dotCMS cites one healthcare customer running 500+ websites on a single install, a credible multi-site scale reference. No documented scale limits (entries, requests per second) were found, keeping this below 75.

dotCMS Cloud takes full daily backups shipped over a private connection to a geographically separate secondary data center, regularly tests restores, and maintains a BCDR plan rehearsed annually with tabletop and simulated recovery exercises. Content can be exported via dotCLI pull and push-publishing bundles. RTO and RPO figures are not published (the Business Continuity Plan is available only on request), so this sits just below 75.

dotCMS ships official Docker images and compose files so developers can run a full local instance, and the dotCLI (npm install -g @dotcms/dotcli) pulls and pushes content types, sites, languages and files between a local workspace and any instance, including a watch-based files push loop. Held below 80 because the local stack is a full Java app server with database and search, which is heavy compared with lightweight emulators.

dotCLI workspaces store content types, sites, languages and files as files that can live in a GitHub repo, with a documented GitHub integration and token plus URL flags for headless pipeline use. Push publishing moves content and configuration between dev, authoring and production environments, and Cloud Anywhere deploys via GitOps with a minimum of three environments. There are no schema migration scripts, environment aliasing or branch-per-PR content environments, which caps this in the mid-60s.

dev.dotcms.com is comprehensive, organized into Author, Build, Manage and Reference sections with an AI docs assistant, detailed CLI and permission references, and example projects for Next.js, Astro, Angular, .NET, Laravel and Symfony. Docs mix current headless guidance with legacy Velocity-era pages and some advertised items (field-level permissions, rate limits) have no doc page, so this lands at the top of the adequate band rather than 80+.

The JS SDKs are written in TypeScript and the shared @dotcms/types package (26.10.8-1) supplies typed page, contentlet and UVE models across the React and Angular libraries. No type generation from a customer's content model was found, so developers hand-write content type interfaces, which keeps this in the typed-SDK-without-codegen band.

dotCMS ships continuously from a public monorepo: the GitHub API shows tagged core releases several times a week (v26.09.02-01 through v26.10.08-01, roughly 15 core tags in five weeks, each paired with a dotcms-cli release) and 261 merged pull requests since September 1, 2026. These carry real feature work, not only fixes: the Real-Time Canvas in the Universal Visual Editor (April 2026), Java 25 container images (from February 2026), the MCP Server for agents, and the @dotcms/events SDK (v26.10.07-01). Held below 85 because many tags are small increments and the headline feature drops arrive a few times a year.

dotCMS publishes a structured Current Releases page on dev.dotcms.com showing its evergreen Docker tracks (Latest, Standard, Trailing) alongside the supported LTS lines and their end-of-life dates. Each GitHub release also has its own notes tied to issue numbers. That is clearly navigable, versioned history, well above a blog-only changelog. Held at 70 because the daily-tag model makes the notes granular and noisy, and per-release breaking-change callouts with linked migration guides were not consistently evident.

Development happens in the open: the dotCMS/core issue tracker is public, with 771 issues opened since July 2026, so anyone can see what is in flight. dotCMS also announces direction ahead of delivery, for example a Java 25 roadmap in December 2025 followed by test images in February and a migration deadline of June 1, 2026. Held below 70 because there is no public roadmap page or feature-voting portal; the issue tracker shows near-term work, not a product roadmap buyers can plan against.

dotCMS runs a dual-track model that suits risk-averse buyers: LTS lines are supported for at least 18 months, with patch releases built to install with minimal risk, often with no downtime on clusters. Those patches deliberately exclude any change that alters existing behaviour (25.07.10 LTS reached patch v19 on September 30, 2026). Evergreen users can pin to the Standard or Trailing Docker tracks for a stabilisation buffer, and the Java 25 move was signposted months ahead with test images. Not higher because there is no automated migration tooling or codemods, and the date-based versioning does not signal breaking changes the way semver does.

The footprint is modest for a platform this old: the dotCMS/core repo has 971 stars and 488 forks, Stack Overflow has only 101 questions under the dotcms tag, and the headless SDK draws about 14,400 monthly npm downloads for @dotcms/client and 12,200 for @dotcms/react. That sits just above the sub-45 'very sparse' band; the healthy fork ratio and steady SDK use keep it out of the bottom tier, but it is well short of the 5K-star mid band.

Activity is high but mostly vendor-driven: GitHub is busy (771 issues opened and 370 closed since July 2026, 100+ contributors on record), yet most of that throughput is dotCMS staff working in the open rather than outside contributors. The public Discourse forum at community.dotcms.com is close to dormant: its about.json reports zero posts and zero active users in the last 30 days, and the latest topic dates from July 2026. No Discord or Slack community surfaced. Scored in the mid-40s for that reason.

dotCMS runs a formal partner program with a public directory split into Solution Partners and Technology Partners, listing around fifteen implementation firms. These include agencies inside Publicis Sapient and Omnicom Precision Marketing Group, DACH and UK specialists, and boutique migration shops, plus co-built integrations such as DSS Partners' Intershop connector. That gives buyers real options in North America and Europe. Capped at 55 because the directory is small, shows no tiered certification levels, and names no tier-one global SIs directly.

Almost all learning material comes from dotCMS itself, through dev.dotcms.com docs, its blog, and the vendor-seeded forum. The 101 Stack Overflow questions and lack of any widely known Udemy or Pluralsight course or independent YouTube series point to a thin independent content base. Third-party coverage is mostly partner marketing and analyst mentions. Scored in the high 30s: the first-party docs are good, but independent validation is sparse.

dotCMS development needs Java, Velocity and OSGi plugin skills for traditional builds. That is a niche combination, and the small Stack Overflow footprint suggests few developers list dotCMS experience. The headless SDKs (@dotcms/client, React, Angular) let generalist front-end developers contribute without platform knowledge, and the free BSL tier for small companies plus the 2025 Pakistan developer hub are attempts to widen the pool. Scored as niche: hire-ready dotCMS specialists are scarce and buyers will usually rely on partners.

dotCMS keeps an established enterprise and public-sector base, citing Royal Bank of Canada, White Castle, World Travel Holdings and Caliber. In 2026 it added compliance credentials that open regulated deals: TX-RAMP, ISO/IEC 27001:2022 and ISO 42001 certification, and a SOC 2 Type II renewal. G2's Summer 2026 badges suggest steady recent review inflow. Held in the mid-50s because no headline new-logo announcements or customer-growth figures from 2025–2026 were found.

dotCMS is a long-running private company, active since the early 2000s, with no recent funding round, acquisition or layoff news surfaced in this run. It shows the habits of a steady, self-sustaining vendor: daily engineering output, paid audits for ISO 27001, ISO 42001, SOC 2 and TX-RAMP, and continued product leadership hires. The move to a Business Source License with free use under $5M total financing is a commercial bet on growth that also narrows open-source freedom. Scored at the stable-but-unfunded midpoint, with low confidence because funding and headcount could not be verified.

dotCMS now positions itself sharply as 'the enterprise CMS for compliance-led organizations', backed by its stack of security and AI-governance certifications. It pairs that with a two-layer agentic AI story: dotAI inside the CMS, and an MCP Server plus APIs that expose the CMS to agents. Its 2025 IDC MarketScape for AI-enabled headless CMS rates it a Major Player, but it does not appear in the current Gartner Magic Quadrant or Forrester Wave for DXP, and its awards page cites no such placement. Held at 55: the niche is coherent and defensible, but analyst recognition is limited to a Major Player rating.

G2 shows dotCMS at 4.1 stars from 118 verified reviews, which puts it in the 45–60 formula band. Within that band, recent signals are positive: six G2 Summer 2026 badges including Best Support (Mid-Market), Best Estimated ROI (Enterprise and Mid-Market) and Fastest Implementation (Mid-Market). Scored mid-band because the headline rating trails peers in the 4.3–4.5 range and review volume is modest, and Gartner Peer Insights and Capterra could not be read directly to cross-check complaint themes.

dotCMS publishes a four-tier matrix (Starter, Professional, Business, Enterprise) with concrete included allowances per tier: 100K/500K/2M/10M requests per month, 1/5/15/50 TB bandwidth, 99.5% vs 99.9% SLA, 8/6/4 hour support response times and the full add-on catalogue. Every tier still ends in 'Request Pricing' and every add-on cell shows a '$' placeholder rather than a figure, so no buyer can price a deal from the page. Clearly above a bare contact form, but short of the public-lower-tier band because not a single dollar amount is published.

The model is tiered with clear included limits and unlimited users and roles at every tier, which avoids seat creep. Pricing is driven by 'scale (typically number of sites or content types)', with metered add-on blocks for extra sites, every 10 content types, 1M requests, 0.5 TB bandwidth and 1 TB storage, plus per-environment charges, so growth in content modelling or traffic steps the bill up in increments. Charging per content type is an unusual axis that penalizes good content modelling, and the page's 'no surprise costs' line is only partly borne out by the overage blocks.

The BSL build ships every feature with no community versus enterprise split, and dotAI core and unlimited users are included at all commercial tiers. But the commercial matrix gates basic production security: SSO/SAML is 'Not available' on Starter and a paid annual add-on on every other tier including Enterprise, IDP support is an add-on on Professional, and dotCDN plus the WAF are absent from Starter. Content Analytics and Experiments are flagged as a future paid add-on. SSO sold separately at every tier is exactly the gating pattern buyers object to.

Every add-on on the pricing page is quoted per year, there is no self-service checkout or monthly option, and no subscription agreement or cloud terms are published (dotcms.com/subscription-agreement and /terms-of-service both return 404), so renewal and termination terms cannot be checked. The BSL Additional Use Grant acts as a de facto startup and small-organization program, giving free production use to anyone under $5M in total finances, and large organizations may use it free outside production. No separate nonprofit or education pricing was found.

Under BSL 1.1 dotCMS is free forever, with full features, unlimited users and unlimited content, for production use by any individual, small business or agency under $5M in total finances, and free in non-production for organizations of any size; each version converts to GPLv3 four years after release. That is permanent and commercially usable, which is generous for a Traditional DXP. Held below 65 because it is self-hosted only (no managed free tier), support is community-only, and the $5M threshold counts the finances of any commercial beneficiary, so an agency building for a larger client loses eligibility.

A single documented 'docker run' of the dotcms-dev image brings up dotCMS with Postgres and OpenSearch pre-wired, and the same image can clone the public demo site, so a developer has a populated CMS and its REST and GraphQL APIs within an hour. The developer docs also offer Next.js and other headless SDK starters. It stays below 75 because the image is heavy (JVM plus database plus search), first real page work means learning dotCMS content types, Velocity templating or the Universal Visual Editor wiring, and the BSL page's compose alternative runs on a different port, which adds small friction.

No community-reported project timelines could be gathered this run, so this is inferred from the platform's shape. dotCMS targets multi-site, compliance-led enterprise programs (one healthcare customer runs 500+ sites on a single install) where environment setup, workflows, permissions and push-publishing topology add weeks, while the visual editor, demo-site starter and headless SDKs shorten a simple marketing build. A mid-band score typical of a mid-market Java DXP fits better than either the fast headless band or the six-month-plus enterprise suite band.

Headless front ends built with the dotCMS SDKs for React, Next.js and Angular use mainstream skills, but server-side work still means Java, OSGi plugins, Velocity templates and dotCMS workflow and push-publish configuration. The talent pool is small: the Stack Exchange [dotcms] tag holds about 101 questions and the vendor points buyers to its own community job board to find an experienced dotCMS developer. That puts the premium in the moderate-to-high range for anything beyond a headless front end.

dotCMS Cloud tiers bundle hosting with published request and bandwidth allowances, and CDN plus WAF from Professional up, but extra environments, requests, bandwidth and storage are sold as add-ons and node, CPU and memory sizing is quoted from separate 'cost inputs'. Cloud Anywhere includes the licence but the customer pays its own AWS, Azure or GCP bill. Self-hosting under BSL means running a JVM application server, PostgreSQL and an OpenSearch cluster plus your own CDN, a meaningful infrastructure footprint.

On dotCMS Cloud or Cloud Anywhere, dotCMS engineers handle deployment, monitoring, upgrades, patching, backups and support behind a 99.95% SLA on Cloud Anywhere, so ops overhead is low for buyers who pay for managed hosting. Self-hosted BSL users carry the full burden of a Java, PostgreSQL and OpenSearch stack plus frequent Evergreen release upgrades. Because the free path, which is a big part of the pitch to smaller organizations, is self-hosted, the likely deployment mix lands mid-band.

Content and schemas can be pulled to local files with the dotCMS CLI workspaces and retrieved through REST and GraphQL, a full database and asset dump is available through the clone tooling, the source code is available and converts to GPLv3 after four years, and Cloud Anywhere keeps the infrastructure and data in the customer's own cloud account. Exit still means rebuilding Velocity templates, workflow definitions, Rules-based personalization and push-publishing setups elsewhere, and with no published subscription terms there is no documented data-return window for dotCMS Cloud.

A full dotCMS build means learning sites and the System Host, folders, content types and their base types (content, page, file, dotAsset, widget, form, persona), containers, templates and themes, workflow schemes, push publishing and Lucene-style content queries. The headless path cuts this down to content types, pages, layouts and UVE component mapping, which fit mainstream mental models better. Lighter than AEM or Sitecore XP, but well beyond the handful of concepts a headless CMS asks for.

dev.dotcms.com is organised into Overview, Author, Build and Manage tracks with a Getting Started section, an Ask AI assistant, per-framework example guides (Next.js, Astro, Angular, .NET, Laravel, Symfony) and a public demo site with published admin credentials to experiment against. There is no interactive in-console onboarding tour or structured certification path comparable to the leading headless vendors, so it sits at adequate-plus rather than best in class.

Headless builds use standard REST and GraphQL APIs with official TypeScript SDKs for React and Angular, and the Next.js example uses the App Router with server rendering. The traditional side is Java, Velocity templates, OSGi plugins and Lucene query syntax, and some delivery still runs through dotCMS-specific page and layout APIs. Mostly mainstream for headless frontend teams, proprietary for anything server-side.

`npx @dotcms/create-app` scaffolds Next.js, Astro, Angular or Angular SSR projects, can start a local dotCMS Docker stack with starter content, configures UVE and writes the .env for you. The Next.js example is TypeScript, maps one React component per content type and is deployed live on Vercel against the demo site. Not higher because create-app is still labelled beta, there is no Nuxt, Vue or SvelteKit starter, and examples carry no CI/CD config.

A headless integration needs three environment variables (host, read-only API token, site ID) plus a one-line UVE app config, and create-app automates all of it, including a bundled docker-compose stack for local work. The catches are that every @dotcms/* package is versioned in lockstep with the server, so non-Evergreen and LTS instances must pin versions or hit GraphQL FieldUndefined errors, and self-hosted production still means configuring a Java app server with PostgreSQL and OpenSearch.

Content types can be pulled and pushed as files with dotCLI, so schema can live in source control, and additive field changes are routine. Field types cannot be converted after creation, each relationship field targets a single content type, there are no union or polymorphic fields, and there is no migration tooling to transform existing content when a model changes, so breaking changes mean scripting against the REST APIs.

The Universal Visual Editor renders the real headless frontend inside dotCMS for in-context editing, drag and drop and persona or language switching, and the React and Angular SDKs supply the page, container and contentlet components that wire it up. Setup is a JSON pattern-to-URL app config that create-app writes automatically, but each content type still needs a mapped frontend component and edit-mode handling, so it is well documented rather than plug and play. Velocity-rendered sites get in-context editing with no extra work.

Generalist React, Next.js or Angular developers can build a headless dotCMS frontend from the examples without certification. Anything server-side, such as custom workflow actions, OSGi plugins, Velocity templates or Lucene query tuning, needs dotCMS-specific Java knowledge, and that talent pool is small. Less specialised than AEM or HCL, more than a headless CMS.

On dotCMS Cloud a small team of two to four (frontend developer, someone owning content modelling and workflow, project lead) can ship a site, and a solo developer can stand up a local stack with create-app. Self-hosted production adds Java, PostgreSQL and OpenSearch operations, and multi-site enterprise rollouts with push publishing across environments need more people. Smaller teams than AEM or Sitecore XP, larger than a headless CMS project.

After go-live editors create pages, choose templates, drag content from the Content Palette into containers, set persona and language variants and schedule publishing in the UVE without developers, including on headless frontends. New content types, containers, templates and frontend components still need developers, and containers bound what editors can rearrange, so self-service is strong but not unlimited.

dotCMS Cloud environments now update automatically on Evergreen Tracks (Latest, Standard at 14 days, Trailing at 28 days) as in-place rolling updates with zero downtime every other week, and self-hosted Evergreen updates are a Docker image tag swap because dotCMS upgrades the database schema and data automatically on startup. The self-hosted procedure still asks for a content freeze and scaling to a single node (rolling upgrades are 'not tested'), and LTS or long-gap upgrades remain projects: the Cloud full-upgrade path builds parallel environments with roughly six weeks of customer testing and custom plugin fixes left to the customer. Higher than typical self-hosted Java DXPs because of the Evergreen automation, below SaaS because LTS customers and plugin-heavy builds still carry real upgrade work.

Cloud customers get security fixes automatically through their Evergreen track, and LTS lines receive backported fixes until end of life (the 25.07 LTS line reached its nineteenth patch release on 2026-09-30). Evergreen self-hosted customers get no backports at all: security patches ship only in newer releases, so staying patched means updating at least monthly. NVD lists four dotCMS CVEs since 2025, including a blind SQL injection in the content type API, a Velocity sandbox escape, a SQL injection in the Publish Audit API and an improper-authorization privilege escalation affecting 21.02 through 26.06.22-03; dotCMS keeps a Known Security Issues page and a Responsible Disclosure Policy but publishes no GitHub security advisories. Held at 60 because the severity mix is notable and self-hosted Evergreen patching is all-or-nothing.

The 2026 Elasticsearch to OpenSearch move is forcing code changes: since 26.03.06-02, OSGi plugins that reference org.elasticsearch types fail to load, 26.04.25-01 changed index API signatures, the $estool.esSearch() and esRaw() Velocity methods are scheduled for removal on March 31, 2027, and anonymous content API access will be disallowed by default from the beginning of 2027. Headless customers also had to update SDK imports in 25.07 and update SDK libraries to keep using the UVE in 26.04.20-01. A public Deprecations page tracks 27 items, typically giving about six months before retirement, and an environment variable can restore the old anonymous-API default. Scored in the high 40s because the notice windows are well under 12 months and the search migration touches custom code.

Self-hosted dotCMS needs Docker for any supported installation, PostgreSQL (Oracle, MySQL and MSSQL support has been removed), and an external Elasticsearch or now OpenSearch cluster alongside the Java/Tomcat application. The official container image bundles Java, Tomcat and libraries, so the tree is simpler than Jahia's or AEM's, but dotCMS states that third-party components such as Java, Tomcat and log4j can only be fixed by upgrading dotCMS, and the search-engine switch adds a migration-phase dependency change in 2026. Cloud removes all of this.

dotCMS Cloud and Cloud Anywhere carry a 99.95% uptime SLA with 24/7 vendor monitoring, and the product has a Cluster Status tool for node health. No public status page could be reached (status.dotcms.com did not resolve), so customers cannot self-serve incident visibility, and self-hosted installs must build their own monitoring for the app nodes, PostgreSQL and the search cluster. Sits between SaaS norms and bare self-hosted because the install base spans both models.

Since 23.10 dotCMS automatically prunes content versions older than a year and more than 100 versions back, and publish and expire dates plus schedule-enabled workflows let teams retire content without manual cleanup. No built-in broken-link checker, orphaned-asset report or content health dashboard was found in the documentation, so most hygiene still depends on editorial discipline and custom queries. Scored at the midpoint pending better evidence of automated hygiene tooling.

dotCMS Cloud includes an integrated CDN with an admin purge screen, an invalidation API and a workflow actionlet that purges on publish, but developers must wire assets through $dotcdn.cdnify() and add the actionlet to workflow steps themselves. Self-hosted installs tune JVM, caching and the search cluster, and dotCMS sells a Performance Review and Optimization package, a sign that performance needs active attention. Held in the high 50s because Cloud covers infrastructure scaling while caching and CDN configuration stay with the customer.

dotCMS publishes its support tiers: Basic gives 8-hour initial response, 2 contacts and a cap of 20 support hours per server with no 24/7 coverage or CSM; Performance adds 4-hour initial response, unlimited hours, a dedicated CSM and 24/7 critical care; Premier brings 2-hour response and includes plugin, deployment and authentication support. G2 gave dotCMS its Best Support badge in the Mid-Market segment for Summer 2026. Kept just above 60 because 24/7 critical care is not in the entry tier, plugin support is an add-on below Premier, and upgrade-environment tickets fall outside the SLA with a 48-hour response.

The official community forum at community.dotcms.com is thin, with about 40 topics in Product Discussions and 39 announcements, and no active Discord or Slack was found. The open dotCMS/core GitHub repository, with public issues and an AI assistant on the developer docs site, is the most useful self-service channel. Low peer-to-peer activity for a platform of this age keeps the score in the low 40s.

dotCMS ships GA releases several times a week (v26.10.05-01, v26.10.07-01 and v26.10.08-01 in a single week), so an accepted fix reaches Latest-track Cloud environments within days and production on Standard within about two weeks, and releases with serious problems are marked Not recommended and skipped. LTS lines get rolling patch releases. The catch is that Evergreen fixes are never backported, so getting a fix means taking every other change in the release, and only 370 of the 771 issues opened in the public tracker since July 2026 are closed.

The Universal Visual Editor gives marketers a drag-and-drop Content Palette, inline editing, a Content Style Editor and (since 26.04) a Real-Time Canvas, so new pages can be assembled from existing templates, containers and content types without a developer. New layouts and new component types still come from developers (templates, containers, or headless component mappings), which keeps this at the threshold rather than above it.

No campaign object, content calendar or campaign analytics. Campaign coordination is assembled from schedule-enabled workflow (publish and expire dates), Future Time Machine preview of a future site state, and push-publishing bundles. That is scheduled publishing plus good preview, not campaign management.

Redirect management is native and editor-operable: Vanity URLs support 200 forward and 301/302 redirects, regex patterns and cross-site targets. URL Maps give slug-based SEO-friendly URLs. dotAI workflows can bulk-generate SEO metadata, and a GEO Scanner in the UVE scores pages for AI-answer-engine citability, structured knowledge and discoverability (Cloud only). Sitemap generation is a Velocity navtool pattern a developer wires into templates rather than a turnkey feature, and there is no native Schema.org authoring.

The no-code Form Builder was deprecated in July 2025; the recommended pattern is now a developer-built schema-driven form that posts submissions as contentlets through the workflow API. Conversion tracking exists in the first-party dotCMS Analytics Conversions dashboard, but that product is still in an Early Adopter Program. No CTA management, lead scoring or UTM handling.

Native, rule-based personalization without a separate CDP: Visitors, Personas and a Rules Engine whose conditions (including geolocation, referrer, visit count, request attributes) set personas, tag visitors and redirect in real time. $dotcontent.pullPersonalized ranks content by accrued visitor tags, and the UVE lets editors build persona variants of a page. No AI-driven or predictive targeting, and personas are the only variant key.

Experiments are native in the UVE: page variants, goals, traffic allocation, scheduling, an in-progress results pane with Bayesian probability to win, and one-click promotion of the winning variant. A headless SDK library extends it to decoupled front ends. It is disabled by default and requires the Analytics App configured by Customer Success, and testing is page-variant level rather than component or headline level, so it sits just below the native-with-auto-winner band.

Inline editing in the UVE, reusable content placed across pages, page copy, folder duplication, bulk upload in Content Drive, and dotAI workflows for batch operations (image generation, tagging, SEO metadata) make routine page production fast. Approval chains via configurable workflows can add steps, and new page types depend on developers.

Hybrid architecture: structured content types and Block Editor JSON delivered through REST, GraphQL and the Page API (layout as a service) to any channel, with SDKs for React, Angular, Next.js and Astro. There are no native email, SMS, push or social renditions; delivery beyond web and apps is up to the implementer.

dotCMS Analytics is first-party and cookieless, with Engagement, Pageview and Conversions dashboards inside the admin and a beta Query API, which is the in-CMS reporting this item asks for. It is still Early Adopter, does not report per-content performance as standalone metrics, and has no content-decay view. A GA4 OSGi plugin can pull GA4 metrics into Velocity templates but does not add tracking or a dashboard.

Consistency comes from developer-controlled templates, themes and containers that restrict which content types can be placed where, plus the Content Style Editor for constrained style choices. There are no locked design tokens or brand guardrail rules that block off-brand publishing.

Open Graph and Twitter card tags can be modeled as fields on page or content types and emitted in templates, and dotAI can generate metadata, but there is no social scheduling, push-to-social or UGC tooling.

A capable built-in media library: dotAssets and file assets with metadata, versioning, on-the-fly image transforms with focal point, WebP and auto-compression, AI image tagging through the AWS Rekognition integration, and bulk upload. No video transcoding or streaming, no rights or licence-expiry management, no usage analytics, so it stops short of DAM grade.

Solid general localization: unlimited languages, language fallback, language variables, multilingual forms, navigation and URL maps, and a native Google Translate workflow sub-action configurable per site that creates translated copies in every installed language. There is no transcreation workflow, locale-specific campaign variant model or regional consent tooling.

The official integration guides cover AWS Rekognition, a GA4 data plugin, Google Translate, a community Shopify plugin and dotAI with multiple LLM providers plus an MCP server. There are no pre-built CRM, marketing automation, CDP or ad-platform connectors, and outbound eventing is workflow-script webhooks rather than a first-class event service.

Flexible content types, relationships, categories, key-value and JSON fields let teams model products with variants and rich media, and the Shopify plugin auto-creates ShopifyProduct and ShopifyCollection types. It is generic modeling repurposed for products, with no product attribute sets or PIM-style tooling.

No merchandising features: no category merchandising, cross-sell management, search merchandising or product spotlights. Persona rules could vary promotional content but that is not merchandising tooling.

The only documented commerce connector is a community Shopify plugin: read-only Storefront API access through a Velocity viewtool, REST endpoints and GraphQL passthrough, with dotCMS content linkable to Shopify products and thumbnail syncing. No write-back, inventory or orders, and nothing for commercetools, Salesforce Commerce Cloud or BigCommerce.

Editorial pages can relate content to Shopify product content items and render product data via the viewtool, and the Block Editor can embed related contentlets, so buying guides are buildable. Shoppable content with inline add-to-cart is not a native authoring pattern.

Cart and checkout live in the commerce platform. dotCMS content could be fetched headlessly into a custom checkout, but there is no mechanism for injecting CMS content into commerce transactional flows.

No order event integration, so post-purchase content is not tied to orders from the CMS. Onboarding or help pages can be published as ordinary content.

Front-end login (including SAML for front-end users) and fine-grained object permissions on pages, folders, files and content can gate spec sheets and documentation by account role, which is useful for B2B portals. There is no account-based pricing display, quote flow or catalog segmentation feature.

Elasticsearch/OpenSearch-backed content search with aggregations supports faceted queries, and Site Search can build scheduled indexes, and dotAI adds semantic search over embeddings. Blending commerce product results requires custom code since Shopify data is not indexed, and there is no synonym or search-landing-page tooling for editors.

Schedule-enabled workflow handles time-activated publish and expire for promo banners, Future Time Machine previews them, and persona rules can target variants by audience or geography. No countdown, promo-code or channel-specific activation features.

One instance serves hundreds of sites, each with its own content, templates and permissions, while System Host content is shared across all sites. That makes shared product content with storefront-specific editorial and legal content straightforward, though there is no commerce-aware storefront model.

Image transforms with focal point and a Block Editor video block cover basic galleries and embeds. No 360 views, 3D/AR, hotspots or video transcoding.

Multi-author contribution with front-end login, workflow approvals and per-role permissions is possible, but nothing marketplace-specific such as seller profiles, review aggregation or moderation at scale.

Product content types inherit dotCMS's per-language versions, fallback and Google Translate sub-action, and per-site content handles regional legal text. There is no currency awareness or regulatory content model.

dotCMS Analytics conversions show which content was present on the path to a goal, which is a start on content attribution, but there is no revenue data or commerce event integration.

Front-end login with SAML SSO, roles mapped from the identity provider, and object-level permissions with inheritance on sites, folders, pages and individual content items let intranets restrict content by department role. dotCMS also markets field-level restriction. No audience-attribute visibility beyond roles.

Configurable approval workflows, version history with restore, tags and categories, and scheduled expiry give a workable knowledge base. There are no review-date or ownership features, and Site Search cannot index permissioned pages, which undercuts internal findability.

dotCMS is used to build portals on its permissioned page model, but it ships no employee news feed, directory, dashboards or notifications. Everything is custom-built.

News can be published and targeted by role permissions or persona rules, but there are no read receipts, acknowledgement tracking or mandatory-read workflows.

A directory can be modeled as a content type, with users synced from LDAP or SAML, but there is no org chart or HR system integration.

Documents are versioned file assets with multi-step approval workflows (including multiple-approval sub-actions), permissions and scheduled expiry, which covers controlled policy publishing. No acknowledgement tracking or automated review reminders.

Role-gated onboarding pages are buildable with permissions and persona rules, but there are no journeys, checklists or HR-triggered portals.

Content search over Elasticsearch/OpenSearch respects permissions through the APIs and dotAI adds semantic search, but the editor-configured Site Search only indexes anonymous-visible pages, and there is no federation with SharePoint, Confluence or Drive, nor search analytics.

Responsive sites and headless SDKs allow a custom mobile app, but there is no native employee app, offline mode or push notifications.

No LMS integration or learning features; training content can only be hosted as ordinary pages and files.

No end-user comments, reactions, forums, polls or community spaces. Workflow comments exist only for editors in the back end.

Azure AD and Google SAML SSO connect identity, and workflow script webhooks can post to Teams or Slack, but there are no embedded cards, bots or Microsoft 365 content integration.

Publish and expire dates via schedule-enabled workflow, archiving through workflow actions, and automatic pruning of old versions give basic lifecycle control. No review dates, stale-content flagging or ownership assignment.

dotCMS Analytics gives page views and engagement by device, browser and language, but nothing by department or user role, no failed-search data and no adoption dashboards.

Each site has its own content, folder tree, templates, permissions, site-scoped content types and per-site app configuration (SAML, translation keys), and sites can be pushed to separate environments. All sites share one database and runtime, so isolation is logical rather than hard multi-tenant separation; separate instances are needed for strict data separation.

The System Host holds content, content types, containers and templates available to every site in the instance, and assets on one site can be referenced from another. That is native cross-site sharing within an instance, though there is no versioned library publishing to separate instances.

Central administration of users, roles, workflow schemes and permission inheritance across all sites in one instance is a real strength. Enforcement of content standards is through permissions and shared workflows rather than cross-brand policy rules.

Many sites run on shared infrastructure in one instance with unlimited users, and the pricing page sells additional sites as add-ons on top of a tier, which is cheaper than an instance per brand. Pricing is still per-site and per-content-type, so cost rises with portfolio size.

Themes and templates are assigned per site, and the Host content type can carry site variables (logos, colors, keys) read by shared templates, so brands can share containers while differing visually. It is configuration and theming rather than a token-based theming system.

Languages are instance-wide, while translation API keys can be set per site and workflows plus permissions can be scoped so regional teams approve their own translations. There is no brand-by-locale governance model.

dotCMS Analytics is enabled and reported per site; there is no portfolio view comparing brands, so aggregation is manual through the beta Query API.

Workflow schemes attach to content types, and permissions on workflow actions can be set by role, so brands get different approval chains by using site-scoped content types and brand roles. That works but is not a per-site workflow setting, and central audit is the shared workflow history.

Content on the System Host appears on every site and updates everywhere when edited, and content can be related or pulled across sites. There is no controlled override point per brand: a local variant means copying the item.

Cloud Anywhere lets customers pick hosting region, per-site SAML separates identity, and the WYSIWYG accessibility checker helps editors. There are no per-brand compliance rules that block non-compliant publishing.

Shared templates and containers on the System Host give a central component set that sites can override with their own themes. Versioned propagation of a design system is handled in front-end code and Git, not the platform.

One user and role store spans all sites; admins can grant roles per site for autonomous brand teams, and SAML can be configured per site with role mapping. No SCIM provisioning.

Content types can be global (System Host) or scoped to one site, so a brand can have its own types alongside shared ones. Extending a shared type per brand without forking is not supported; brands either share the full type or create their own.

No executive reporting across sites on freshness, SLA adherence or cost allocation; admins rely on custom queries.

dotCMS names a data protection officer ([email protected]), lists a GDPR policy, Data Protection Policy and Data Deletion Policy among its implemented policies, and publishes GDPR and CCPA support documentation that names AWS as a sub-processor for dotCMS Cloud. EU hosting is available (GCP EU-Central Frankfurt for dotCMS Cloud, plus Cloud Anywhere and self-hosting in a customer-chosen region). No public DPA, SCC terms or full sub-processor list could be verified outside the Vanta-hosted Trust Center, which keeps this in the 60s.

dotCMS markets heavily to healthcare and compliance-led organizations and its content discusses HIPAA audit-control requirements, but no Business Associate Agreement or HIPAA-eligible dotCMS Cloud offering is documented on the security and compliance page or in the docs. Self-hosting and Cloud Anywhere let a covered entity keep any ePHI inside its own controlled infrastructure, which lifts it slightly above the no-coverage band.

GDPR and CCPA are both covered by dedicated support documentation, and dotCMS Cloud holds TX-RAMP Level II certification for Texas public-sector agencies, a meaningful US state-government credential. There is no FedRAMP, StateRAMP/GovRAMP, IRAP, C5, PCI DSS or HITRUST, and no documented UK IDTA, PIPEDA or LGPD coverage, so breadth stays modest.

dotCMS holds a SOC 2 Type II report covering the Security, Availability and Confidentiality Trust Services Criteria, audited by Prescient Security, renewed annually since at least 2021 (fourth consecutive year announced September 2024, zero exceptions). The report and auditor test results are requestable through the Trust Center. Just below the top of the band because the most recent dated renewal announcement is from 2024, though the current product page still lists the attestation.

dotCMS holds its own ISO/IEC 27001:2022 certification for an ISMS covering its cloud services and supporting operations, first achieved in 2023 with surveillance audits completed since. This is platform scope, not inherited AWS certification. No ISO 27017 or 27018 certification is listed, which keeps it below 80.

Beyond SOC 2 and ISO 27001, dotCMS holds TX-RAMP Level II and ISO/IEC 42001:2023 for AI management (covering dotAI features), publishes a Cloud Security Alliance CAIQ, and is an authorized CVE Numbering Authority. The CAIQ is a self-assessment rather than a STAR Level 2 audit, and there is no PCI DSS, Cyber Essentials Plus, FedRAMP, IRAP or C5, so the portfolio is solid but not deep.

dotCMS Cloud runs in multiple regions (AWS US-East, CA-Central and Sydney, and GCP EU-Central Frankfurt), Cloud Anywhere runs a dotCMS-managed instance in the customer's own AWS, Azure or GCP account in any region, and self-hosting gives full control. Backups replicate to a geographically separate secondary region, which buyers with strict residency needs must check. Contractual residency guarantees are not published, keeping it just under 78.

Admins can download a point-in-time database dump and a zipped asset backup from the Maintenance tools (also scriptable via API), export content to CSV, and work through full REST and GraphQL APIs, so a complete self-service exit is possible. A Data Deletion Policy exists, but the post-termination retention period is not published and there is no dedicated right-to-erasure tool beyond user and content deletion.

dotCMS keeps per-content version history and workflow history with comments, records logins and user activity in its application logs, and its docs refer to log and audit logging configuration through log4j2, which self-hosted customers can ship to any SIEM. No native SIEM push, in-product audit log viewer with export, or configurable audit retention is documented for dotCMS Cloud, so SIEM integration relies on log files or support.

dotCMS's only accessibility statement covers its marketing website (partial WCAG 2.1 AA, self-evaluated, 2023), not the authoring interface. Editors get a WYSIWYG accessibility checker and page health scanners for published content, but those address delivered output. No WCAG or ATAG conformance claim for the Angular admin UI was found.

No VPAT, ACR or Section 508 conformance report for the dotCMS product is published, and the Trust Center and security page list none. The only formal document is the marketing website accessibility statement, which does not help a procurement review of the product. Content-facing accessibility tooling earns a little credit, but documentation is minimal.

dotAI ships in core with AI Blocks in the Block Editor for in-editor generation, the dotAI Tool chat workspace, and an AI Content Prompt workflow sub-action that can generate whole contentlets or fields asynchronously, with prompts able to reference existing content via Velocity. Global Role and Text prompts in the dotAI app settings set a writing style and persona, which is a basic brand-voice control. Held in the mid-50s because there is no prompt-template library per content type, no multi-voice brand guardrails, and no inline review or diff of AI suggestions beyond normal versioning.

Image generation is a native dotAI capability (OpenAI gpt-image/DALL-E or Azure OpenAI image deployments) usable from the dotAI Tool and the AI Generate Image workflow sub-action, which can batch-fill content missing an image. The AI Image Auto-Tagging and Descriptions sub-action writes alt text and tags from the image, and also fires on Publish when field variables are defined; AWS Rekognition auto-tagging is a further option. Not 70+ because generated images can only land in binary fields, not image fields, and there is no smart crop, focal point AI or video/media AI.

The AI Translate Content workflow sub-action translates contentlets into one or more target languages using the configured LLM, with field-type and field-level include/exclude lists, a configurable translation model, system and user prompts, and a glossary drawn from up to 1,000 language variables by prefix for exact domain terminology. A separate Google Translate integration offers classic MT. Held at 60 because there is no translation quality scoring, no translation memory, and runs are sequential per language through workflow rather than a dedicated localization console.

dotAI documents batch generation of SEO metadata across large sets of content through the AI Content Prompt sub-action, plus AI Auto-Tag Content (optionally limited to pre-existing tags) and AI-generated alt text and descriptions for images. This covers titles, descriptions, tags and alt text, but SEO metadata generation is a configurable prompt pattern rather than a purpose-built SEO feature. No on-page SEO scoring, schema markup suggestions or optimization recommendations were found, which keeps it in the partial band.

AI is woven into dotCMS's workflow engine as sub-actions (content prompt, auto-tag, image generation, image tagging/alt text, translation) that can run asynchronously, fire from the content search bulk menu, run on a delay, or trigger automatically on Publish. Embeddings are kept in sync on content updates, so semantic indexes stay current without manual work. Not 60+ because there is no AI scheduling, routing or duplicate detection, and each automation must be assembled by an administrator in workflow configuration.

dotCMS positions AI agents as actors that receive a dotCMS role and operate inside existing permissions, approval workflows and audit trails, and the MCP server lets external agents create, edit, publish and run workflow actions in natural language. However, there is no named, in-platform agent product or agent builder; multi-step autonomy depends on external agent clients plus the MCP server, which is still published under a beta tag. That places it in the early agentic band.

dotAI offers semantic related-content lookups and embedding counts per content type, and dotCMS has analytics and experiments, but no AI-driven content gap analysis, topic clustering, content health scoring or editorial priority recommendations were found in the docs or product pages. Auto-tagging gives some structure for analysis but no dashboard surfaces insight from it.

No AI-powered audit capability for quality, brand voice compliance, accessibility or thin/duplicate content is documented. Teams could build a custom audit with the AI Content Prompt sub-action run in bulk from content search, but that is a do-it-yourself pattern rather than a shipped feature.

dotAI provides native vector search backed by pgvector in the dotCMS Postgres database, with named embedding indexes per content type, field-level index selection, similarity thresholds, and REST endpoints for semantic search and related-content retrieval, plus streaming completions that can answer over indexed content (RAG). Embeddings can come from OpenAI, Azure OpenAI, Bedrock Titan, Google or OpenRouter models. Not higher because it requires adding the pgvector extension, there is no documented hybrid keyword plus vector ranking, and the editor-facing site search remains Elasticsearch/OpenSearch keyword search.

dotCMS personalization is persona and rules based, with A/B experiments, and the homepage frames it as testing and personalization within governed workflows. No ML model, predictive segmentation, real-time audience scoring or next-best-content engine was found; semantic related-content via embeddings is the closest AI-driven recommendation and requires custom implementation.

dotCMS publishes an official MCP server (@dotcms/mcp-server, source in core-web/apps/mcp-server) that pre-loads instance context such as content types, lets agents search the REST API spec and execute authenticated calls, and supports create, edit, publish and workflow operations, scoped by an API token's permissions. Setup guides cover Claude Desktop and Cursor. Held at 60 because the docs still direct users to the @beta tag pending stability, and the design is a generic API-execution sandbox rather than curated, schema-specific tools.

dotAI is BYOK by design: Chat, Embeddings and Image Generation are each configured independently against OpenAI, Azure OpenAI, Google Vertex AI, Amazon Bedrock, Google AI, Anthropic or OpenRouter using the customer's own credentials, with per-site configuration, model fallback lists, region selection for Bedrock and deployment names for Azure, and a test-connection button. Running models inside the customer's own Azure, AWS or Google tenancy gives real data residency control. Not higher only because some providers are chat-only, so image and embedding capabilities need OpenAI, Azure, Bedrock or Google.

Developers get a dedicated /api/v1/ai REST surface (completions with streaming, embeddings management, semantic and related search), a $ai Velocity viewtool for server-side AI calls, an AI SDK library in core-web (libs/sdk/ai) used by the MCP server, a dotAI plugin example for extending it, and the MCP server for agent clients. This is solid RAG-ready tooling, but there are no official LangChain or LlamaIndex integrations or agent-framework guides, which keeps it below 70.

dotCMS runs AI-generated and agent work through the same roles, permissions, approval workflows, audit trails and version history as human edits, so AI changes are attributable, reviewable and reversible, and the company holds ISO/IEC 42001 certification for AI management. BYOK keeps data inside the customer's approved model provider. Held below 70 because there is no brand-safety enforcement on output, no hallucination or confidence scoring, no prompt-template governance beyond global prompts, and no IP indemnification.

Administrators can set rate limits for tokens and API calls per minute, enable verbose AI debug logging, and query embedding counts per index, and the completions API returns token usage per call. There is no usage dashboard, per-user consumption reporting, cost tracking or quality trend monitoring, and with BYOK the spend is only visible in the provider's own console.