Paperless-ngx is a good match for a mini PC because document management is usually an intermittent workload. The box waits quietly most of the day, then spends a short burst of CPU time converting a scan, running OCR, creating an archive copy, and updating the search index. That pattern is very different from a media server that can stay busy for hours.
The important question is not whether Paperless-ngx starts. Almost any current x86 mini PC can start it. The useful question is whether the machine can process your scan batches without making the rest of your homelab sluggish, and whether its storage plan still makes sense after several years of receipts, statements, manuals, and correspondence.
This guide covers a Docker deployment, what OCR actually costs, how to estimate storage growth, and where an Intel N100 class mini PC stops being a comfortable choice. For the broader hardware decision, see our mini PC home server guide. For storage planning, use the NAS capacity calculator before you choose a disk layout.
What Paperless-ngx Actually Does
Paperless-ngx is more than a folder with a web interface. A document enters the consume directory, the consumer detects it, and the application creates a searchable representation. Depending on the input, that can include converting an image or office file to PDF, running OCR, classifying the document, applying tags and correspondents, generating a thumbnail, and indexing text for search.
The Paperless-ngx documentation describes the application as a group of services rather than one standalone process. A normal deployment includes the web application, a task queue, Redis, and a database. The official Docker Compose deployment handles those relationships, while your job is to provide persistent storage, a stable host, and backups.
That architecture explains why a mini PC works well. The web interface and database are light for a personal archive. OCR is the bursty part. Classification and indexing add more work after the file has been accepted. If the mini PC also hosts a busy media server, a large build job, or several virtual machines, those bursts become visible to every other service.
Is an N100 Enough for Paperless-ngx?
An Intel N100 is enough for a small or medium personal archive when you scan in ordinary batches and let OCR work in the background. Intel lists the N100 as a four-core processor with a maximum frequency of 3.4GHz in its official product specifications. That is modest server hardware, but Paperless-ngx does not need a large CPU when new documents arrive a few at a time.
The boundary is workload concurrency. An N100 is a sensible fit for:
- A household archive with a few people adding documents
- A scanner that produces short batches rather than a continuous office feed
- OCR in one language or a small language set
- Paperless-ngx alongside light containers such as a dashboard, DNS service, or password vault
- A setup where a large import can finish in the background instead of immediately
Move up from the N100 class when you expect:
- Hundreds or thousands of documents to arrive in a single import
- Multi-page color scans at high resolution every day
- Several OCR languages with mixed layouts and difficult source material
- Paperless-ngx beside video transcoding, photo recognition, or several busy virtual machines
- A shared office archive where users expect imports to finish quickly during working hours
The next useful step is not necessarily a high-end mini PC. A four to eight core Ryzen or Core system with 16GB of memory gives OCR more scheduling room and leaves space for other containers. More cores reduce contention during an import, but they do not make a poor scan legible. A clean 300 dpi black-and-white scan is often a better improvement than buying a much faster box.
What OCR Costs in CPU Time
OCR is a CPU workload because the application has to inspect the pixels in a document and infer characters from them. Paperless-ngx relies on OCR software such as Tesseract through its document processing path. The Tesseract documentation makes the important point for homelab planning: recognition quality depends on the input image, language data, layout, and page segmentation.
There is no honest universal seconds-per-page number. A clean text document, a skewed receipt, a photograph of a form, and a page with a complex table do not cost the same to process. The scan resolution matters too. Moving from 300 dpi to 600 dpi increases the pixel count by four for the same physical page because both dimensions double. That does not guarantee four times the processing time, but it explains why oversized scans can create much larger CPU bursts and files.
Think about OCR in four stages:
- Decode and convert. The system reads the input and may convert it to a PDF or another supported form.
- Recognize text. Tesseract examines page images and creates a text layer. This is usually the most CPU-sensitive stage.
- Create derivatives. The application can create thumbnails and archive representations according to your settings.
- Index and classify. The database and search index are updated so titles, dates, tags, and full text can be found later.
On an N100, these stages are best treated as a queue. Importing a small group of documents is fine. Importing a decade of scans while the same host is transcoding video is when the hardware boundary becomes obvious. Set expectations around throughput rather than promising a time figure nobody can publish for every document type.
The practical tuning levers are simple. Keep scan resolution appropriate to the source, limit unnecessary languages, avoid importing duplicate files, and let the consumer process a batch with one task worker. Paperless-ngx documents environment settings for OCR languages, task workers, threads, and conversion limits in its configuration documentation. Start conservatively, then increase concurrency only after the host remains responsive during an import.
Storage Growth Is the Bigger Long-Term Decision
CPU gets attention because users can see an import in progress. Storage is the commitment that lasts. Paperless-ngx can retain the original file, create an archive representation, generate thumbnails, store OCR text and metadata, and maintain database and search-index data. The exact footprint depends on file type, scan quality, retention settings, and the version of the application.
Do not estimate the archive from the number of pages alone. Measure a representative sample from your scanner, then use this planning formula:
annual originals = documents per month × 12 × average original size
archive reserve = annual originals × years to retain
working reserve = archive reserve × 0.25
planned storage = archive reserve + working reserve + backup spaceThe 25 percent working reserve is a planning choice, not a Paperless-ngx requirement. It leaves room for temporary imports, database growth, exports, and unexpected large files. If your sample shows that archive copies and thumbnails add more, increase the reserve. If you keep a second copy on a NAS, count that copy separately rather than treating it as free protection.
Here is a deliberately simple example. A household scans 250 documents per month and the sample averages 1.5MB per original. The original stream is about 4.5GB per year. Five years of originals is about 22.5GB before derivatives, database data, exports, and backups. That archive is easy for an SSD, but a larger scanner output or a family with several times the intake can change the answer quickly.
Use the NAS capacity calculator when the archive will live beside media, photos, or backups. Keep the active database and search index on local SSD storage when possible. Put bulk originals on a reliable local disk or a well-supported network mount, and make sure Paperless-ngx can still access that mount after a reboot.
A Practical Mini PC Layout
For a new installation, use a supported Debian or Ubuntu host with Docker Engine and the Compose plugin. The Docker Compose documentation explains the model: a YAML file defines the services, while bind mounts or named volumes keep application data outside the disposable containers.
Create separate locations for the application data, media, export files, consume directory, and database. The exact paths can differ, but the separation makes backups and recovery easier:
sudo mkdir -p /srv/paperless/data
sudo mkdir -p /srv/paperless/media
sudo mkdir -p /srv/paperless/export
sudo mkdir -p /srv/paperless/consume
sudo mkdir -p /srv/paperless/postgres
sudo chown -R 1000:1000 /srv/paperlessDownload the current Compose example from the Paperless-ngx installation guide, place it in /srv/paperless, and change its persistent paths to match the directories above. Keep PostgreSQL data on the SSD unless the host is intentionally designed around a fast and reliable external storage path. Keep the consume directory separate from the media directory so an accidental copy or permissions mistake does not become a document-management problem.
Before the first import, set the OCR language to match the documents you actually scan. A large language set can increase resource use and can make recognition choices less predictable. Set one task worker and one thread per worker for an N100 that also hosts other services. The configuration page documents these variables and the tradeoff between concurrency and resource use.
Start the stack and inspect its service state:
cd /srv/paperless
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100 webserverOpen the web interface, create the first administrator, and import a small representative batch. Use a clear text PDF, a receipt, a multi-page document, and one difficult scan. Check that the original is present, text search finds a phrase from each document, and the tags and dates can be corrected in the interface. This is a verification of your deployment, not a performance benchmark.
Backup Before You Trust the Archive
Paperless-ngx is a database-backed document system. Copying only the visible media directory is not a complete backup plan. Preserve the original and archive files, the database, the export directory, and the configuration secrets needed to rebuild the stack. The Paperless-ngx backup guidance and your database documentation should be the source of the exact commands for your deployment.
Use an export or backup routine that produces files you can open outside the application. Keep at least one copy on a different device, and keep one copy disconnected or protected from ordinary host credentials. A second disk in the same mini PC helps with a failed drive but does not protect against deletion, ransomware, or a power event.
If the archive matters, add a UPS and put the mini PC, storage, and network equipment on the same shutdown plan. Our power cost calculator helps estimate the always-on electricity cost, while a UPS gives the host time to stop services cleanly during an outage. The calculator is for cost, not runtime or battery sizing.
Common Problems and Their Causes
The scanner produces files but Paperless-ngx does not import them. Check ownership and permissions on the consume directory first. Then inspect the webserver and consumer logs. A bind mount that exists on the host but is not mapped into the container is a common cause.
Search returns nothing from a scanned image. The file may contain no text layer, OCR may be disabled, or the configured language may not match the document. Reprocess one sample after correcting the setting. Do not assume that a PDF icon means the file is searchable.
The mini PC becomes unresponsive during imports. Reduce task workers and threads, scan at a sensible resolution, and pause other CPU-heavy services during the initial archive import. An N100 can be enough for ongoing household use while still being a poor choice for a large one-time migration.
The archive fills the SSD. Check the original files, archive files, thumbnails, database, exports, and Docker logs separately. Log retention and old exports can consume space without appearing as documents in the Paperless-ngx interface.
A network-mounted media path disappears after reboot. Fix the mount and its boot ordering before importing more files. Paperless-ngx cannot protect a document that the operating system cannot reliably see.
Who Should Use an N100 and Who Should Skip It
Choose an N100 class mini PC when the archive is personal or household-sized, scans arrive in small batches, and the box runs mostly light services. Give it an SSD, at least 8GB of memory as a practical planning floor, and a backup destination. It is a quiet and economical place to start because OCR bursts do not require a large workstation all day.
Choose a stronger four to eight core mini PC with 16GB or more when Paperless-ngx shares the host with photo recognition, media transcoding, a large container stack, or several virtual machines. Use the VM capacity estimator if you are deciding whether the same box should also become a virtualization host.
Skip the mini PC approach when you need a supported office appliance, strict enterprise retention controls, high-volume continuous scanning, or a storage system with redundant controllers. In those cases, a small server or managed document platform may be a better operational fit than adding more CPU to a consumer box.
Frequently Asked Questions
Is an Intel N100 enough for Paperless-ngx?
Yes, an Intel N100 is enough for a small Paperless-ngx archive when OCR runs in modest batches and the mini PC is not also handling heavy media or virtual machine workloads. It is a poor fit for constant high-volume scanning or many CPU-heavy services at the same time.
How much RAM does Paperless-ngx need on a mini PC?
Eight gigabytes is a sensible planning floor for Paperless-ngx with its database, cache, and one or two supporting services. Choose 16GB when the same mini PC will host several containers, a reverse proxy, or other always-on applications.
Does Paperless-ngx require a GPU for OCR?
No. Paperless-ngx uses OCR software on the CPU, so a GPU is not required for a normal document archive. A GPU does not solve the main bottlenecks either, which are scan quality, OCR language setup, CPU bursts, and storage growth.
How much storage does Paperless-ngx use?
Storage depends on the original scan size, file format, OCR output, thumbnails, archive copies, and retention policy. Keep the original documents, database, media directory, export directory, and backups in your plan instead of budgeting only for the visible PDFs.
Can Paperless-ngx run in Docker on a mini PC?
Yes. The Paperless-ngx documentation provides a Docker Compose deployment that uses persistent storage for the application data, documents, export files, and database. A mini PC running Debian or Ubuntu is a practical host when the storage and backup plan are sound.
Should Paperless-ngx run on an SSD or hard drive?
Use an SSD for the operating system, database, search index, and active application data. Large originals can live on a hard drive or NAS when the mount is reliable and backed up, but the database and index should not share a slow or unreliable path.
Sources and Scope
This guide is based on the Paperless-ngx documentation, its installation guidance, the Tesseract documentation, the Docker Compose documentation, and Intel’s N100 product specifications. Storage examples are arithmetic planning examples. No universal OCR throughput, power reading, or first-party benchmark is claimed here.