Обзор Mayan EDMS: серверный архив документов с OCR, версиями и workflow

Mayan EDMS — не настольный PDF-ридер и не редактор одного файла, а серверная электронная система управления документами. Она принимает документы из разных источников, хранит оригиналы и версии, строит превью и полнотекстовый индекс, запускает OCR, связывает документы с метаданными и бизнес-процессами, а доступ разделяет по ролям и ACL. На 15 сентября 2026 года актуальная стабильная ветка — 4.12, а последний выпуск 4.12.1 датирован 21 августа 2026 года. Для нового развёртывания разработчики рекомендуют Docker Compose; старое зеркало проекта на GitHub прямо помечено как устаревшее, поэтому ориентироваться следует на официальный GitLab, сайт и документацию.

Скачать Mayan EDMS

Безопасный путь получения начинается с официального сайта: раздел Download ведёт в актуальную документацию, а та — к Docker Compose из основного GitLab-репозитория. Для ветки 4.12 Compose использует официальный образ Mayan EDMS и согласованный набор сервисов. Старое GitHub-зеркало прямо помечено как неактуальное, поэтому брать из него инструкции и файлы для нового сервера не следует.

Пакет 4.12.1 есть и в PyPI со статусом Production/Stable, но актуальная документация больше не предлагает прямую Python-установку как штатный путь. Наличие wheel и исходного архива полезно разработчикам; обычному администратору разумнее следовать Docker Compose и сохранять применённые Compose- и env-файлы для воспроизводимости.

Что такое Mayan EDMS

Mayan EDMS расшифровывается как Electronic Document Management System. Проект предназначен для централизованного хранения, классификации, поиска и контролируемой обработки сканированных и цифровых документов. Это принципиально другой класс ПО, чем локальный PDF-просмотрщик: сервер хранит документы и связанные с ними данные, выполняет фоновые операции, а пользователи получают единое веб-пространство с правилами доступа.

Автором и основным сопровождающим проекта указан Roberto Rosario. Коммерческую поддержку, обучение, миграции и другие услуги предоставляет Mayan EDMS LLC. При этом базовая программа остаётся свободным ПО с открытым исходным кодом: действующий LICENSE в основном репозитории и метаданные пакета 4.12.1 указывают GPL-2.0-only. На странице поддержки отдельно предлагается коммерческое перелицензирование, в том числе на Apache 2.0, поэтому старые материалы, где Mayan EDMS назывался Apache-2.0-проектом, нельзя переносить на текущий релиз без оговорки.

Проект активен. В 2026 году вышли серии 4.11 и 4.12, причём 4.12.1 закрывает конкретные вопросы надёжности, безопасности REST API, зависаний внешних процессов и поддержки интерфейсов с письмом справа налево. Это не законсервированная система и не снятая с поддержки ветка. Одновременно Mayan EDMS не следует смешивать с Mayan Enterprise Cloud: облачное предложение и услуги компании являются отдельным способом эксплуатации, тогда как рассматриваемый здесь Mayan EDMS можно развернуть на своей инфраструктуре.

Основные функции Mayan EDMS

Документы, версии и страницы

Mayan EDMS хранит версии документа и позволяет возвращаться к прежним вариантам. Страницы можно переставлять, отключать и собирать в новое представление; поворот, обрезка, масштабирование и redaction-слои относятся к неразрушающим операциям и не требуют переписывать загруженный оригинал. Это модель управления жизненным циклом документа, а не свободного редактирования текста и верстки PDF.

OCR, текст и файловые метаданные

Для сканов предусмотрен OCR на базе Tesseract по умолчанию; задачи выполняются в фоне, а язык документа передаётся движку распознавания. PDF и офисные файлы с готовым текстовым слоем могут разбираться без OCR. Отдельные drivers извлекают файловые метаданные. ClamAV поддерживается как драйвер проверки, но в 4.12 для новых типов документов его нужно включать явно.

Классификация и поиск

Типы документов связываются с пользовательскими метаданными, теги дают быстрые признаки, cabinets создают иерархию, а автоматические индексы строят дерево по данным и шаблонам. Поиск использует извлечённый и распознанный текст вместе с полями объектов, поэтому документ можно находить не только по имени файла.

Источники и пакетный импорт

Документы поступают через браузер, серверные файлы, watched folders, IMAP/POP3, SANE-сканеры и подключаемые хранилища. Поддерживается пакетная загрузка и обработка архивов. После приёма файла OCR, конвертация, индексирование и другие операции могут продолжаться асинхронно, поэтому факт загрузки ещё не означает готовность всех производных данных.

Workflow, события и автоматизация

Workflow задаёт состояния и допустимые переходы документа. Переходы могут инициироваться пользователем или событиями, а действия состояния — менять теги и доступ, отправлять сообщения или вызывать зарегистрированные интеграции. События и журналы помогают фиксировать, что произошло с объектом; последовательности из 4.12 дают атомарные номера для шаблонов, workflow и API.

Доступ и аутентификация

Разрешения выдаются через роли и могут ограничиваться конкретными объектами через ACL: просмотр, скачивание, изменение метаданных и другие действия разделяются. Есть TOTP-двухфакторная аутентификация, блокировка после неудачных входов и расширяемые authentication backends для SSO/LDAP-сценариев. В 4.12.1 усилена проверка объектных разрешений REST API.

REST API и внешние сервисы

Функции доступны через версионированный HTTP REST API с OpenAPI-документацией. В 4.12 рекомендованный путь загрузки проходит через приложение Sources, а прежний прямой upload endpoint помечен к удалению в 5.0. Интеграции с OpenAI и Ollama опциональны: OpenAI требует внешнего API, а Ollama можно держать локально. Обязательной облачной обработки для обычного архива нет.

Интерфейс и удобство использования

Работа ведётся в браузере. В версии 4.12 интерфейс переведён с Bootstrap 3 на Bootstrap 5: переработаны панели списков, формы, адаптивные режимы, боковые панели и просмотр страниц. Пользователь может работать в светлом или тёмном цветовом режиме; добавлена поддержка RTL для языков с направлением письма справа налево. Для продукта с большим количеством административных сущностей это не косметическое изменение, а заметное упрощение навигации на современных экранах.

Основная логика строится вокруг списков объектов и контекстных действий. Пользователь открывает документы, типы, источники, кабинеты, теги или workflow, а доступные операции зависят от разрешений. В списках есть табличное и карточное представление, сортировка, фильтрация, пакетный выбор. Отдельные панели и dashboards показывают состояние репозитория и объекты, важные текущему пользователю.

Порог входа двухуровневый. Загрузить первый файл можно быстро: после первого запуска уже есть Default document type и Default source. Но качественно спроектировать типы документов, метаданные, ACL, роли, индексы и workflow без понимания предметной области не получится. Mayan EDMS проще освоить как систему постепенно: сначала загрузка и поиск, затем классификация, потом автоматизация и интеграции.

Интерфейс многоязычный, язык задаётся пользователю индивидуально. В серии 4.10 в список переводов была добавлена русская локаль, а 4.12 улучшила языковую разметку страниц. При этом перевод большого административного продукта может обновляться неравномерно, поэтому для сопровождения полезно сохранять знание англоязычных названий настроек и объектов из официальной документации.

Поддерживаемые форматы и совместимость

Mayan EDMS не публикует короткий закрытый список «разрешённых расширений», потому что разные операции опираются на converter-, parser- и metadata-backend. Официальная функциональная документация прямо подтверждает многостраничные PDF, офисные документы и TIFF, а также превью многих популярных форматов. Для офисных документов Mayan EDMS использует LibreOffice, если он присутствует в окружении, и создаёт браузерное представление без необходимости устанавливать офисный пакет на компьютер пользователя.

PDF — один из естественных форматов для репозитория: система отображает страницы, извлекает встроенный текст, поддерживает OCR сканов и умеет экспортировать выбранную версию документа в единый PDF. Оригинальный загруженный файл при этом доступен для скачивания отдельно. Такое разделение важно: «экспорт версии» и «скачивание исходника» дают разные результаты и должны использоваться осознанно.

Совместимость с источниками шире форматов файлов. Документы могут приходить из браузера, почты, watched folders, SANE-совместимых сканеров и объектного хранилища. Для хранения доступны локальная файловая система и подключаемые backend-модули, включая Amazon S3 и S3-совместимый MinIO. Для интеграций предусмотрен REST API, а индексы и cabinets при специальной конфигурации могут публиковаться как файловое представление только для чтения.

Клиентская сторона не привязана к Windows-приложению: пользователь открывает сервер в браузере. Сам сервер проект рекомендует размещать на GNU/Linux либо другой платформе с зрелой поддержкой виртуализации и Docker Compose. Это означает, что Windows и macOS могут участвовать как рабочие станции с браузером, но Mayan EDMS нельзя оценивать как обычную нативную программу для этих ОС.

Производительность и стабильность

Фоновая архитектура делает Mayan EDMS заметно требовательнее простого файлового сервера. OCR, построение превью, извлечение текста, метаданные, поиск и workflow конкурируют за CPU, память, диск и очереди. Минимум 4 ГБ RAM подходит лишь как стартовая точка; официальная рекомендация для базовой инсталляции — 16 ГБ и более, 64-битный процессор от 8 ядер и 2 ГГц, а для хранения — SSD. Объём документов, размер файлов и количество одновременных пользователей напрямую влияют на необходимый запас.

У проекта есть опубликованный сравнительный тест самой версии 4.12, и его полезно читать именно как данные разработчиков, а не как универсальный результат. На одной 8-процессорной виртуальной машине с 16 ГБ памяти сравнивались 4.11.5 и 4.12 при обработке 1015 PDF, 9404 страниц и 1,82 ГБ данных. Для 4.12 указана устойчивая скорость создания около 4,82 документа в секунду против 4,22 у 4.11.5, а медиана выдачи изображения страницы снизилась со 314 до 114 мс. Эти цифры подтверждают направление оптимизаций, но не гарантируют такую же производительность на другом хранилище, при ином OCR-языке или в многопользовательской нагрузке.

Версия 4.12.1 добавила тайм-ауты для внешних команд и исправила потенциальную блокировку pdftotext при очень большом выводе. Для LibreOffice, pdftoppm и pdfinfo в актуальной серии предусмотрен стандартный предел выполнения 300 секунд; аналогичный 300-секундный предел есть для pdftotext, а SANE-сканирование по умолчанию ограничивается 300 секундами. Практический смысл в том, что повреждённый или необычно тяжёлый файл с большей вероятностью завершится ошибкой обработки, а не зависшим worker.

Стабильность крупного репозитория зависит и от обслуживающих сервисов. Актуальный Compose серии 4.12 использует PostgreSQL 15.17, RabbitMQ 4.1.8 и Redis 7.4.8; Elasticsearch 9.1.10 доступен как отдельный профиль. Redis настроен с политикой noeviction, чтобы при дефиците памяти не исчезали ключи блокировок и результатов задач. Администратору это даёт более явную ошибку вместо тихой потери служебного состояния, но требует следить за лимитом памяти.

Лицензирование и версии

Актуальный код Mayan EDMS распространяется по GPL-2.0-only. У основного проекта нет отдельной урезанной бесплатной редакции: Docker Compose запускает тот же базовый продукт, а лицензионный ключ, пробный период и регистрация у поставщика для самостоятельного экземпляра не требуются. Коммерческое перелицензирование, включая Apache 2.0, предлагается отдельно.

Платными являются услуги вокруг продукта. На дату проверки Self Guided стоит 9,99 доллара США в месяц, Level 4 Enterprise — 1099 долларов в месяц при годовом плане, индивидуальный контракт начинается от 35 000 долларов в год. Это цены поддержки и услуг, а не обязательная стоимость программы. Для установки следует использовать документацию текущей ветки 4.12.1: старые версии отличаются зависимостями, методами развёртывания и исторически лицензией.

Системные требования

Минимальный уровень

Официальная страница требований указывает 4 ГБ RAM, 64-битный двухъядерный процессор около 1 ГГц и PostgreSQL 13.11 как минимальную конфигурацию. В качестве платформы рекомендуется GNU/Linux либо другая ОС с зрелой поддержкой виртуализации и Docker Compose. Система способна запуститься и на более слабом оборудовании, включая некоторые ARM-устройства, но документация прямо предупреждает о снижении скорости обработки и удобства.

Рекомендуемый базовый сервер

Для обычного развёртывания разработчики рекомендуют 16 ГБ RAM или больше, 64-битный процессор с 8 ядрами или более и частотой от 2 ГГц, а также SSD. Эти значения не являются пределом масштабирования. Для производственной системы ёмкость планируется отдельно с учётом роста архива, резервного копирования, времени восстановления, доступности и количества параллельных задач.

Что фактически ставит актуальный Compose

Указание PostgreSQL 13.11 в таблице минимальных требований не означает, что стоит вручную заменять базу в официальном Compose на эту версию. Текущий файл серии 4.12 по умолчанию закрепляет PostgreSQL 15.17, а образ Mayan EDMS — на ветке s4.12. Также используются RabbitMQ и Redis; Elasticsearch и Traefik включаются профилями при необходимости. Лучший вариант для нового сервера — сохранять версии из опубликованной конфигурации и менять их только после чтения release notes.

Преимущества и недостатки Mayan EDMS

Плюсы и минусы

Единая серверная модель. Версии, метаданные, права, события, поиск и workflow относятся к одному объекту документа, а не к разрозненным копиям в папках.

Неразрушающая обработка. Исходники сохраняются, а страничные преобразования и redaction-слои не требуют менять оригинал.

Автоматизация. Источники, OCR, фоновые очереди, workflow и REST API подходят для постоянного входящего потока.

Гранулярный доступ. Роли, разрешения и ACL позволяют отделить просмотр от скачивания и административных действий.

Self-hosted. Базовый сценарий можно держать в собственной инфраструктуре без обязательного облака.

Минусы

Сложная инфраструктура. За Compose остаются база данных, брокер, Redis, workers, резервные копии и обновления.

Ресурсоёмкость. OCR и фоновые задачи делают 4 ГБ нижней границей, а не комфортной производственной конфигурацией.

Не PDF-редактор. Для ручной правки текста и верстки нужен другой класс программ.

Высокий порог проектирования. Роли, метаданные и workflow требуют понимания процессов организации.

Обновления требуют дисциплины. Между сериями встречаются несовместимые изменения, поэтому нужны release notes и проверяемые backup-копии.

Сравнение с аналогами

Mayan EDMS стоит сравнивать прежде всего с системами управления архивом, а не с одиночными PDF-программами. Ниже — три соседних сценария, которые часто выглядят похожими только до момента постановки требований.

Относительно Sumatra PDF Mayan EDMS находится на другом уровне архитектуры. Sumatra удобна для локального открытия уже имеющегося файла и остаётся логичным дополнением к серверному архиву: документ можно скачать из Mayan EDMS и просмотреть локально. Но заменять Sumatra сервером ради чтения одного PDF нерационально, как и пытаться построить на просмотрщике централизованный документооборот.

Если задача не архивная, а настольная, выбор смещается в другие категории. Для глубокой правки PDF уместнее смотреть на Adobe Acrobat Pro, для настольного OCR и преобразования — на ABBYY FineReader, а для чтения и повседневной работы с PDF — на Foxit Reader. Эти программы не являются прямой заменой Mayan EDMS, потому что решают задачу на уровне одного рабочего места, а не общего репозитория.

Инструкция по установке

Подготовка и получение файлов

1. Выберите 64-битный сервер с Docker Compose; для постоянной работы предпочтителен GNU/Linux. Проверьте RAM и CPU: официальный минимум начинается с 4 ГБ, но базовая рекомендация — 16 ГБ и 8 ядер.

2. Создайте отдельный каталог развёртывания и через актуальную документацию 4.12.1 получите из основного GitLab два файла: docker-compose.yml и .env. Не используйте старое GitHub-зеркало.

3. До первого запуска просмотрите .env и замените защитные значения. Официальный шаблон отдельно предупреждает изменить учётные данные внутренних сервисов; при внешней публикации также задайте допустимые host names и настройте TLS.

Первый запуск

4. Запустите стек командой docker compose up —detach, затем проверьте docker compose ps. Ошибки смотрите через docker compose logs.

5. В стандартной конфигурации веб-интерфейс публикуется на порту 80. Первый запуск создаёт пользователя admin со случайным паролем, который показывается на странице входа; после входа пароль нужно сразу заменить.

6. Загрузите один небольшой файл через готовые Default document type и Default source и дождитесь превью и, если применимо, текста. Такой контроль отделяет проблему установки от ошибок будущей схемы классификации.

Безопасное удаление

docker compose down удаляет контейнеры, но сохраняет постоянные volumes. Перед намеренным удалением volumes сначала сохраните оригиналы, конфигурацию и проверенную резервную копию базы и хранилища: документация предупреждает, что удаление томов может уничтожить документы и данные приложения.

Обновление с запасным выходом

Проект требует последовательного перехода между сериями: сначала последний bugfix текущей серии, затем следующая. Перед обновлением прочитайте release notes и проверьте backup. Остановите стек, сохраните старые docker-compose.yml и .env, получите новые файлы, перенесите в них только локальные значения, выполните docker compose pull и снова docker compose up —detach. После миграций проверьте вход, выборку документов, загрузку, OCR, поиск, права и очереди. Для отката надёжнее восстанавливать согласованный backup со старой конфигурацией, чем запускать старый код поверх уже изменённой схемы базы.

Карта критических зависимостей

Обязательного аккаунта Mayan EDMS LLC и постоянного облачного соединения нет. Интернет нужен для получения образов и обновлений и для тех интеграций, которые администратор подключил сам. В изолированном контуре обновления и пакеты придётся переносить управляемым процессом.

Паспорт обратимости операций

Файл и версии. Загруженный оригинал хранится отдельно от представлений; новые версии не требуют уничтожать предыдущие. Проверка обратимости — скачать исходник и убедиться, что нужная версия доступна.

Страничные изменения и redaction. Поворот, обрезка, перестановка страниц и redaction-слои неразрушающие. Это сохраняет исходник, но означает, что визуальное скрытие не равно физическому удалению секретных данных из оригинального файла.

Серверные данные. Метаданные, теги, cabinets, индексы, ACL и workflow принадлежат модели Mayan EDMS и не обязаны быть встроены в PDF. Простого копирования файлов недостаточно для полноценной миграции; нужны база, API-выгрузка или иной план переноса структуры.

PDF-экспорт. Экспорт версии создаёт переносимый PDF из страниц выбранного представления, но не заменяет backup: роли, журналы, workflow и полная история репозитория в такой файл не помещаются.

Хронология развития и поддержки

2010–2011. Официальный сайт относит появление проекта к 2010 году, а релиз 4.0 в 2021 году отмечал десятилетие первого выпуска. Mayan EDMS изначально развивался как EDMS, а не как PDF-просмотрщик.

2024. В актуальной кодовой линии используется GPL 2.0; старые статьи с Apache 2.0 относятся к прежнему состоянию лицензии.

30 октября 2025 года, 4.10. Переход к PostgreSQL 15 и Elasticsearch 9, API throttling, интеграция OpenAI и новые локали, включая русскую.

25 февраля 2026 года, 4.11. Переход на Django 5.2 и Debian 13, поддержка ARM64 Docker images и переработка настроек.

16–21 августа 2026 года, 4.12 и 4.12.1. Bootstrap 5, новые responsive-режимы, светлый/тёмный режим, RTL, переработка очередей и измерения производительности; затем тайм-ауты внешних команд, исправление pdftotext и усиление REST API permission checks.

Практические кейсы

Архив счетов с поиском по содержимому

Цель: искать сканы по номеру, контрагенту и тексту. Подготовка: создать тип «Счёт», нужные метаданные, язык OCR и роли. Шаги: загрузить несколько типовых файлов, дождаться фоновой обработки, заполнить поля и теги. Проверка: найти документ по метаданным и по фразе из скана, затем скачать оригинал. Ограничение: качество OCR зависит от изображения и языка, критичные реквизиты нужно сверять.

Согласование договора

Цель: фиксировать этапы «получен → проверка → согласован → подписан». Подготовка: создать workflow, роли и разрешённые переходы. Шаги: привязать workflow к типу, загрузить договор и проводить его между состояниями. Проверка: под разными ролями убедиться, что доступны только разрешённые переходы, и просмотреть события. Ограничение: противоречивый бизнес-процесс сначала нужно формализовать вне программы.

Автоматический импорт вложений

Цель: не сохранять вручную вложения общего ящика. Подготовка: создать IMAP-источник и отдельные credentials. Шаги: связать источник с типом документа и последующей классификацией. Проверка: отправить безопасное тестовое вложение и убедиться, что оно появилось один раз и прошло обработку. Ограничение: почтовый импорт расширяет поверхность атаки; антивирус и политика неизвестных файлов настраиваются отдельно.

Разделение доступа к конфиденциальным документам

Цель: одной группе дать просмотр, другой — скачивание оригинала и администрирование. Подготовка: заранее спроектировать роли и ACL. Шаги: выдать разрешения на типы или объекты и при необходимости применить redaction-слои. Проверка: войти тестовыми пользователями и отдельно проверить доступ к исходнику. Ограничение: redaction не переписывает оригинальный файл.

Контроль перед сохранением и передачей

Перед внешней передачей сверяйте количество и порядок страниц, выбранную версию, OCR на критичных реквизитах, метаданные и права доступа к исходнику. Экспортированный PDF нужно открыть независимым просмотрщиком и проверить, что страницы читаются, а чувствительные данные действительно не доступны получателю. Для внешней выдачи полезно фиксировать, какая версия документа была передана.

Часто задаваемые вопросы

Что переносить при миграции со старой сетевой папки?

Не только файлы. Сначала определите будущие типы документов, обязательные метаданные, правила именования и владельцев доступа; затем импортируйте небольшой репрезентативный набор и проверьте поиск, OCR и права. Иначе хаос папок просто переедет в новый интерфейс.

Есть ли жёсткий предел количества документов?

Документация не задаёт единого лицензионного лимита для open-source установки и описывает масштабирование до миллионов документов. Реальный предел определяется архитектурой, storage, базой, поиском, количеством workers и требованиями к времени обработки.

Достаточно ли копии каталога с файлами для backup?

Нет. Репозиторий зависит от структурированных данных PostgreSQL и конфигурации, а не только от оригинальных файлов. Рабочая стратегия резервного копирования должна восстанавливать согласованное состояние базы, storage и настроек.

Что делать, если OCR не завершился?

Сначала проверьте error log объекта и состояние очередей, затем язык OCR, доступность Tesseract и качество исходника. В 4.12.1 внешние команды имеют тайм-ауты, поэтому ошибка может быть контролируемым завершением слишком долгой операции, а не зависанием системы.

Можно ли подключить существующее S3-совместимое хранилище?

Архитектура поддерживает подключаемые storage backends, включая S3 и MinIO. Но перенос уже работающего репозитория требует отдельного плана: нельзя считать смену backend равнозначной простому копированию папки.

Нужно ли включать ClamAV?

Это зависит от политики организации. Драйвер поддерживается, но для новых типов документов в 4.12 он не включается автоматически. Если входящие файлы приходят из почты или внешних источников, отсутствие автоматического включения нужно учитывать в модели безопасности.

Сломается ли старый API-клиент при обновлении?

Не обязательно, но release notes нужно читать до перехода. В 4.12 старый прямой endpoint загрузки уже помечен deprecated и запланирован к удалению в 5.0; новые интеграции лучше строить через Sources API и актуальную OpenAPI-схему.

Можно ли сочетать Mayan EDMS и Sumatra PDF?

Да. Mayan EDMS хранит и управляет документом на сервере, а Sumatra PDF удобно использовать как локальный просмотрщик скачанного PDF или другого поддерживаемого формата. Это дополняющие роли.

Вывод

Mayan EDMS подходит организациям, которым нужен не просто каталог файлов, а управляемый жизненный цикл документа: централизованный сервер, версии, OCR, метаданные, поиск, роли, ACL, workflow, события и API. Особенно хорошо продукт выглядит там, где важны самостоятельное размещение, точное разделение полномочий и возможность автоматизировать поступление документов из почты, папок и сканирующей инфраструктуры.

Цена этой функциональности — администрирование. Даже базовый Compose включает несколько сервисов, а серьёзный архив требует мониторинга, резервного копирования, плановых обновлений и предварительного проектирования ролей и метаданных. Для одиночного пользователя или команды без серверных компетенций такая архитектура может быть избыточной.

Если главная задача — быстро читать локальные PDF, лучше выбрать Sumatra PDF или другой просмотрщик. Если нужны ручная правка PDF и инструменты подготовки файла, логичнее настольный редактор. Если приоритет — максимально простой личный OCR-архив, стоит сравнить Paperless-ngx и Docspell. Mayan EDMS имеет смысл выбирать тогда, когда документ является объектом процесса и доступа, а не просто файлом, который нужно открыть.