Gentics Mesh is a Java headless CMS built around content trees and a GraphQL API

A headless CMS is a content store with no front end of its own

Gentics Mesh is described as a friendly, enterprise grade, open source headless CMS, and the README makes the case for the headless model before it makes the case for its own product.

A traditional CMS is described as coupled, meaning the CMS also takes care of the presentation layer that delivers content to clients, with content and presentation closely interlinked, and content managers working through WYSIWYG editors. The CMS then delivers the content according to the front-end delivery layer built into it, which typically supports your websites but not much else.

A pure headless CMS offers no front end capabilities at all, giving you full control of the customer experience through APIs, while providing content managers with a presentation and channel agnostic way of managing content. It requires a front end development team to handle the rest with the frameworks and tools they prefer, and the content can be loaded by external applications, meaning it can be reused by multiple applications and channels: web, mobile app, audio guides, IoT.

That last point is the whole argument for a headless CMS, and it is why the project positions itself as more than a CMS, as an application development platform for websites, IoT applications, mobile apps, smart devices and digital signage.

Content trees are the design decision that does the work

The README lists three things that make Gentics Mesh different from other headless CMSes, and the first is the one that shapes everything else: it thinks in content trees, just like websites do.

The consequence is stated as a set of things you get for free. Automatic navigation menus, automatic beautiful URLs, built in link resolving. A content tree is a hierarchy, and a hierarchy has a parent and a position, so a navigation menu is a query rather than a configuration exercise, and a URL can be derived from the path of the node rather than stored separately.

That is a real architectural difference from a flat, schema driven content model where a page is a row with a slug column and a menu is a separate structure someone maintains by hand. The trade-off is that the tree imposes a shape. If your content is genuinely flat, a set of independent items with no hierarchy, a tree forces you to invent a hierarchy to store it.

The second differentiator is built in user management, which the documentation says covers not only the admin and editor features but can also be used for handling access to your application. So the same directory that stores your content can authenticate the users of the application that reads it, which removes a common duplication in headless setups.

The third is that it is scalable and clustering friendly, so a deployment can grow with the project.

What the platform handles so your application does not

The value proposition is stated plainly: Mesh is the platform that holds your content and gives you APIs to access and modify it, while relieving you from handling permissions, multi-language aspects, search, and much more.

Each of those four is a subsystem you would otherwise build or buy.

Permissions, meaning who can read and change which content, and multi-language content, which in a headless setup means modelling translations, fallback chains and per-locale publication states, are the two that most often end up as bespoke code in the application layer. Search is the third, since a headless CMS that cannot search is only half a CMS. A modern user interface is also part of the offer, one the documentation says makes content editing and administration enjoyable.

What the platform does not decide is your application stack. You choose the technology and programming language you want to implement the application with, you decide whether to host locally or in the cloud, and the documentation is explicit that the vendor does not care whether you are a Windows, Linux or Mac person.

The API surface is documented in two flavours. There is a Using the REST API section and a Using the GraphQL API section in the documentation index, and the repository topics name both graphql-api and api-first. The project description calls it an API first CMS, and the API Reference is part of the documentation site.

Getting started means the docs, not a quick install

The README does not contain an install command, and it points at the Getting Started Guide for an explanation of the basic concepts of Gentics Mesh. That guide is the intended entry point, and the documentation index carries the rest: the Usage, API and Concepts pages, and a section on getting started developing that covers authentication and then the two ways of consuming the API.

The concept that has to come first is the content tree, because the API's shape follows from it. Once you understand how nodes are structured and how the API addresses them, the REST and GraphQL surfaces make more sense.

For developers the workflow the documentation describes is: authenticate against the API, then use either the REST API or the GraphQL API. Authentication comes before either, which tells you the CMS is a secured service in its own right rather than a read-only content dump.

The project is a Maven build with a pom.xml at the root, so the source is a multi module Java project rather than a single jar, and the modules are visible in the top level directory listing. The api/ directory holds the API definition, common-api/ and common/ hold shared code, core/ and server/ hold the service itself, services/ holds the domain services, connectors/ holds integrations, and rest-client/ and rest-model/ hold the client side pieces.

The Java module layout tells you what the product is made of

The top level of the repository is unusually informative, because it is a large enterprise Java project and every directory is a subsystem.

Beyond the ones already mentioned there is mdm/ for the data model, and the delivery side. The elasticsearch/ directory is the search implementation, which tells you the search subsystem is Elasticsearch rather than a database query layer. The distributed/ and distributed-coordinator/ directories are the clustering support, matching the claim that the platform is clustering friendly. The connectors/ directory holds integrations, and plugin-api/, plugin-bom/, plugin-dep/ and plugin-parent/ are a whole plugin system with its own Maven module hierarchy, which is how an enterprise CMS exposes extension points.

There is also a js/ directory, so a JavaScript component ships alongside the Java server, and rest-client/ and rest-model/ are the Java client libraries, which gives a JVM application typed classes for calling the API instead of hand-writing requests..

Then there is the test infrastructure. integration-tests/, database-tests/, performance-tests/, test-scanner/ and tests/ are separate directories, and database-tests/ in particular suggests the schema is verified against multiple database engines rather than one, which is a reasonable expectation for a product that is sold as something you host.

The rest is build machinery: bom/, build/,.docker/ and.dockerignore/ for container builds, a Jenkinsfile.split, a.travis.yml,.jenkins/, CHANGELOG.adoc, LTS-CHANGELOG.adoc and SQL-CHANGELOG.adoc, plus SECURITY.md.

Open source and Enterprise Edition sit next to each other

The product structure is worth understanding before you adopt anything, because it decides what you get.

Gentics CMP, the Content Management Platform, is composed of Gentics CMS, Gentics Mesh and Gentics Portal. Gentics CMS and Mesh are available as both open source software and as an Enterprise Edition. Gentics Portal, in Java and PHP, can only be acquired with the Enterprise Edition. The README links a page listing the Enterprise Edition features and gives a sales contact address for more information.

So the open source build of Mesh is complete as a CMS and API server, and the parts that are tied to the Enterprise Edition are the Portal front end and whatever else that comparison page lists. The important thing for an evaluator is that the page exists and is linked from the README, rather than having to discover the split by trial.

The licence is Apache 2.0, and the documentation states plainly that with it you are free to use it, modify it and improve it. There is also a CLA assistant badge, so contributions are handled through a contributor licence agreement, and the project publishes a SECURITY.md alongside the changelogs.

The status section is unusually direct about the people behind it: Gentics Mesh is actively developed by a dedicated team at Gentics Software GmbH in Vienna, Austria, and the core team is listed with roles such as UI/UX developer, software architect and backend developer. That is a commercial vendor backing an open source project, and for an enterprise buyer that is a different proposition from an unfunded project, in both directions.

Where a headless CMS is the wrong choice

The honest limits are about scale of adoption and about what the open source build leaves out.

The first is that this is a large Java service. The repository is a multi module Maven project with a plugin framework, a clustering coordinator, an Elasticsearch dependency, a data model layer and a container build. Deploying and operating it is a Java operations exercise, not a weekend. A team that wants content with a REST API and a dozen entries will spend more time on the CMS than on the site.

The second is the Enterprise Edition boundary. If your plan involves the Portal, or whatever else the comparison page places on the commercial side, the open source build will get you part of the way and then stop, and the next step is a conversation with sales. That is a legitimate business model, but it should be a planned step in your evaluation rather than a surprise after a quarter of work.

The third is that a headless CMS buys you API delivery and nothing else. It does not give you a fast site, a good developer experience for your front end, or a preview environment, and it does not remove the need for front end developers. The documentation says a front end development team is required to handle the rest. For a team that just wants a nice editing experience and a fast marketing site, a coupled CMS with a WYSIWYG editor is less total work, and the documentation is unusually clear about why the headless model exists in the first place.

Editorial conclusion

Gentics Mesh fits an enterprise team that already runs Java, wants a CMS it can host on its own infrastructure, and needs one content store feeding websites, mobile apps, IoT devices and digital signage rather than one front end. It does not fit a small team that wants a hosted service with a monthly bill and a support contract, because the open source build leaves the Enterprise Edition features, including Gentics Portal, behind a licence conversation with sales. Before committing, read the open source and Enterprise Edition comparison the README links, confirm which of the features you need sit on which side of that line, and plan for a Java service that needs its own database, since the repository layout is a large multi module Maven project rather than a single deployable artefact.

Frequently asked questions

Official sources

1. gentics/mesh on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases