Paperless Office Stack

Last reviewed Oct 11, 2026 · 650 words

Paperless-ngx is the archive and Stirling PDF is the workbench, and the setup goes wrong when people blur the two. Fix a document in Stirling first, then ingest the finished file into Paperless once; never edit a PDF after Paperless has filed it. Together they need about 2,560 MB of RAM by the directory's estimates: 2,048 MB for Paperless-ngx, which spends most of it on OCR, and 512 MB for Stirling PDF.

What talks to what

There is no API link between them. The handoff is a file.

Paperless-ngx watches a consume folder. Anything dropped there (from a network scanner's scan-to-folder, a mail rule, or by hand) gets OCR'd, matched against your tags, correspondents and document types, and filed into its media store with full-text search. It also accepts uploads through the web UI and its REST API. Behind it sits a Redis broker that queues the processing work, which is why the catalogue's compose file starts Redis before Paperless.

Stirling PDF is a browser toolbox: merge, split, rotate, compress, convert to and from PDF, and run OCR, all locally. It holds nothing permanently. You use it on the way in to fix scans that would confuse Paperless (a double-sided batch that needs splitting into separate letters, a sideways page, a phone photo that needs converting), and occasionally on the way out to combine exported documents into one file for someone else.

Deploy in this order

Paperless first, because it is the one that matters. Start from the catalogue's compose layout: a Redis broker, then Paperless with data, media, export and consume volumes. Set PAPERLESS_URL to the public address and PAPERLESS_OCR_LANGUAGE for every language your mail arrives in; a missing language produces OCR text that search cannot find. SQLite is fine to start and you can move to Postgres later. Stirling PDF second, on the LAN; it processes whatever anyone uploads, so it has no business on the open internet without authentication in front.

Why does editing a filed document cause trouble?

Because Paperless treats its stored file as the original, and a changed copy uploaded again is a new document. If you pull a filed PDF out, split or compress it in Stirling and drop it back in the consume folder, you get duplicates with separate tags, notes and history, and the search index now returns both. Do the cleanup before ingestion. If a filed document really needs fixing, replace it deliberately and delete the old one, rather than letting both live in the archive.

The backup trap

The catalogue is blunt about this: back up with Paperless's built-in document_exporter, not by copying the media folder. The media folder holds the files, but your tags, correspondents, notes and custom fields live in the database, and a folder copy without a matching database is a pile of oddly named PDFs. The exporter writes everything into the export volume in a form the importer can restore on a fresh install. Schedule it nightly, back up that folder off-site, and ping a dead-man switch when it finishes. Stirling PDF has nothing to back up beyond its own settings.

What I'd do

Deploy Paperless-ngx with the exporter scheduled from day one, set your OCR languages before the first scan, and run Stirling PDF beside it for pre-ingestion cleanup. Spend the first week building matching rules on a small batch before feeding in the shoebox. The Paperless-ngx guide covers those rules and scanner setup, and the document management category lists the alternatives if Paperless's 2 GB floor is too much for your hardware.