Paperless-ngx server requirements: базовая конфигурация и принцип расчёта
Для Paperless-ngx с архивом до 1 000 документов достаточно 2 vCPU, 4 GB RAM и 80 GB NVMe-диска, но для массового OCR-импорта 10 000+ файлов нужны минимум 4 vCPU и 8 GB RAM.
Paperless-ngx — относительно лёгкое self-hosted приложение в режиме ожидания: веб-интерфейс, PostgreSQL, Redis и фоновые процессы обычно потребляют менее 1 vCPU. Нагрузка меняется при появлении новых документов. Каждый PDF, скан или изображение проходит OCR через OCRmyPDF и Tesseract; при включённых интеграциях Apache Tika и Gotenberg добавляются конвертация офисных файлов, извлечение текста и рендеринг PDF.
Поэтому paperless-ngx server requirements нельзя оценивать только по числу пользователей. Главные параметры — размер архива, дневной поток документов, процент сканов без текстового слоя, разрешение изображений и необходимость быстро обработать накопившуюся очередь.
Какие сервисы работают в Paperless-ngx
- PostgreSQL хранит метаданные, теги, корреспондентов, полнотекстовый индекс и настройки.
- Redis используется очередями и фоновыми задачами; обычно ему достаточно 128–512 MB RAM.
- Consumer отслеживает папку consume и запускает обработку документов.
- OCRmyPDF и Tesseract распознают сканы, создают searchable PDF и дают основной пик CPU.
- Gotenberg конвертирует DOCX, XLSX, HTML и другие офисные форматы в PDF.
- Apache Tika извлекает текст и метаданные из поддерживаемых форматов.
Почему конфигурацию выбирают по пикам, а не по простою
Один пользователь, открывающий документы в браузере, почти не нагружает сервер. Иная ситуация — загрузка 500 сканов по 5–20 страниц: несколько OCR-процессов способны занять все ядра на десятки минут или часы. Подход к выбору железа такой же, как при планировании других сервисов: сначала измеряют пиковую фоновую работу, затем оставляют запас. Этот принцип подробно разобран в материале о подборе железа для self-hosted приложений.
Paperless ngx hardware requirements по размеру архива
Paperless ngx hardware requirements зависят прежде всего от количества документов и характера импорта. Архив из 10 000 электронных PDF может занимать 10–30 GB, тогда как 10 000 сканированных договоров в 300 dpi нередко требуют 80–250 GB ещё до резервных копий.
Масштаб → спека
Для архива до 10 000 документов и регулярной OCR-загрузки достаточно 4 vCPU, 8 GB RAM, 200 GB NVMe-диска и порта 1 Gbps.
| Масштаб нагрузки | vCPU | RAM | Диск | Сетевой порт | Трафик | Цена |
|---|---|---|---|---|---|---|
| До 1 000 документов, до 50 новых в день | 2 vCPU | 4 GB | 80 GB NVMe | 1 Gbps | 1 TB/мес | ориентировочно от $8/мес |
| 1 000–10 000 документов, до 300 новых в день | 4 vCPU | 8 GB | 200 GB NVMe | 1 Gbps | 2 TB/мес | ориентировочно от $18/мес |
| 10 000–50 000 документов, до 1 000 новых в день | 6–8 vCPU | 16 GB | 500 GB NVMe | 1 Gbps | 3–5 TB/мес | ориентировочно от $35/мес |
| 50 000+ документов, массовый импорт и несколько пользователей | 8–12 vCPU | 24–32 GB | 1 TB NVMe | 1 Gbps | 5 TB+/мес | ориентировочно от $70/мес |
Цены указаны как общерыночный ориентир на март 2025 года для VPS соответствующего класса; фактическая стоимость зависит от локации, типа CPU, объёма NVMe и включённого трафика.
Как интерпретировать уровни нагрузки
Первый уровень подходит для домашнего архива, личных счетов, договоров и почты. 2 vCPU обработают OCR, но очередь из нескольких сотен документов будет разбираться не мгновенно. Это нормальный выбор, если импорт запускается ночью или файлы поступают постепенно.
Уровень 4 vCPU и 8 GB RAM — практический минимум для небольшой компании или отдела. Он позволяет держать PostgreSQL, Redis, контейнеры Paperless-ngx и Gotenberg без постоянного дефицита памяти, а также обрабатывать несколько документов параллельно.
Архив от 50 000 документов требует не только дополнительных ядер. Важны быстрый NVMe, резерв под рост хранилища, регулярное обслуживание PostgreSQL и независимые резервные копии. Если на том же сервере работают другие сервисы, ресурсы Paperless-ngx лучше не смешивать с критичными базами данных.
Ищете надёжный сервер для ваших проектов?
VPS от $10/мес и выделенные серверы от $9/мес с NVMe, DDoS-защитой и поддержкой 24/7.
Смотреть предложения →Paperless ngx RAM CPU: что происходит при OCR и конвертации
Paperless ngx RAM CPU потребляет неравномерно: в простое стек часто укладывается в 1–2 GB RAM и доли одного ядра, а при OCR один тяжёлый скан способен полностью занять 1 CPU-поток.
Производительность OCR: реальные ориентиры
Tesseract в составе OCRmyPDF хорошо масштабируется по числу одновременно обрабатываемых документов, но не превращает один документ в идеально многопоточный процесс. На современном CPU с частотой около 3,0 GHz одна страница A4 в 300 dpi обычно распознаётся за 1–5 секунд, однако цветные сканы, таблицы, плохой контраст и 600 dpi могут увеличить время до 10–30 секунд на страницу.
Практический ориентир: сервер с 4 быстрыми vCPU способен обработать примерно 1 000–3 000 обычных страниц в час при параллельной очереди, если диск не является узким местом. На 2 медленных shared vCPU та же задача может занять в 2–4 раза больше времени. Для OCR важнее производительность одного ядра и отсутствие жёсткого CPU throttling, чем номинально большое число виртуальных ядер.
Tika и Gotenberg: когда нужны дополнительные ресурсы
Paperless ngx ocr server specs должны учитывать Tika и Gotenberg только при работе с офисными документами, письмами, презентациями и HTML. Gotenberg использует Chromium или LibreOffice-подобные процессы и может кратковременно занять 500 MB–1,5 GB RAM на конвертацию сложного файла. Для сервера с Gotenberg не стоит выбирать менее 4 GB RAM, даже если сам архив небольшой.
Ограничивайте параллелизм потребителей, если VPS используется совместно с другими приложениями. Например, стартовая настройка Docker Compose может выглядеть так:
services:
webserver:
image: ghcr.io/paperless-ngx/paperless-ngx:latest
environment:
PAPERLESS_THREADS_PER_WORKER: "2"
PAPERLESS_WORKERS: "2"
PAPERLESS_OCR_LANGUAGE: "rus+eng"
PAPERLESS_TASK_WORKERS: "2"На 2 vCPU логично начать с 1–2 OCR-задач, на 4 vCPU — с 2–4. После массового импорта проверьте загрузку CPU, использование памяти и длину очереди, а не увеличивайте workers вслепую.
Сколько RAM для Paperless-ngx и как рассчитать диск
На вопрос «сколько RAM для Paperless ngx» практический ответ такой: 4 GB — минимум для личного архива, 8 GB — комфортный уровень с Gotenberg, 16 GB — рабочая норма для 10 000–50 000 документов и параллельного импорта.
Память: контейнеры, файловый кэш и база данных
Не выделяйте RAM только по сумме потребления контейнеров. Linux использует свободную память под файловый кэш, а PostgreSQL выигрывает от кэша индекса и часто запрашиваемых метаданных. На VPS с 4 GB после запуска Paperless-ngx, PostgreSQL, Redis и Gotenberg свободный запас может быстро сократиться до 1 GB. При конвертации DOCX или OCR крупных PDF начинается swap, а время обработки растёт в разы.
- 4 GB RAM: до 1 000–3 000 документов, 1–2 фоновых worker, без тяжёлых пакетных загрузок.
- 8 GB RAM: до 10 000 документов, 2–4 worker, Tika/Gotenberg и ежедневный импорт.
- 16 GB RAM: архив до 50 000 документов, несколько пользователей, запас для PostgreSQL и импорта.
- 24–32 GB RAM: крупный архив, 8+ OCR-потоков, соседние сервисы или обработка больших TIFF/PDF.
Формула для хранилища
Размер диска нужно считать по оригиналам, а не по размеру PostgreSQL. Используйте формулу: архив оригиналов × 1,5 + 20–50 GB на систему, БД и временные файлы. Коэффициент 1,5 покрывает PDF после OCR, thumbnails, индекс, временные данные и умеренный рост.
Например, если текущие документы занимают 120 GB, разумный минимум — 200 GB NVMe, но для роста в течение года лучше 300–400 GB. Не храните единственную резервную копию на том же диске: сбой файловой системы, ошибочное удаление или компрометация сервера затронут и архив, и backup.
Для стратегии хранения полезно применить подходы из статьи о расчёте объёма бэкапов и дедупликации: резервируйте отдельное пространство и проверяйте восстановление, а не только факт успешного запуска задания.
Сервер Paperless ngx требования к сети, диску и безопасности
Сервер Paperless ngx требования к сети обычно невысоки: для одного офиса достаточно порта 1 Gbps, а критичнее стабильный канал и достаточный месячный трафик для загрузок и резервного копирования.
Трафик: что реально передаётся
При работе через браузер пользователи загружают оригиналы и скачивают PDF. Если в месяц принимается 500 документов по 10 MB, входящий объём составит около 5 GB. Основной расход появляется при резервном копировании: архив на 200 GB при первой выгрузке передаст примерно 200 GB, а последующие инкрементальные копии — только изменённые данные.
Порт 1 Gbps теоретически передаёт до 125 MB/s, но скорость ограничивают диск, маршрут, производительность VPS и удалённое хранилище. Для начальной синхронизации 200 GB закладывайте несколько часов, а не 30 минут. При доступе через интернет используйте HTTPS, сложные пароли, двухфакторную аутентификацию при наличии внешнего SSO и ограничение доступа по VPN или firewall.
NVMe важнее большого SATA-диска
OCR читает оригинал, создаёт промежуточные файлы, пишет итоговый PDF и обновляет PostgreSQL. Медленный диск увеличивает задержку всей очереди. NVMe с десятками тысяч IOPS заметно лучше подходит для одновременной работы базы и импорта, чем HDD. SATA SSD приемлем для небольшого архива до 1 000 документов, но для 10 000+ документов предпочтителен NVMe.
Если требуется изолированное железо, RAID, большой локальный массив или десятки параллельных задач, ориентируйтесь на подбор выделенного Linux-сервера под задачу. Выделенный сервер особенно оправдан, когда Paperless-ngx становится частью корпоративного документооборота, а не личным архивом.
Paperless ngx self hosted hardware: VPS или выделенный сервер
Paperless ngx self hosted hardware в большинстве случаев начинается с VPS: до 10 000 документов нет необходимости платить за физический сервер, если доступны 4 vCPU, 8 GB RAM и NVMe-хранилище.
Когда достаточно VPS
VPS подходит для личного архива, небольшой компании, отдела до 20 сотрудников и постепенной загрузки документов. Выбирайте конфигурацию с возможностью увеличить RAM и диск без сложной миграции. Для OCR предпочтительны CPU с предсказуемой производительностью: дешёвый VPS с высокими лимитами соседей может показывать нестабильную скорость распознавания.
Оптимальная стартовая схема — отдельный VPS для Paperless-ngx, Docker Compose, ежедневный дамп PostgreSQL и удалённая копия каталога media. Не публикуйте PostgreSQL и Redis в интернет: наружу должен быть доступен только reverse proxy или веб-контейнер по HTTPS.
Когда переходить на выделенный сервер
Выделенный сервер нужен при архиве 50 000+ документов, ежедневной обработке тысяч страниц, требованиях к локальному RAID, большом числе интеграций либо одновременном размещении нескольких внутренних сервисов. Конфигурация уровня 8 ядер с частотой 3,0 GHz+, 32 GB ECC RAM и 2 × 1 TB NVMe в RAID 1 обеспечивает заметно более предсказуемую обработку, чем перегруженный VPS.
Не размещайте на одном узле ресурсоёмкие LLM, видеокодирование и OCR без жёстких лимитов контейнеров: сервисы будут конкурировать за CPU и память. Если в инфраструктуре есть локальные модели, учитывайте рекомендации по self-hosted ИИ, RAM и VRAM отдельно от ресурсов документооборота.
Развёртывание и настройка производительности Paperless-ngx
Стабильная работа Paperless-ngx начинается с разделения данных, правильных лимитов Docker и контроля свободного места: заполненный на 100% диск способен остановить и PostgreSQL, и импорт документов.
Минимальные параметры Docker Compose
Для production-развёртывания закрепите каталоги данных на NVMe, настройте часовой пояс, языки OCR и регулярные backup-задачи. Пример ключевых переменных:
services:
webserver:
environment:
PAPERLESS_REDIS: redis://redis:6379
PAPERLESS_DBHOST: db
PAPERLESS_DATA_DIR: /usr/src/paperless/data
PAPERLESS_MEDIA_ROOT: /usr/src/paperless/media
PAPERLESS_CONSUMPTION_DIR: /usr/src/paperless/consume
PAPERLESS_OCR_LANGUAGE: rus+eng
PAPERLESS_TIME_ZONE: Europe/Moscow
PAPERLESS_URL: https://paperless.example.comКаталоги data, media и база PostgreSQL должны быть на persistent volumes. Папка consume может временно разрастаться при ошибке OCR, поэтому контролируйте её отдельно.
Проверка очереди и состояния контейнеров
После импорта 100–200 тестовых документов проверьте фактическую загрузку. Команды для базовой диагностики:
docker compose ps
docker stats --no-stream
docker compose logs --tail=100 webserver
df -h
free -h
uptimeЕсли CPU постоянно держится выше 90% более 30 минут, а очередь не уменьшается, сначала снизьте число параллельных задач или увеличьте число vCPU. Если свободной памяти меньше 500 MB и активен swap, увеличивайте RAM. При заполнении NVMe выше 80% расширяйте том заранее: PostgreSQL и Docker требуют свободного пространства для нормальной работы.
Резервное копирование, обновления и контроль ресурсов
Для Paperless-ngx недостаточно копировать только PDF: полноценное восстановление требует оригиналов, базы PostgreSQL, конфигурации и ключей, используемых для шифрования или интеграций.
Что включать в backup
- Каталог
mediaс оригинальными и обработанными документами. - Дамп PostgreSQL не реже 1 раза в сутки.
- Файлы Docker Compose,
.envи конфигурацию reverse proxy. - Ключи и секреты, включая
PAPERLESS_SECRET_KEY, в защищённом хранилище. - Отдельную копию за пределами основного VPS или выделенного сервера.
Проверяйте восстановление хотя бы раз в квартал на тестовой машине. Backup в 300 GB, который никогда не разворачивали, не является подтверждённой защитой. Для критичного архива используйте правило 3-2-1: 3 копии, 2 разных носителя, 1 копия вне основной площадки.
Когда масштабировать конфигурацию
Сигналы для апгрейда понятны: средняя загрузка CPU при импорте выше 80%, OCR-очередь не успевает обработаться за рабочую ночь, swap используется постоянно, свободно менее 20% диска или запросы к интерфейсу стали заметно медленнее. В такой ситуации сначала добавляют vCPU для OCR, затем RAM для базы и кэша, после чего расширяют NVMe.
Не путайте высокую CPU-нагрузку во время разовой миграции с постоянной потребностью в дорогой конфигурации. Импорт 30 000 старых файлов можно выполнить на временно усиленном сервере, а после обработки уменьшить ресурсы до уровня ежедневной эксплуатации.
Часто задаваемые вопросы
Ответы по ресурсам Paperless-ngx
Сколько RAM нужно для Paperless-ngx? Для личного архива до 1 000 документов достаточно 4 GB RAM. Если включены Gotenberg, Apache Tika и регулярная OCR-обработка, выбирайте 8 GB. Для 10 000–50 000 документов, нескольких пользователей и 4+ фоновых задач разумно выделить 16 GB RAM, чтобы избежать постоянного swap.
Сколько vCPU нужно для OCR в Paperless-ngx? Минимум — 2 vCPU для редкого импорта, но 4 vCPU заметно комфортнее для ежедневной обработки. При загрузке 1 000 и более страниц в день выбирайте 6–8 vCPU. Один OCR-процесс может занимать почти целое ядро, поэтому число ядер определяет скорость разбора очереди.
Нужен ли NVMe-диск для Paperless-ngx? Для архива до 1 000 документов можно использовать SATA SSD, однако для 10 000+ файлов рекомендуется NVMe. Paperless-ngx одновременно читает оригиналы, создаёт временные PDF, записывает thumbnails и обновляет PostgreSQL. Практический минимум — 80 GB NVMe, а для среднего архива чаще нужен объём 200 GB.
Можно ли установить Paperless-ngx на VPS с 2 GB RAM? Технически минимальная установка без тяжёлой обработки иногда запускается на 2 GB RAM, но для production это рискованно. PostgreSQL, Redis, контейнер Paperless-ngx и OCR могут вызвать swap или OOM при одном крупном PDF. Для надёжной эксплуатации используйте минимум 4 GB RAM и 2 vCPU.
Выводы
Рекомендация по выбору сервера
Для большинства архивов Paperless-ngx до 10 000 документов выбирайте VPS с 4 vCPU, 8 GB RAM и 200 GB NVMe. При массовом OCR, архиве 50 000+ файлов или ежедневной загрузке тысяч страниц переходите на 8 vCPU, 16–32 GB RAM и NVMe от 1 TB с отдельными резервными копиями.
NVMe VPS с активацией за 60 секунд: полный root-доступ, 20+ локаций, оплата картой или криптой.
Выбрать тариф
