Paperless-ngx hardware requirements: baseline specs and sizing guide
For a Paperless-ngx archive of up to 1,000 documents, 2 vCPU, 4 GB RAM, and 80 GB NVMe storage are enough, but bulk OCR imports of 10,000+ files need at least 4 vCPU and 8 GB RAM.
Paperless-ngx is a relatively lightweight self-hosted application while idle: the web interface, PostgreSQL, Redis, and background processes typically use less than 1 vCPU. Load changes when new documents arrive. Every PDF, scan, or image goes through OCR with OCRmyPDF and Tesseract; enabled Apache Tika and Gotenberg integrations add office document conversion, text extraction, and PDF rendering.
That is why paperless-ngx server requirements cannot be estimated from the number of users alone. The main factors are archive size, daily document volume, the percentage of scans without a text layer, image resolution, and how quickly you need to clear a backlog.
Services that run in Paperless-ngx
- PostgreSQL stores metadata, tags, correspondents, the full-text index, and settings.
- Redis is used by queues and background tasks; it typically needs 128–512 MB RAM.
- Consumer monitors the consume directory and starts document processing.
- OCRmyPDF and Tesseract recognize scans, create searchable PDFs, and cause the main CPU spikes.
- Gotenberg converts DOCX, XLSX, HTML, and other office formats to PDF.
- Apache Tika extracts text and metadata from supported formats.
Why you should size for peak load, not idle usage
One user opening documents in a browser places almost no load on the server. Uploading 500 scans with 5–20 pages each is different: several OCR processes can occupy all CPU cores for tens of minutes or hours. The hardware sizing approach is the same as for other services: measure peak background workloads first, then leave capacity headroom. This principle is covered in detail in our guide to sizing hardware for self-hosted applications.
Paperless ngx hardware requirements by archive size
Paperless ngx hardware requirements depend primarily on document count and import patterns. An archive of 10,000 digital PDFs may use 10–30 GB, while 10,000 scanned contracts at 300 dpi often require 80–250 GB before backups.
Load scale → specs
For an archive of up to 10,000 documents with regular OCR uploads, 4 vCPU, 8 GB RAM, 200 GB NVMe storage, and a 1 Gbps port are sufficient.
| Load scale | vCPU | RAM | Storage | Network port | Bandwidth | Price |
|---|---|---|---|---|---|---|
| Up to 1,000 documents, up to 50 new documents per day | 2 vCPU | 4 GB | 80 GB NVMe | 1 Gbps | 1 TB/month | approximately from $8/month |
| 1,000–10,000 documents, up to 300 new documents per day | 4 vCPU | 8 GB | 200 GB NVMe | 1 Gbps | 2 TB/month | approximately from $18/month |
| 10,000–50,000 documents, up to 1,000 new documents per day | 6–8 vCPU | 16 GB | 500 GB NVMe | 1 Gbps | 3–5 TB/month | approximately from $35/month |
| 50,000+ documents, bulk imports, and multiple users | 8–12 vCPU | 24–32 GB | 1 TB NVMe | 1 Gbps | 5 TB+/month | approximately from $70/month |
Prices are general market estimates as of March 2025 for VPS plans in this class; actual cost depends on location, CPU type, NVMe capacity, and included bandwidth.
How to interpret the load tiers
The first tier is suitable for a home archive, personal bills, contracts, and mail. 2 vCPU can handle OCR, but a queue of several hundred documents will not clear instantly. It is a sensible option when imports run overnight or files arrive gradually.
The 4 vCPU and 8 GB RAM tier is a practical minimum for a small business or department. It can run PostgreSQL, Redis, Paperless-ngx containers, and Gotenberg without constant memory pressure while processing several documents in parallel.
An archive of 50,000 documents or more needs more than additional CPU cores. Fast NVMe, storage growth capacity, regular PostgreSQL maintenance, and independent backups are important. If other services run on the same server, do not mix Paperless-ngx resources with critical databases.
Looking for a reliable server for your projects?
VPS plans from $10/month and dedicated servers from $9/month with NVMe, DDoS protection, and 24/7 support.
View plans →Paperless ngx RAM CPU usage during OCR and conversion
Paperless ngx RAM CPU usage is uneven: while idle, the stack often fits within 1–2 GB RAM and a fraction of one CPU core, while OCR for one large scan can fully use 1 CPU thread.
OCR performance: practical benchmarks
Tesseract within OCRmyPDF scales well with the number of documents processed concurrently, but it does not turn a single document into a perfectly multithreaded workload. On a modern CPU running at around 3.0 GHz, one A4 page at 300 dpi is typically recognized in 1–5 seconds. Color scans, tables, poor contrast, and 600 dpi can increase this to 10–30 seconds per page.
As a practical benchmark, a server with 4 fast vCPU can process approximately 1,000–3,000 standard pages per hour with a parallel queue, provided storage is not the bottleneck. On 2 slow shared vCPU, the same workload can take 2–4 times longer. For OCR, single-core performance and the absence of aggressive CPU throttling matter more than a high nominal number of virtual cores.
Tika and Gotenberg: when you need more resources
Paperless ngx ocr server specs should account for Tika and Gotenberg only when processing office documents, emails, presentations, and HTML. Gotenberg uses Chromium or LibreOffice-like processes and can temporarily consume 500 MB–1.5 GB RAM when converting a complex file. For a server running Gotenberg, do not choose less than 4 GB RAM even if the archive itself is small.
Limit consumer parallelism if the VPS is shared with other applications. For example, a starting Docker Compose configuration can look like this:
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"On 2 vCPU, it makes sense to start with 1–2 OCR tasks; on 4 vCPU, start with 2–4. After a bulk import, check CPU load, memory usage, and queue length instead of blindly increasing workers.
How much RAM does Paperless-ngx need and how to size storage
The practical answer to “how much RAM for Paperless ngx” is: 4 GB is the minimum for a personal archive, 8 GB is a comfortable level with Gotenberg, and 16 GB is the working standard for 10,000–50,000 documents and parallel imports.
Memory: containers, file cache, and the database
Do not allocate RAM based only on the combined memory usage of containers. Linux uses free memory for file cache, while PostgreSQL benefits from caching indexes and frequently requested metadata. On a 4 GB VPS, free capacity may quickly fall to 1 GB after starting Paperless-ngx, PostgreSQL, Redis, and Gotenberg. During DOCX conversion or OCR of large PDFs, swap starts being used and processing time can increase severalfold.
- 4 GB RAM: up to 1,000–3,000 documents, 1–2 background workers, without heavy batch uploads.
- 8 GB RAM: up to 10,000 documents, 2–4 workers, Tika/Gotenberg, and daily imports.
- 16 GB RAM: an archive of up to 50,000 documents, multiple users, and headroom for PostgreSQL and imports.
- 24–32 GB RAM: a large archive, 8+ OCR threads, colocated services, or processing large TIFF/PDF files.
Storage sizing formula
Calculate disk capacity from the original files, not PostgreSQL size. Use the formula: original archive size × 1.5 + 20–50 GB for the system, database, and temporary files. The 1.5 multiplier covers OCR-generated PDFs, thumbnails, the index, temporary data, and moderate growth.
For example, if your current documents use 120 GB, a reasonable minimum is 200 GB NVMe, but 300–400 GB is better for a year of growth. Do not keep the only backup on the same disk: a filesystem failure, accidental deletion, or server compromise affects both the archive and the backup.
For your storage strategy, apply the approaches from our guide to backup sizing and deduplication: reserve separate capacity and test restores, not just whether a job completed successfully.
Paperless ngx server requirements for network, storage, and security
Paperless ngx server requirements for networking are usually modest: a 1 Gbps port is enough for one office, while a stable connection and sufficient monthly bandwidth for uploads and backups matter more.
Bandwidth: what is actually transferred
When using the browser interface, users upload originals and download PDFs. If 500 documents averaging 10 MB are received each month, inbound data totals about 5 GB. Backups create the main bandwidth usage: an archive of 200 GB transfers approximately 200 GB during the first upload, while later incremental copies transfer only changed data.
A 1 Gbps port can theoretically transfer up to 125 MB/s, but speed is limited by storage, routing, VPS performance, and remote storage. Allow several hours, rather than 30 minutes, for an initial 200 GB sync. For internet access, use HTTPS, strong passwords, two-factor authentication where external SSO is available, and access restrictions through a VPN or firewall.
NVMe matters more than a large SATA drive
OCR reads the original file, creates intermediate files, writes the final PDF, and updates PostgreSQL. Slow storage increases latency across the entire queue. NVMe with tens of thousands of IOPS is significantly better suited to simultaneous database activity and imports than HDD storage. A SATA SSD is acceptable for a small archive of up to 1,000 documents, but NVMe is preferable for 10,000+ documents.
If you need isolated hardware, RAID, a large local array, or dozens of parallel tasks, see our guide to choosing a dedicated Linux server for your workload. A dedicated server is especially worthwhile when Paperless-ngx becomes part of a company document workflow rather than a personal archive.
Paperless ngx self hosted hardware: VPS vs dedicated server
Paperless ngx self hosted hardware usually starts with a VPS: for up to 10,000 documents, there is no need to pay for a physical server if you have 4 vCPU, 8 GB RAM, and NVMe storage.
When a VPS is enough
A VPS is suitable for a personal archive, a small business, a department of up to 20 employees, and gradual document uploads. Choose a configuration that lets you increase RAM and storage without a difficult migration. For OCR, CPUs with predictable performance are preferable: an inexpensive VPS with high noisy-neighbor limits can deliver inconsistent recognition speed.
An optimal starting setup is a separate VPS for Paperless-ngx, Docker Compose, a daily PostgreSQL dump, and a remote copy of the media directory. Do not expose PostgreSQL and Redis to the internet: only the reverse proxy or web container should be publicly accessible over HTTPS.
When to move to a dedicated server
A dedicated server is needed for an archive of 50,000+ documents, daily processing of thousands of pages, local RAID requirements, many integrations, or hosting several internal services at the same time. A configuration with 8 cores at 3.0 GHz+, 32 GB ECC RAM, and 2 × 1 TB NVMe in RAID 1 provides substantially more predictable processing than an overloaded VPS.
Do not run resource-intensive LLMs, video encoding, and OCR on the same node without strict container limits: the services will compete for CPU and memory. If your infrastructure includes local models, consider the recommendations for self-hosted AI, RAM, and VRAM separately from document management resources.
How to deploy and tune Paperless-ngx performance
Stable Paperless-ngx operation starts with separating data, setting proper Docker limits, and monitoring free space: a disk filled to 100% can stop both PostgreSQL and document imports.
Minimum Docker Compose settings
For a production deployment, place data directories on NVMe, configure the timezone, OCR languages, and regular backup jobs. Example key variables:
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.comThe data, media, and PostgreSQL database directories must use persistent volumes. The consume directory can grow temporarily after an OCR failure, so monitor it separately.
Checking the queue and container status
After importing 100–200 test documents, check actual resource utilization. Commands for basic diagnostics:
docker compose ps
docker stats --no-stream
docker compose logs --tail=100 webserver
df -h
free -h
uptimeIf CPU remains above 90% for more than 30 minutes and the queue does not shrink, first reduce the number of parallel tasks or increase vCPU. If free memory is below 500 MB and swap is active, add RAM. If NVMe utilization exceeds 80%, expand the volume in advance: PostgreSQL and Docker need free space to operate normally.
Backups, updates, and resource monitoring
For Paperless-ngx, copying PDFs alone is not enough: a full recovery requires originals, the PostgreSQL database, configuration files, and keys used for encryption or integrations.
What to include in backups
- The
mediadirectory with original and processed documents. - A PostgreSQL dump at least once per day.
- Docker Compose files,
.env, and reverse proxy configuration. - Keys and secrets, including
PAPERLESS_SECRET_KEY, in secure storage. - A separate copy outside the primary VPS or dedicated server.
Test recovery on a test machine at least once per quarter. A 300 GB backup that has never been restored is not verified protection. For critical archives, use the 3-2-1 rule: 3 copies, 2 different media types, and 1 copy off-site.
When to scale the configuration
Upgrade signals are clear: average CPU usage during imports exceeds 80%, the OCR queue cannot clear overnight, swap is constantly used, less than 20% disk space remains free, or interface requests have become noticeably slower. In this situation, add vCPU for OCR first, then RAM for the database and cache, and then expand NVMe storage.
Do not confuse high CPU load during a one-time migration with a permanent need for an expensive configuration. You can import 30,000 old files on a temporarily upgraded server, then reduce resources to the level needed for daily operation.
Frequently Asked Questions
Paperless-ngx resource answers
How much RAM does Paperless-ngx need? 4 GB RAM is enough for a personal archive of up to 1,000 documents. If Gotenberg, Apache Tika, and regular OCR processing are enabled, choose 8 GB. For 10,000–50,000 documents, multiple users, and 4+ background tasks, allocating 16 GB RAM is sensible to avoid constant swap usage.
How many vCPU does Paperless-ngx need for OCR? The minimum is 2 vCPU for occasional imports, but 4 vCPU is considerably more comfortable for daily processing. When uploading 1,000 or more pages per day, choose 6–8 vCPU. One OCR process can use almost an entire core, so the number of cores determines queue processing speed.
Does Paperless-ngx need an NVMe drive? A SATA SSD can be used for an archive of up to 1,000 documents, but NVMe is recommended for 10,000+ files. Paperless-ngx simultaneously reads originals, creates temporary PDFs, writes thumbnails, and updates PostgreSQL. The practical minimum is 80 GB NVMe, while a medium-sized archive more often needs 200 GB.
Can I install Paperless-ngx on a VPS with 2 GB RAM? Technically, a minimal installation without heavy processing can sometimes run on 2 GB RAM, but this is risky for production. PostgreSQL, Redis, the Paperless-ngx container, and OCR can cause swap or OOM with a single large PDF. For reliable operation, use at least 4 GB RAM and 2 vCPU.
Conclusion
Server selection recommendation
For most Paperless-ngx archives of up to 10,000 documents, choose a VPS with 4 vCPU, 8 GB RAM, and 200 GB NVMe. For bulk OCR, an archive of 50,000+ files, or daily uploads of thousands of pages, move to 8 vCPU, 16–32 GB RAM, and 1 TB+ NVMe with separate backups.
NVMe VPS hosting activated in 60 seconds: full root access, 20+ locations, and card or crypto payments.
Choose a plan
