Mayan EDMS: a Django document management system, and the mirror you should ignore

The first line of the README is a warning, not a pitch

The most important sentence in this repository is the one at the very top of the README, and it is easy to skim past because it is written in capitals.

It says this is a mirror, that it is no longer maintained, and that it is very outdated, and it instructs the reader to use the official repository instead, at gitlab.com/mayan-edms/mayan-edms. The repository description says the same thing in shorter form, describing it as a mirror with no pull request or issues.

That framing changes what an article about this project can responsibly claim. Any evaluation of Mayan EDMS as software has to be done against the GitLab repository, not this tree. What this tree is good for is telling you how the project is deployed, what it depends on, and where the community and artefacts live, and for that it is still useful.

The description calls Mayan a free open source document management system, and the README calls it the most advanced, scalable and mature open source document management system. That is the project's own claim about itself, and the README does not back it with a benchmark or a scale figure, so treat it as positioning rather than evidence.

The maintenance facts available for this repository are narrow and worth stating plainly. The last push here was on 2026-05-23, the repository is not flagged as archived, and it has no GitHub releases. The mirror exists, it is recent enough not to be abandoned outright, and the code inside it is behind the GitLab project.

The real project lives on GitLab, PyPI and Docker Hub

The README's important links section is the map you need.

The homepage is mayan-edms.com, the documentation is at docs.mayan-edms.com, there is a forum at forum.mayan-edms.com, and the source code, issues and bugs are on GitLab at the mayan-edms/mayan-edms project. That last one is the one that matters, because that is where the source of truth, the issue tracker and the pipelines live.

The artefacts have their own channels. The package is published to PyPI as mayan-edms, the Docker image is mayanedms/mayanedms on Docker Hub, and there is a Zenodo DOI, 10.5281/zenodo.16760961, which is the citation handle for the project. A DOI is what you want if you are referencing Mayan in a paper or a procurement document, because it versions the citation rather than pointing at a moving URL.

The README also points at a knowledge base for in depth articles, tutorials and troubleshooting, and at a getting started page in the documentation at docs.mayan-edms.com/parts/installation.html.

The repository layout of the mirror also hints at what the project contains beyond the application code, with a docker directory holding the compose setup, a portainer directory, a vagrant directory, a contrib directory, a docs directory, and a requirements directory split into common.txt and base.txt, with requirements.txt pointing at both.

There are also four history files, HISTORY.rst plus HISTORY_1_x.rst, HISTORY_2_x.rst and HISTORY_3_x.rst, which is a sign of a project that has been through several major version lines and has kept its changelog.

Deployment is three commands and a compose file

The README makes a strong claim about how easy it is to get started, and then backs it with a short command sequence.

It says it is very easy to get started with Mayan EDMS, just deploy the official Docker Compose file.

curl https://gitlab.com/mayan-edms/mayan-edms/-/raw/master/docker/docker-compose.yml -O
curl https://gitlab.com/mayan-edms/mayan-edms/-/raw/master/docker/.env -O
docker compose up --detach

Two things about those commands are worth pointing out, and both come from reading them rather than from the prose.

First, they fetch from GitLab, not from this GitHub mirror. Even the quick start is telling you to go to the other host, which is a further confirmation that this repository is not where the work happens.

Second, the second file is a .env, and the compose file and the environment file are fetched together because the compose file expects that environment file to be present in the same directory. That is a small operational detail with a real consequence: if you fetch only the compose file, or rename the .env, the stack starts with defaults you did not intend. The .env is the place where the deployment specific settings live, so it is also the file you will edit for a real installation rather than a trial.

For a document management system, a compose file is the right delivery format. The services involved, a database, a search index, background workers and the application itself, are exactly the kind of set of things that are painful to install by hand and easy to run as a stack.

The dependency list describes the feature set better than the README does

The packaging metadata in this mirror is dated, but it is a compact description of what the system is made of.

The install requirements pin Django 3.2.14, and pull in CairoSVG 2.5.2, Pillow 9.2.0, PyPDF2 1.28.4, PyYAML 6.0, Whoosh 2.7.4, bleach 4.1.0, celery 5.2.3, django-activity-stream 1.4.0, django-auth-ldap 4.0.0, django-celery-beat 2.2.1 and django-cors, with the list truncated after that.

Read as a set, those names describe the product. Whoosh is a pure Python search library, which is how a document management system gets full text indexing without a separate search cluster. Pillow with PyPDF2 and CairoSVG is a document conversion and preview pipeline, so a PDF in becomes searchable text and a rendered page. bleach is an HTML sanitiser, which matters a lot in a system that stores and later serves user supplied documents. Celery with django-celery-beat is the asynchronous task layer, and in a DMS that is where OCR, conversion and indexing run. django-auth-ldap points at directory service integration, which is the standard requirement for an enterprise document store. django-activity-stream is the audit trail, and an audit trail is not optional in this category of software.

The topics attached to the repository list django, dms, document-management, document-manager, ocr, pdf and paperless, which is consistent with that reading. The topic list also includes docker and enterprise-software, which describes the deployment and the audience rather than the code.

The test matrix covers five database engines

The Makefile in this mirror shows a test setup that is more ambitious than most, and it is the clearest sign of what the project has to work with.

There are named container variables for the test dependencies, one each for Elastic, MySQL, Oracle, PostgreSQL and Redis, and the test command is assembled from a module name, a settings module, and skip-migrations, debug and extra arguments.

TEST_COMMAND = ./manage.py test $(MODULE) --settings=$(SETTINGS) $(SKIPMIGRATIONS) $(DEBUG) $(ARGUMENTS)

The default settings module is the testing development settings, and the default module is the mayan-apps module. There are targets for running a single app, a single module or a single test class, for running everything, for running in debug mode, and for running with migrations, plus a set of clean targets that remove build artifacts and Python bytecode caches.

The five backends are the interesting part. A DMS is not a simple web application, because it stores binary objects, indexes their content, runs background processing and has to support the database your organisation has already standardised on. Being able to run the test suite against MySQL, Oracle, PostgreSQL and Redis alongside Elasticsearch is a claim about portability, and it is also a substantial maintenance burden, which is presumably why the project needs a mirror of its own on a second host.

The requirements being split into common.txt and base.txt, and the Makefile pulling in a config.env at the top, are consistent with a project that is built and tested in a fairly formal way.

The licence is the one thing to settle before anything else

The licence situation is unusual and deserves attention before an evaluation goes further.

The repository is recorded as having a licence that GitHub cannot classify, a custom one, with a pointer to the LICENSE file. The README's licence badge links to the LICENSE file on the GitLab repository rather than to a local one, which is a small hint that the canonical licence text lives with the active project.

That combination is worth taking seriously. The PyPI licence badge in this mirror points at the OSI badge image, which is the standard way of indicating a recognised open source licence, while the repository metadata says the licence cannot be classified. Both can be true at once if the licence is a modified or additional grant over the upstream components, which is common in a Django application that ships a large dependency set, but the README does not describe the terms.

This is not a licence analysis, and anyone reading this should read the LICENSE file and, if it matters to them, ask. The practical point is narrower. If you are evaluating Mayan for procurement, a compliance review, or a redistribution scenario, the licence question cannot be deferred to the end, because an unclassifiable custom licence is exactly the kind of thing that a legal team will want to see early rather than after the deployment has been built.

The repository also carries a DCO file and a CONTRIBUTING.md, which means the contribution process asks for a Developer Certificate of Origin sign-off rather than a click-through licence agreement, another sign of a project with an orderly process around it.

Editorial conclusion

Mayan EDMS suits a team that needs a self hosted document management system with OCR and full text search on a Django stack, and it deploys in a single docker compose command, which is a low barrier to a trial. It does not suit a team that plans to work from GitHub, because the GitHub copy of this project is a mirror that its own README calls unmaintained and very outdated, and it does not suit a team that needs a licence it can classify at a glance, since the repository ships a custom licence GitHub cannot categorise. Before you evaluate anything, move to the GitLab repository named in the README, and if you evaluate this mirror at all, check the Docker image tag on Docker Hub and the PyPI release, because the last push here was on 2026-05-23 and the code in this tree is older than either.

Frequently asked questions

Official sources

1. Issues
2. mayan-edms/Mayan-EDMS on GitHub
3. Project website
4. README