dotCMS

dotCMS offers 20+ field types including JSON, key/value, Block Editor, relationships, category, tag and custom fields, and content types can be pulled and pushed as files with the dotCMS CLI. There are no union or polymorphic fields and the CLI is a sync tool rather than true schema-as-code, which keeps it below 80.

Relationship fields support one-to-one, one-to-many, many-to-one and many-to-many cardinality, with the reverse side exposed as an 'Existing' relationship field and queryable via Lucene and GraphQL. Each relationship field targets a single content type, so polymorphic references are missing and it stays below 80.

The Block Editor stores structured JSON and can embed contentlets (dotContent), grid blocks and tables, and pages compose contentlets into containers and template regions. Nesting is limited compared with unlimited component trees, so it stays in the adequate-to-strong band.

Fields support required, unique and regex validation with predefined patterns, file-type restrictions on binary fields, and validation applies to API writes through the workflow API. There are no declarative min/max or date-range settings and no cross-field rule engine beyond custom code, so it sits at standard built-in level.

Every save creates a version with author and date in the History tab, working and live states are separate, any version can be restored, and archived content can be unarchived before deletion. There is no branching and version comparison is limited, so it lands at the low end of adequate.

dotCMS Categories are hierarchical, permissioned controlled vocabularies reusable across any content type through the category field, and they are queryable in Lucene, REST and GraphQL; a separate Tag Manager handles free tags that also feed persona tag accrual. There is no synonym support or bulk reclassification tooling, which keeps it just under 75.

The Universal Visual Editor previews drafts on the real frontend, including headless Next.js, Angular and Astro apps through the @dotcms/uve SDK, with click-to-edit, inline text editing and persona, language, device and future-date (Time Machine) preview. Shareable unauthenticated preview links are limited and headless setup needs SDK wiring, keeping it below 90.

The Block Editor outputs a documented JSON AST with official renderers for React, Angular and Velocity, embeds contentlets, images and video, and includes markdown shortcuts and an accessibility checker on the WYSIWYG field. Custom blocks require remote extensions, so it stays just below the 75+ AST tier.

URL-based image transforms cover resize, crop, focal point, WebP and quality compression, assets carry extracted metadata, and Content Drive provides bulk upload and folder management. AVIF is missing and usage tracking is basic, so it stays just under 75.

Content locking prevents conflicting edits, and workflow comments plus task assignment notifications provide async collaboration. There is no presence, co-editing or inline commenting, so it sits at the bottom of the locking-plus-comments band.

Workflows have custom steps and actions, role-based assignment, multiple-approver sub-actions, per-content-type schemes, notifications, and a task history audit trail, all exposed through a workflow REST API. There is no visual drag-and-drop workflow designer, which keeps it below the mid-80s.

Schedule-enabled workflows give publish and expire dates per content type, push publishing bundles move many items atomically to receiving environments on a schedule, and Future Time Machine previews the site at a future date. There is no publishing calendar view, so it stays below 75.

Localization is document-level: each contentlet has a version per language, with configurable fallback to the default language, language variables for UI strings, and language switching in UVE preview and APIs. There is no field-level localization or multi-step fallback chain, so it stays in the document-level band.

dotCMS has custom hierarchical roles with inherited permissions on sites, folders, content types and individual contentlets, workflow actions tied to roles, and SAML/OIDC SSO through the Apps screen. Field-level permissions and SCIM provisioning are not documented, so it sits in the good role model band.

dotCMS offers REST (content, Page/Layout-as-a-Service, Elasticsearch), and GraphQL with pagination, collections and language parameters. Delivery and management share the same API surface rather than a dedicated delivery API, keeping it at the lower end of the REST plus GraphQL band.

dotCMS Cloud includes dotCDN with publish-triggered invalidation through push-publish listeners, and static publishing can push to S3 and other targets. Edge personalization is absent and self-hosted CDN integration is DIY, so it sits in the CDN-backed band.

Outbound webhooks are built as workflow sub-actions or Velocity scripts, push-publish listeners fire on publish, and system events cover internal changes. There is no first-class webhook service with signing, retries or delivery logs, so it sits low in the solid-webhooks band.

dotCMS is a hybrid CMS with official JavaScript SDKs (client, React, Angular, UVE, types, events), an alpha PHP library and example projects for .NET, Laravel and Astro, and the Block Editor outputs portable JSON. There are no native mobile SDKs and the SDK set is JavaScript-centric, so it stays in the mid-60s.

Personas and the Rules engine segment visitors in real time on geolocation, referrer, device, visited pages, cookies and accrued tags, all in the base product. There is no unified CDP-grade profile, identity resolution or named CDP connector, so it sits at the bottom of the rule-based band.

Pages can be personalized per persona in the Universal Visual Editor with a persona switcher for in-editor preview, and Rules can show or redirect content by visitor condition. Variants are keyed to personas rather than arbitrary segments, keeping it just below 70.

dotCMS Experiments run page A/B tests with variants, traffic split, goals and Bayesian probability-to-win reporting inside the editor. It depends on the Content Analytics infrastructure, which is simplest on dotCMS Cloud, and there is no multivariate testing, so it stays below 70.

No recommendation engine is documented; related content is built with tag or category queries in Velocity or the content API, and persona tag accrual can bias those queries. That is a build pattern, not a feature.

Site Search crawls and indexes sites into Elasticsearch with scheduled jobs, and content can be queried with full Lucene and raw Elasticsearch queries including facets. There is no relevance tuning UI, merchandising or search analytics, so it sits in the basic native band.

dotCMS has no catalog, cart, checkout or pricing module. Product content can be modelled as content types but that is not commerce.

No first-party Shopify, commercetools or BigCommerce connector is documented; commerce appears as a use-case page and partner builds using the APIs and OSGi plugins. That places it in the custom tier.

Content Analytics collects page views and content events with dashboards and an analytics query API, and feeds Experiments. It is newer, tied to dotCMS's analytics infrastructure, and lacks content health and lifecycle reporting, so it stays below 60.

GA4, Adobe Analytics or GTM tags are added through templates or the headless frontend; no official analytics connector or event helper for third-party tools is documented. That is custom integration.

Multi-tenant multi-site is core to dotCMS: many sites run in one instance with per-site configuration, and content, templates and containers can be shared through System Host. Cross-site governance tooling is basic, keeping it at 80.

A built-in Translate workflow sub-action machine-translates content into other languages, and the edit screen supports side-by-side language versions. No official TMS connector (Phrase, Smartling, Lokalise) or translation memory is documented, so it stays below 55.

Brands can run as separate sites with shared System Host assets, per-site permissions and per-site workflow schemes. There is no cross-brand policy enforcement, brand-level analytics or locked design tokens, so it sits in the organization-level band.

dotAssets give a versioned asset library with extracted metadata, folders, tags and categories, workflow-based approval and Content Drive bulk operations. Rights and usage-rights expiry, brand portals and cross-channel usage tracking are absent, so it stays below 60.

Video files can be uploaded and served as assets and embedded through the Block Editor video block. No transcoding, adaptive streaming, captions management or player is documented, so it sits just below the basic-upload band.

The Universal Visual Editor lets marketers drag contentlets from a Content Palette into containers, with a template layout designer for rows and columns and containers restricting allowed content types as guardrails, and it works for headless frontends. Layout freedom is bounded by templates and design-token governance is limited, keeping it below the mid-80s.

dotCMS renders full sites natively with Velocity templates and themes, and dotCMS Cloud hosts them with dotCDN, TLS, custom domains and multiple environments; it can also be self-hosted. Headless frontends (Next.js, Angular) must be hosted by the customer, so it falls short of the 90+ band.

The Form content type and form builder create forms whose submissions are stored as content and can trigger workflow actions such as email or webhooks. Conditional logic, multi-step forms and progressive profiling are not documented, so it sits in the basic builder band.

A Send Email workflow sub-action sends transactional notifications, but no Mailchimp, Marketo or HubSpot connector is documented. ESP integration is a build-it-yourself job.

The Rules engine can set personas, cookies and redirects on visitor behaviour, but there are no drip flows, lead scoring or campaigns. Automation requires an external tool wired in by hand.

Page assets carry SEO title, description, keywords and friendly URL fields, Vanity URLs handle 301/302 redirects and forwards with regex, and edit mode includes an SEO and social media preview. Structured data authoring and on-page recommendations are not native, and sitemaps need configuration, keeping it in the 60s.

No llms.txt generation, Markdown endpoints for agents or per-bot crawler controls are documented; these could be built with Velocity scripts, vanity URLs and robots.txt as a file asset. Without vendor guidance it stays in the custom tier.

The Apps screen configures a small set of built-in integrations (SSO, translation, AI, analytics), and OSGi plugin examples live in the dotCMS GitHub organization. There is no public marketplace with a broad catalog, so it sits in the small directory band.

dotCMS supports front-end users with login, roles and the same permission model for gating pages, files and content, and the SAML/OIDC app can authenticate front-end visitors against an IdP. There is no packaged member portal, self-service account pages or consent management, so it stays below 75.

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 (privacy@dotcms.com), 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.