What Hyland's OpenArch carries forward from Nuxeo and what it leaves behind

What Hyland's OpenArch Carries Forward from Nuxeo, and What It Leaves Behind

Hyland released OpenArch as open source. I pointed Claude at the codebase, next to the Nuxeo LTS 2023 and 2025 branches, and asked for a straight answer: what is familiar, what is new, what was set aside, and where each one wins.

This is what came back, with my own notes on top.

The short version

• OpenArch is built on Nuxeo's foundations. Runtime, content model, MongoDB storage, blob layer, security model. If you know Nuxeo, you can read it.
• It is a repository plus search. It is not a platform. No workflow, no automation, no renditions, no UI. That is a choice, not a gap.
• It does one thing Nuxeo does not do out of the box: vector and hybrid search. Nuxeo 2025 has no vector support yet, and none by default. You can add it, but you are building it yourself.
• Not a replacement. OpenArch reuses Nuxeo's building blocks for a different job: serving content to AI services with permissions intact. Nuxeo stays the content management platform, and it can be one of OpenArch's sources.

What OpenArch is

The pitch is narrow: take unstructured content from across the organization (Alfresco, Nuxeo, SharePoint, others), make it available to AI services and agents, and never lose track of who is allowed to see what.

Three things follow:

• It keeps the originals where they are. OpenArch stores what retrieval needs and points back to the source system for the file itself.
• It puts permissions on the content as ACLs and simplifies security.
• It is only API-first. There is no user interface out of the box.

Take a Nuxeo repository as the source, since that is the case most of us care about. The PDF stays in Nuxeo's blob store, in S3 or wherever you keep binaries. What OpenArch holds for that document is its metadata, the extracted text split into chunks, an embedding for each chunk, its ACL, and a reference back to the Nuxeo document. A query, keyword or semantic, is answered from that, and the permission check runs against the ACL before any result comes back. If a user or an agent then needs the actual file, you follow the reference back into Nuxeo and fetch it there. Nuxeo stays the system of record. OpenArch holds a few kilobytes per document instead of a second copy of the file.

docker-compose up, open the Swagger UI, POST a document. A few minutes.

That is interesting on its own. If you work with Nuxeo it is more than interesting, because most of what is underneath is already familiar.

The foundations are Nuxeo's

Hyland owns Nuxeo, so none of this is a coincidence. Of the platforms Hyland owns, Nuxeo is the best architected, and it shows in what they chose to build on. Large parts of the stack are the same architecture under a new package name.

Two surface changes first: properties moved from ecm: to sys_, and the query language is now HXQL. Under that, here is what you will recognise.

Runtime and extension points. Named extension points, XML contributions, a central service registry. You still change behaviour by contributing, not by patching. It runs next to Spring Boot rather than being replaced by it.

Content model. XSD schemas, document types extending each other, facets, validation, constraints, resolvers. Facets got renamed: Folderish is SysFolderish, Versionable is SysVersionable.

Document API. CoreSession, DocumentModel, DocumentRef. About half the methods Nuxeo has, but the same object.

MongoDB storage. The full document store abstraction: query planning, cursor scrolling, caching, cluster invalidation. A Mongo query plan from OpenArch looks like a Mongo query plan from Nuxeo.

Blob storage. Same layering: providers, a caching store, a transactional store, the backend.

Security. A security service with pluggable policies, permission descriptors, and read ACLs denormalised onto each document.

Indexing. An inline listener on document events, commands coalesced per transaction, then asynchronous scroller and batch processing. Named index configuration with settings and mapping files, source include and exclude, alias management with numbered indexes.

Platform services. Key-value store, pub/sub, cluster service, transient store, and the scheduled jobs for ACE validity and retention expiry.

Governance. Records, retention and legal hold are all there. Given how much else was cut, that tells you something about the target customer.

What OpenArch adds

Embeddings in the content model

Not an integration layer. There is a facet for documents that carry embeddings, and the embedding model goes down into the storage layer. Chunks and vectors are repository objects.

Hybrid search

A separate embeddings index with a 1024-dimension vector field. Keyword and semantic results are merged with Reciprocal Rank Fusion, by rank rather than by score, so nobody has to hand-tune normalisation between two scales that do not compare.

Embedding ingestion is pluggable through an extension point. Out of the box it reads a Parquet file per document, one row per chunk with its text and vector. OpenArch does not call an embedding model itself; producing the vectors is your pipeline's job.

Permissions you can inspect

REST endpoints return a document's effective ACL and effective permissions. If you are going to promise "permissions respected at retrieval time", this is what makes the promise checkable.

One security layer

Nuxeo has two security layers. OpenArch has one.

In Nuxeo, access control has two layers. There are ACLs and there are security policies, a second layer that has nothing to do with ACLs, which the repository applies on its own and the search side applies only for policies that know how to express themselves as a query. In OpenArch the ACL check is itself a security policy. It contributes a sys_racl IN (principals) clause like any other policy would. All policies, ACLs included, go through one security policy service, and both the repository and the search layer call that same service on the parsed query before either backend sees it. One layer, applied once, to both.

What it leaves behind

Compared with Nuxeo, a lot is simply not there, on purpose:

• Automation operations and chains
• Workflow and document routing
• Converters, renditions, imaging and video pipelines
• Audit, comments, tags, collections, Drive
• Any web user interface
• Proxies, publishing, and the lifecycle state machine
• A relational storage backend. MongoDB only.

None of it reads as unfinished. OpenArch is a repository and a search layer, and most of that list is things you no longer have to run. It also means the two products answer different questions, so read the comparison below with that in mind.

Where Nuxeo still wins

Breadth. Everything in the list above. If the problem is content management rather than content retrieval, Nuxeo is the product and OpenArch is not competing for the job.

Search abstraction. This surprised me. Nuxeo 2025 replaced its Elasticsearch integration with a real search service: a pluggable client SPI with capability negotiation (aggregates, highlighting, multiple repositories), plus a client that answers queries straight from MongoDB with no search engine at all. OpenArch makes OpenSearch mandatory and the integration is concrete, not pluggable.

Cross-repository search in a single query. OpenArch has no concept of it.

Storage choice. MongoDB or relational. OpenArch is MongoDB only.

Durable async work. Nuxeo's bulk processing runs on a durable stream layer built for repository-wide jobs. OpenArch's task runner is pluggable by contribution, but the only implementation in the repository is in-memory. For reindexing at serious scale, that difference is real.

Ecosystem. Marketplace packages, Studio, client SDKs, years of conventions and connectors.

Where OpenArch wins

. Vector search out of the box. Nuxeo 2025 ships none yet. No vector fields, no hybrid ranking, nothing in the search capability model by default. You can add it (we already did!), but it is a custom development, not a configuration.

One security layer, as above.

Operations. OpenArch is one system fewer to run. A production Nuxeo needs Nuxeo, MongoDB, a search engine and Kafka. OpenArch needs OpenArch, MongoDB and OpenSearch. The difference is Kafka, and the reason it is gone is simple. Nuxeo sends all of its background work through Kafka topics, from a single document reindex to a bulk action over the whole repository, so that work survives a restart and can be shared across nodes. OpenArch keeps that work in a task queue inside the application. So there is no broker to size, no topics to tune and no retention arithmetic. The price is the one I listed on Nuxeo's side: background work in OpenArch is not durable in the same way..

A search client built for today's OpenSearch. OpenArch uses the current typed Java client for OpenSearch 3 and puts a circuit breaker, retries and a health probe around it. If the cluster starts struggling, OpenArch notices, backs off, and tells you. Nuxeo's fully tested path is still the older high-level REST client, which does none of that. You find out the cluster is in trouble the way we all have: timeouts in the logs, and someone asking why search is slow..

Time to first API call. Compose file, Swagger UI, documented default credentials. Minutes.

Who should look at this

If you run Nuxeo for document management, with workflows, renditions, and a UI your users log into, nothing here changes that. OpenArch is not asking you to reconsider.

If you are the one being asked to make enterprise content AI-ready, meaning chunked, embedded, retrievable across several systems, with permissions enforced at query time instead of filtered afterwards, OpenArch is a serious starting point. You get that machinery on top of a repository design that has already been proven at very large scale. That is rare in a 1.0.

Why this fits us

Almost everything underneath OpenArch is ground we know well. The runtime and its extension points, the schema system, the MongoDB storage layer, the blob stores, the security model, the indexing pipeline. These are the parts of Nuxeo we have spent years extending, tuning and debugging in production.

Reading this codebase is not a learning curve for us.

That matters. A 1.0 open-source release means thin documentation, few examples, and answers that live in the source. Knowing where to look, and knowing which behaviours are inherited and come with a decade of operational knowledge, saves time and removes risk.

If you are considering building on OpenArch, evaluating it, planning how it sits next to an existing Nuxeo estate, wiring a connector, or you just want someone to read the source with you, get in touch.

---

How this was done: Claude read the OpenArch source directly against the Nuxeo LTS 2023 and 2025 branches, comparing module structure, service interfaces, configuration contributions and index mappings. The findings come from the code, not from documentation or release notes. The judgement calls are mine.