OpenCms is a Java and XML CMS for large intranets and sites

An XML content repository behind the editor

OpenCms is described as a powerful open source website content management system, built in Java and XML from open source components, providing features especially suited for large internet or intranet websites. The XML part is the interesting one, because it explains a lot of the system's character. The content repository is an XML virtual file system, and structured contents can be defined using a simple XML schema, so a page is not a blob of HTML with a template wrapped around it but a defined structure with typed fields. That is the design that makes a large editorial operation manageable, since the same field can be required, localised and rendered consistently across thousands of pages. The repository is also reachable from outside the web tier. File access to the OpenCms content repository over a shared network or SMB drive is supported, along with CMIS and WebDAV access, and contents can be served dynamically or exported to static HTML files. That combination is the reason the system is still in use in places the newer headless-first CMSes have not reached.

Three editors, and why they are not interchangeable

The editor story is where most CMS evaluations stall, and OpenCms offers three distinct paths. The page editor allows WYSIWYG inline editing of web pages and arrangement of content by drag and drop. The form based editor allows editing of structured content in a well defined form mask, which is the one that matters when content is schema-driven. The sitemap editor allows creating new pages and rearranging the navigation tree by drag and drop, which is the tool that turns the repository into a navigable site rather than a pile of files. For an evaluation, the form based editor is the one to test, because it is where the structured content model either works for your content or does not. The rest of the feature list supports the large site case. Link management for all internal resources comes with broken link detection, there is integrated image scaling and cropping, and SEO features include automatic sitemap.xml generation and page alias support. The responsive Mercury default template is based on Bootstrap 4, and content creation for mobile devices comes with preview and device specific content control.

Workflow, permissions and multiple sites in one install

Three features carry the weight for an enterprise intranet. The first is the Online and Offline workflow, where changes must be approved before they become visible, which is the difference between a CMS an intranet team can use and one they will route around. The second is full featured user management supporting the concept of Organizational Units, which is a permission model that maps onto a real company's structure rather than on flat roles. The third is that one installation can manage multiple websites, so a corporate site, an internal portal and a campaign microsite can share one repository, one user store and one deployment. Two smaller features are worth knowing about because they are unusual. The time warp feature allows viewing resources which are expired or not yet released, which is a legitimate editorial and legal review tool. And the system integrates Apache SOLR for powerful content searching and noSQL like queries, with full text search covering web pages as well as office documents like PDF, MS Office and Open Office files, so the search covers the PDFs people actually read rather than only the pages.

Extensions, templates and a headless API

Extensions can be added through a flexible module system, and the repository layout shows how substantial that is: there are modules/ and src-modules/ directories, a module-export.conf file and a webapp/ directory for the application itself. Modules are how a site gets its custom behaviour without forking the core, and the documentation mentions JSP integration for dynamic functionality in templates and dynamic forms, so a module can also supply server-side rendering logic for the default template. The headless API for accessing content as JSON from external applications means the same repository can feed a mobile app or a separate front end without a second content store, which is how a team avoids the classic split where the CMS and the app each hold a copy of the truth. The default template is the other half of the story. The responsive Mercury template is shipped with the product, so a new site has something usable on day one, and the page editor, the form editor and the sitemap editor all work against that template's structure rather than against arbitrary HTML.

Jakarta EE and the legacy javax branch

The compatibility story is the most consequential operational detail, and OpenCms 22 is available in two variants. The Jakarta EE variant requires a Jakarta Servlet 6.0 compatible web container, works out of the box with Tomcat 10.1, Tomcat 11 or Jetty 12, and is the default variant and the recommended choice for new installations. The legacy Java(x) EE variant requires a Java Servlet 4.0 web container such as Tomcat 9 or Jetty 12 in EE 8 mode, and it is for existing installations that still depend on javax code, with a note that OpenCms 23 will be Jakarta-only. Others have reported deploying OpenCms successfully on other web servlet containers like WildFly, GlassFish, WebLogic, WebSphere and Resin. The source layout explains how the two variants are produced. The main branch contains the Jakarta EE variant and all active development happens there, while the master branch contains the legacy variant and is generated from main for the release by converting the sources back to the javax namespace, so pull requests should always target main. Which variant a build produces is controlled by the eeTarget property in gradle.properties, which is set to jakarta or javax and also selects the matching dependency set. The repository carries two dependency files, dependencies_jakarta.gradle and dependencies_javax.gradle, alongside the general one.

Installing with Docker or from source

The easiest installation is the official Docker image, and the project points at alkacon/opencms-docker on Docker Hub for full information about running it. Images are available for both variants, with alkacon/opencms-docker:22.0 for the Jakarta EE variant and alkacon/opencms-docker:22.0-javax for the legacy one. If you prefer to install from scratch on your own server, the manual route is documented in the OpenCms installation guide in the assets/docs directory of the repository, and the build itself is Gradle based with a gradlew wrapper, a build.gradle, settings.gradle and a dependencies.gradle. The runtime requirements are Java 21 and Java 25, both of which the documentation lists as compatible, and the database side is where the deployment decisions bite, since support is provided for MySQL, MariaDB, Oracle, PostgreSQL, MS SQL Server, DB2 and HSQLDB. The repository also carries a history.txt file and a VERSION-like set of build properties, with create_version_properties.sh and copy-messages.sh as build helpers, and the release history in the project's own tags shows build_22_0_0 for OpenCms 22 on 2026-10-06 after build_21_0_0 and build_21_0_1 in April 2026.

The live demo, and how the project is run

Before you install anything, the documentation offers a way to see the product without a server of your own. The OpenCms Live Demo server gives you a personal OpenCms installation exclusively for you, and all you need to do is register with a valid email address, with a commitment that the data you provide will not be used for anything other than setting up your personal demo installation. For a system with this much surface area, that is a cheap and sensible first step, because the editing model is the thing you cannot evaluate from a feature list. The rest of the project structure is well documented too. The OpenCms Documentation Central is the portal to all documentation regarding OpenCms related technology, the issue tracker on GitHub is where bugs and feature requests go, and pull requests are welcome directly on GitHub. Security issues are handled differently, through a security issue report form on the Alkacon website rather than the public tracker, which is the right call and a good sign about how the project treats disclosure. OpenCms is developed by Alkacon Software with the help of an international OpenCms community, and the source code is released under the GNU LGPL.

Editorial conclusion

Adopt OpenCms if you run a large internet or intranet site with many editors, need structured content defined by an XML schema, and want offline approval workflows and a headless API on the same platform. Do not adopt it for a small marketing site, where the deployment weight of a servlet container, a database and a Java application server is more than the editorial model buys you, and do not start a new project on the legacy javax branch, since the documentation says OpenCms 23 will be Jakarta-only. Verify two things before you plan a migration: which servlet container and Java version you will run, since the Jakarta variant needs a Jakarta Servlet 6.0 container while the legacy variant needs a Java Servlet 4.0 one, and whether your database is on the supported list, which covers MySQL, MariaDB, Oracle, PostgreSQL, MS SQL Server, DB2 and HSQLDB. The practical first step is to spin up the Docker image for the variant you need and register for the live demo to see the editing model before you install anything.

Frequently asked questions

Official sources

1. alkacon/opencms-core on GitHub
2. License: LGPL-2.1
3. Project website
4. README
5. Releases