Stirling PDF или Paperless-ngx: что выгоднее и когда

MAATRIX

Когда в компании накапливаются сканы, счета и договоры, а PDF нужно то склеить, то сжать, то распознать текст — рано или поздно встаёт вопрос: поднять один сервис на все случаи или два разных под разные задачи. Stirling PDF и Paperless-ngx на первый взгляд решают похожую проблему «что-то с PDF», но по сути это инструменты из разных категорий. Разберёмся, чем они отличаются на уровне архитектуры, сколько ресурсов сервера съедают и в каком сценарии переплата за «второй сервис» на самом деле экономит время.

Что это на самом деле: инструмент против архива

Первая ошибка при выборе — сравнивать их как конкурентов. Это не так.

Stirling PDF — веб-интерфейс и API поверх набора операций с PDF: слияние, разбиение, сжатие, конвертация в/из других форматов, поворот страниц, добавление водяных знаков, электронная подпись, распознавание текста (OCR) через встроенный OCRmyPDF. Это инструмент активного действия: вы загружаете файл, что-то с ним делаете, скачиваете результат. По умолчанию Stirling PDF ничего не хранит — файл живёт в контейнере ровно на время обработки, если явно не подключить постоянное хранилище для конфигураций и пользовательских шаблонов.

Paperless-ngx — система управления документами (DMS). Задача другая: принять поток документов (через папку consume, email-ящик или сканер с прямой выгрузкой), прогнать через OCR, распознать дату, отправителя, теги, положить в архив и дать полнотекстовый поиск по всему, что накопилось за годы. Это не инструмент разового действия, а постоянно работающий архив с базой данных, к которому вы возвращаетесь месяцами позже со словами «где тот счёт от поставщика за март».

Разница похожа на разницу между ножом и картотекой: нож ускоряет одно конкретное действие, картотека делает так, чтобы вы вообще не теряли то, что туда положили. У обоих есть OCR — это единственная точка пересечения функциональности, а не повод считать их взаимозаменяемыми.

Требования к серверу: разница в разы

Это первое, что стоит понять до аренды VPS — стек Paperless-ngx кратно тяжелее, и это не вопрос настройки, а архитектуры.

Если у вас на сервере уже крутятся другие сервисы и вы хотите добавить только «конвертер PDF» — Stirling PDF почти не заметен по нагрузке, его можно посадить рядом с чем угодно на минимальном VPS. Paperless-ngx же стоит закладывать как отдельный проект с прицелом на рост диска: архив документов за пару лет активного использования небольшой компании легко доходит до десятков гигабайт с учётом оригиналов, OCR-слоя и превью.

Если ресурсы уже поджаты, есть смысл сначала прикинуть нагрузку на конкретном тарифе — ориентиры по CPU/RAM для типовыхself-hosted стеков разбирали в статье про лимиты ресурсов Docker по CPU и памяти.

Функциональность: что реально умеет каждый

Stirling PDF закрывает разовые операции:

• слияние/разбиение/пересортировка страниц;
• сжатие PDF (полезно перед отправкой по почте, где лимит вложения 10–25 МБ);
• конвертация PDF ↔ Word/Excel/изображения;
• OCR отдельного файла (слой распознанного текста поверх скана);
• водяные знаки, штампы, защита паролем, электронная подпись;
• API — можно дёргать операции скриптом без открытия веб-интерфейса.

Paperless-ngx закрывает архивацию и поиск:

• автоматический приём документов из папки, IMAP-ящика или через мобильное приложение;
• OCR каждого документа при поступлении с сохранением оригинала и текстового слоя;
• теги, корреспонденты, типы документов, кастомные поля — и правила автотегирования по содержимому;
• полнотекстовый поиск по всему архиву, включая содержимое сканов;
• сроки хранения (retention policy) и экспорт/импорт всей базы для миграции;
• workflow-автоматизация: например, документы от определённого отправителя автоматически получают тег и переезжают в нужную папку.

Обратите внимание: у Paperless-ngx нет функций редактирования PDF — он не сжимает, не объединяет и не конвертирует файлы под произвольную задачу, только принимает и архивирует. А у Stirling PDF нет постоянного хранилища и поиска — обработали файл, скачали, всё. Один не заменяет другой ни по одному пункту, кроме OCR.

Сценарии: когда что выбрать

Практический чеклист вместо абстрактного сравнения.

Ставьте только Stirling PDF, если:

• вам нужно периодически (не каждый день) что-то сделать с PDF — сжать перед отправкой, слить сканы в один файл, подписать договор;
• документы не нужно хранить в системе — конечный результат уходит клиенту или в другую систему;
• вы уже используете Nextcloud, Google Drive или файловый сервер как основное хранилище, а PDF-операции — просто утилита сбоку;
• сервер и так небольшой, а тратить ресурсы на СУБД ради редких операций не хочется.

Ставьте только Paperless-ngx, если:

• в компанию физически или на почту стабильно приходит поток документов (счета, акты, договоры, письма от контрагентов), которые нужно находить месяцы спустя;
• важен полнотекстовый поиск «по содержимому», а не по имени файла;
• нужна юридическая прослеживаемость — кто, когда и в каком виде получил документ;
• есть сканер с функцией выгрузки в сетевую папку или на email — тогда архивация происходит вообще без ручных действий.

Ставьте оба, если у вас есть и поток входящих документов (нужна архивация), и регулярная работа с PDF-файлами перед отправкой куда-то во внешний мир (нужны операции). Это довольно частый случай для бухгалтерии или юридического отдела: входящие акты архивируются в Paperless-ngx, а исходящие договоры перед отправкой контрагенту сжимаются и подписываются через Stirling PDF.

Установка: минимальный docker-compose для каждого

Оба сервиса разворачиваются через Docker Compose, это самый быстрый путь на чистом VPS.

Stirling PDF — один контейнер, работает сразу после docker compose up -d:

services:
  stirling-pdf:
    image: stirlingtools/stirling-pdf:latest
    container_name: stirling-pdf
    ports:
      - "8080:8080"
    volumes:
      - ./stirling-config:/configs
      - ./stirling-logs:/logs
    environment:
      - DOCKER_ENABLE_SECURITY=false
      - LANGS=ru_RU
    restart: unless-stopped

Подробный пошаговый разбор для Ubuntu 24.04, включая настройку авторизации и языковых пакетов OCR, — в статье Stirling PDF на Ubuntu 24.04: пошаговая установка. Если после запуска что-то падает или не открывается веб-интерфейс — частые причины и решения собраны в Stirling PDF на сервере: частые ошибки и решения.

Paperless-ngx требует минимум трёх контейнеров — база, брокер очередей и сам веб-сервис:

services:
  broker:
    image: redis:7
    restart: unless-stopped

  db:
    image: postgres:16
    restart: unless-stopped
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: paperless
      POSTGRES_USER: paperless
      POSTGRES_PASSWORD: paperless

  webserver:
    image: ghcr.io/paperless-ngx/paperless-ngx:latest
    restart: unless-stopped
    depends_on:
      - db
      - broker
    ports:
      - "8000:8000"
    environment:
      PAPERLESS_REDIS: redis://broker:6379
      PAPERLESS_DBHOST: db
      PAPERLESS_OCR_LANGUAGE: rus+eng
    volumes:
      - ./consume:/usr/src/paperless/consume
      - ./media:/usr/src/paperless/media
      - ./data:/usr/src/paperless/data
      - ./export:/usr/src/paperless/export

volumes:
  pgdata:

Пароль базы в примере вынесен намеренно упрощённо — в проде используйте .env-файл и не коммитьте секреты. Полный разбор установки, включая настройку email-приёма и первого суперпользователя, — в статье как установить и настроить Paperless-ngx на VPS.

Оба сервиса стоит прятать за обратным прокси с HTTPS — если ещё не определились с выбором прокси, сравнение вариантов есть в статье Traefik или Nginx Proxy Manager: что выбрать для сервера.

Комбинация: Stirling PDF как препроцессор перед Paperless-ngx

Связка «Stirling PDF на входе → Paperless-ngx на архивации» решает проблему, с которой сталкиваются почти все, кто сканирует пачками: сканер часто отдаёт один PDF на 20 страниц, где на самом деле пять разных документов. Paperless-ngx умеет разбирать такие файлы, но не идеально — а вручную резать PDF на части неудобно без специального инструмента.

Практическая схема:

1. Скан целиком выгружается не сразу в consume-папку Paperless-ngx, а во временную папку.
2. Через API Stirling PDF (/api/v1/general/split-pages и похожие эндпоинты) файл разбивается на отдельные документы по номерам страниц.
3. Результат скриптом (curl + cron или простой shell-скрипт) перекладывается в consume-папку Paperless-ngx.
4. Paperless-ngx подхватывает уже разделённые файлы, OCR'ит и раскладывает по тегам.

Это же имеет смысл для сжатия: если сканер отдаёт тяжёлые файлы по 15–20 МБ на страницу, прогон через Stirling PDF перед архивацией экономит место на диске в разы — а диск у Paperless-ngx только растёт, обратного пути (кроме ручной чистки) там нет.

Обратная связка тоже работает: документ, найденный в архиве Paperless-ngx, перед отправкой клиенту (например, нужно наложить водяной знак «копия» или удалить лишние страницы) скачивается и прогоняется через Stirling PDF — архив остаётся неизменным источником истины, а модификации происходят только с копией.

Что выбрать: короткий чеклист

Если сомневаетесь — задайте себе один вопрос: вы храните документы или обрабатываете их?

• Обрабатываете (разово, перед отправкой, без цели найти файл через полгода) — берите Stirling PDF, минимальный VPS, разворачивается за 10 минут.
• Храните и потом ищете — берите Paperless-ngx, закладывайте сервер побольше и план резервного копирования базы данных (без бэкапа PostgreSQL потеря архива необратима — это не файлы, которые можно скачать заново).
• И то и другое одновременно на постоянной основе — не экономьте на объединении в один контейнер, разносите по своим томам и, если позволяет нагрузка, по разным серверам: так проще масштабировать архив отдельно от нагрузки на конвертацию.

Частые вопросы