Nuxeo Platform: an extensible content management foundation

A content back end, not a content library

The Nuxeo Platform is described as an open source customizable and extensible content management platform for building business applications. The word that matters is applications. Nuxeo is not a library you add to a Spring Boot service and not a place to upload PDFs; it is a server product that hosts documents, assets, cases and knowledge bases, and the applications you build on top of it talk to it over its APIs. The README names the four domains it serves, document management, digital asset management, case management application and knowledge management, and describes two extension routes: ready-to-use addons, or extending the platform using its extension point system. The audience is therefore an enterprise development team with a domain to model, not a developer with a single file to serve. The platform is developed and supported by Nuxeo, with contributions from the community, and the code is primarily Java.

Modules, packages and the Maven build tree

The repository layout tells you what kind of project this is. The top level contains `modules/`, `packages/`, `server/`, `docker/`, `boms/`, `parent/`, `tools/`, `scripts/`, `ci/` and `ftests/`, plus a root `pom.xml`, a `versions-rules.xml` and a `clone.py` helper. A `modules/` tree of Maven modules is the extension surface in practice, and the presence of `boms/` means dependency versions are managed centrally rather than per module, which is what keeps a tree this large buildable. The `packages/` and `server/` directories are where the distributable artifacts are assembled, and `docker/` holds the image build that the README points to for how to build, run and configure the Nuxeo Docker Image. There is also a `findbugs.xml`, an `owasp-dependency-suppression.xml` and a `fixeclipse` script, which are the fingerprints of a codebase that has to pass static analysis and a dependency policy gate. The build badge in the README points at a Jenkins job for the 2025 branch.

Cloning, JDK 21 and the Maven options you need

Building requires Git, JDK 21 with Azul Zulu recommended, and Apache Maven 3.9.6 or later. The README gives two clone paths, one for people with access to the private nuxeo-lts repository and one for the public repository, and each is a two line sequence you run in a shell:

# If you have access to the nuxeo/nuxeo-lts private repository (latest sources):
git clone [email protected]:nuxeo/nuxeo-lts.git
cd nuxeo-lts

# Else:
git clone [email protected]:nuxeo/nuxeo.git
cd nuxeo

Before running Maven the README asks you to export JVM options for the build, because a project this size needs headroom:

export MAVEN_OPTS='-Xmx4g -Xms2g -XX:+TieredCompilation -XX:TieredStopAtLevel=1'

The important switches in the documented command are the `distrib` and `docker` profiles, the `nuxeo.skip.enforcer=true` flag that tells the build to step past its enforcement checks, and the `-T6` parallel thread setting. The README also points at a Nuxeo Core Developer Guide for complete instructions.

One maven command, or a shorter path to the image

The full build, which the README says includes the packages, the server ZIP and the Docker image, is a single Maven invocation:

mvn install -Pdistrib,docker -DskipTests -Dnuxeo.skip.enforcer=true -T6

If the Docker image is all you need, there is a shorter path. The README describes it as starting by building the image dependencies, the server modules and the ZIP, and then the image itself, and the command adds a module selection to restrict the build to `docker/nuxeo` plus its dependencies:

mvn install -Pdistrib,docker -pl docker/nuxeo -am -DskipTests -Dnuxeo.skip.enforcer=true -T6

The `-T6` flag runs the build with six parallel threads, and `-am` pulls in the modules the selected one depends on. The outputs are predictable: the Tomcat ZIP distribution ends up under `server/nuxeo-server-tomcat/target`, and a built image shows up in the local images repository, visible with `docker images`. That is a reasonable amount of ceremony for a platform of this size, and the parallelism is what makes it bearable.

Third-party binaries the platform expects you to supply

Running the platform needs JDK 21, and the installation itself follows the Installation guide the README links. The less obvious dependency is preview and conversion software, which the platform does not bundle. Depending on the features you use, you may need LibreOffice and pdftohtml for document preview, and ImageMagick for pictures. The README points to a page in the Admin documentation that lists the third-party software, which tells you the platform expects these to exist on the host rather than shipping them in the distribution. That is a deliberate choice for a server product, and it has a consequence: the same installation that works on a developer laptop can behave differently on a server, because the conversion binaries and their versions are part of what determines whether a preview renders. A deployment checklist for Nuxeo therefore includes more than the server itself.

Where the documentation lives and how issues are tracked

Nuxeo splits its documentation by audience, and the README lists the entry points: a Developer Documentation site, a Server Documentation section, a REST API Documentation section, a User Documentation section, and the Nuxeo Core Developer Guide. The REST API documentation is the part that matters most for integrators, because the application-facing contract with the platform is the API rather than the Java internals. For problems, the README points at a JIRA instance for the NXP project and at answers.nuxeo.com for questions, and the repository also has a `crowdin-conf.yml`, which indicates that the user-facing translations are managed through Crowdin. There is a separate Benchmarks site where the platform is described as benchmarked continuously to test its scalability on several databases. That claim is worth noting for what it is: it is a statement about the vendor's own testing program, not a measurement you can rely on for your own workload.

The cost of running it and the cost of changing it

Two things bound the operational cost. The first is the shape of the deployment itself: a Tomcat based server, a database, a build tree with a hundred or more modules and a configurable addons layer. The second is the extension model, and it cuts both ways. The extension point system is what makes the platform adaptable, but every addons you install becomes part of what you must upgrade and support together, and the version rules encoded in `versions-rules.xml` are the mechanism the project uses to keep those combinations coherent. Licensing is straightforward: most of the source is copyright Nuxeo and contributors under the Apache License, Version 2.0, with the LICENSE file and a licenses page in the documentation as the authoritative references. That permissive licence is what makes embedding or redistributing components practical, though it says nothing about the commercial support and products Nuxeo sells around the platform.

Editorial conclusion

The Nuxeo Platform fits teams that need a full content back end with an extension point system, a REST API and packaged addons, and that have the appetite to build and operate a Java server product. It is a poor fit for a small project needing a document store in an afternoon, since the build needs JDK 21, Maven and a large module tree, and preview features pull in LibreOffice, pdftohtml and ImageMagick. Before you commit, read the installation guide linked from the README, confirm the addons you need are available, and check the Apache-2.0 licensing terms against your distribution model. The last push was on 2026-10-20 on the 2025 branch, and the repository publishes no GitHub releases, so versioning runs through the Maven artifacts and the documentation site.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. nuxeo/nuxeo on GitHub
4. Project website
5. README