More pages and worker concurrency can keep CPU cores busy for long periods.
Scan-heavy offices and archives.Papermerge Hardware Requirements: RAM, CPU, OCR & Storage
Plan Papermerge hardware for RAM, CPU, OCR workers, PostgreSQL, Redis, search and document storage, with practical ZimaOS sizing recommendations.
Papermerge requirements at a glance
Papermerge is a document-management workload where OCR and indexing matter much more than the web UI alone.
- RAM minimum
- Current Papermerge 3.5 requirement: absolute minimum 1 GB RAM for running only the web app.
- CPU
- No current numerical CPU minimum is published for the full stack. OCR worker concurrency makes CPU a major processing variable.
- Database
- Current production-style Compose examples use PostgreSQL 16.1; SQLite is described as suitable for quick demos, not production.
- Queue/cache
- Redis is used by current worker-based Compose examples.
- Storage/search
- Original documents, OCR results, PostgreSQL and optional Solr indexes determine capacity; no universal current disk minimum is published.
- Best Zima starting point
- ZimaBoard 2 1664 is a safer compact OCR stack; ZimaCube 2 Pro is better when OCR concurrency, search and document storage grow.
From official requirements to the right setup
Size Papermerge from the complete OCR/indexing pipeline, not the 1 GB web-only floor.
-
Official requirements
Use 1 GB RAM only as the absolute web-app-only minimum. A useful OCR deployment adds one or more workers, Redis and usually PostgreSQL.
-
Confirm your needs
Estimate document/page ingestion and OCR concurrency. Current Compose examples allow multiple OCR workers, making CPU the main processing bottleneck.
-
Leave room to grow
For production-style deployments, use PostgreSQL instead of demo SQLite; add Solr only when search workload justifies it, and persist the shared media root.
-
Run it on ZimaOS
On ZimaOS, use Install Custom App with Papermerge’s current Compose architecture, persist PostgreSQL/media/search data, and tune OCR worker concurrency to available CPU/RAM.
Check every playback client
- Documents/pages
- OCR languages
- OCR concurrency
- PostgreSQL
- Redis
- Solr/search use
- Media storage
- Backup retention
Official minimum requirements
Papermerge 3.5 publishes a web-app-only memory floor and explicitly says hardware depends on deployment topology and OCR use.
The 1 GB figure is not a complete OCR-stack requirement. A production-style system should budget separately for OCR workers, PostgreSQL, Redis, media and optional search services.
| Requirement | Official minimum | What this supports |
|---|---|---|
| Web-app-only RAM minimum | 1 GB | Current absolute minimum for just the web app. |
| Full-stack RAM minimum | No universal numerical minimum published | Depends on workers, database, search and OCR. |
| CPU minimum | No current numerical minimum published | OCR materially increases CPU requirements. |
| Production database example | PostgreSQL 16.1 | Current 3.5 Compose documentation. |
| Worker broker/cache | Redis 7.2 in current examples | Used by OCR/I3 worker architecture. |
| Search example | Solr 9.7 | Optional current Compose example for full-text search. |
| Official app image | papermerge/papermerge:3.5.3 | Current 3.5 Docker documentation. |
When to upgrade your hardware
Papermerge should scale when OCR queues, search indexing or the document repository grows.
OCR queues remain backlogged
PostgreSQL and search services consume more memory
Original documents and backups outgrow storage
Larger metadata and Solr indexes increase RAM and SSD demands.
Large searchable repositories.The media repository can become the largest long-term capacity requirement.
High-retention document archives.Plan hardware growth with confidence
Scale Papermerge around OCR throughput, database/search memory and durable document storage.
Use SSD-backed PostgreSQL and search storage
Database and index latency affects browsing, search and worker pipelines.
Use NVMe/SSD with ZimaBoard 2 or ZimaCube 2.Use 16 GB for a practical all-in-one OCR stack
More RAM gives the web app, PostgreSQL, Redis and workers room beyond the 1 GB web-only floor.
ZimaBoard 2 1664.Use stronger CPU for higher OCR concurrency
OCR processing is CPU-sensitive and benefits from more cores than the N150’s four.
ZimaCube 2 Pro.Use multi-drive storage for large archives
Original documents and backups can justify a six-bay platform.
ZimaCube 2 Pro or Standard depending on CPU needs.Can it run on ZimaOS?
No public official ZimaOS one-click Papermerge App Store page was verified for this guide. Papermerge can be deployed through Install Custom App using its official Docker images and Compose examples.
Custom install Papermerge in ZimaOS
Use the current Papermerge Compose stack, persist the media root and PostgreSQL data, and add OCR/Redis/search services as required.
Custom install Papermerge in the ZimaOS app ↗Use the current Papermerge Docker image
Papermerge 3.5 docs use papermerge/papermerge:3.5.3 and show progressive deployments from web-only to OCR/search stacks.
Review Papermerge Docker setup ↗Build the full stack progressively
Current Compose docs show PostgreSQL, Redis, OCR workers and optional Solr/I3 workers as separate services.
Review Papermerge Compose examples ↗Choose Zima hardware for Papermerge
Papermerge can start small, but OCR and search quickly make CPU, RAM and storage more important than the web UI’s 1 GB minimum.
Is this a light document archive or an OCR-heavy searchable repository?
Light archive / modest OCR
Use 16 GB for comfortable room across the web app, PostgreSQL, Redis and workers.
- Best compact choiceZimaBoard 2 1664
OCR-heavy / larger searchable archive
Use stronger CPU and expandable SSD/multi-drive storage.
- Higher-processing headroomZimaCube 2 Pro
- Storage-first optionZimaCube 2 Standard
These are workload recommendations, not official pages-per-hour OCR guarantees.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 1664 | Personal and small-team Papermerge OCR deployments. | Papermerge, PostgreSQL, Redis and modest OCR worker concurrency. |
|
16 GB provides whole-stack headroom, but the 4-core N150 limits heavy OCR throughput. | Get Now |
| ZimaCube 2 Pro | OCR-heavy or larger Papermerge deployments. | More OCR concurrency, PostgreSQL, Redis, Solr/search and document storage. |
|
Closest Zima fit when CPU throughput and storage expansion both matter. | Get Now |
| ZimaCube 2 Standard | Large document archives with lighter OCR demand. | Papermerge plus multi-drive document retention and backups. |
|
Its 8 GB RAM and weaker CPU make it less suitable than Pro for heavy OCR/search. | Get Now |
What the Press Says
Highlights from trusted reviewers worldwide.
“ZimaCube 2: Not just another NAS, tested with 25TB storage, local AI agents, 4K transcoding, and real homelab workflows.”Read full review
“The ZimaBoard 2 is a compact x86 server board that can be turned into a mini NAS, home server, media box, or self-hosting hub.”Read full review
“ZimaCube 2: A modern, high-performance NAS with plenty of room to grow—built for users who want more than basic storage.”Read full review
“Coverage focused on ZimaCube 2's open hardware foundation, no monthly fee, and self-hosting flexibility.”Read full review
Loved by the Community
Stories and reviews from people who build with Zima every day.
★★★★★
Zima Blade Little yet Powerful
Maybe I am not digital natives but I live with PCs since 12 years old in 1984 when IBM PC clone come to my home. Many years have passed and many operating system I've tried. For me Zima blade and CasaOS was a quantum leap for home PC enthusiast and server lab machine to make me stay curious and relevant for this era.
★★★★★
Very good!!
I use ZimaCube Pro as 5th Proxmox cluster node. It runs several VMs and containers, including a VM with GPU passthrough to run a self-hosted LLM. A specific LXC container runs a Samba server for NAS capabilities using four of six RAID 6 SATA HDDs with ZFS.
★★★★★
Great innovation for mini server!
It is very useful and makes a powerful mini server for many purposes, including university and college students in engineering and electronics. Thank you so much for making this server.
★★★★★
Avaliação ZimaBoard 2
Construí um servidor de uso pessoal. O desempenho está muito bom e funciona perfeitamente onde quer que eu esteja. A surpresa é não dependermos de grandes estruturas para termos nosso próprio servidor de dados. Como iniciante, estou gostando bastante do ZimaOS, pois ele é simples e eficiente.
Frequently asked questions
These answers cover Papermerge RAM, CPU, OCR, PostgreSQL, Redis, search and ZimaOS deployment.
How much RAM does Papermerge need?
Papermerge 3.5 lists an absolute 1 GB minimum for running only the web app. A full OCR stack needs additional memory.
How many CPU cores does Papermerge need?
Current 3.5 docs do not publish a universal CPU minimum; OCR worker concurrency makes CPU important.
Which database should Papermerge use?
Current 3.5 Compose docs use PostgreSQL 16.1 for production-style deployments; SQLite is for quick demos rather than production.
Does Papermerge use Redis?
Yes. Current worker-based Compose examples use Redis 7.2.
Does Papermerge use Solr?
Solr is optional in current advanced Compose examples for full-text search and I3 indexing.
Does Papermerge need a GPU?
No dedicated GPU is required by the current Papermerge hardware requirements.
Can ZimaBoard 2 run Papermerge?
Yes. The 16 GB model is a practical compact choice for a modest OCR stack, though heavy OCR may be CPU-limited.
When should I choose ZimaCube 2 Pro?
When OCR queues, search services and document storage justify more CPU cores plus broader SSD/multi-drive capacity.
What sources informed this Papermerge hardware guide?
Current Papermerge 3.5 requirements, Docker and Compose documentation plus current Zima product pages.
