Системні вимоги Paperless-ngx: базова конфігурація та розрахунок ресурсів
Для 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 залежно від розміру архіву
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, навіть якщо сам архів невеликий.
Обмежуйте паралелізм consumer-процесів, якщо 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: 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+ локацій, оплата карткою або криптовалютою.
Обрати тариф
