Paperless-ngx vs Nextcloud

These two are not competitors, and any page that ranks them against each other on a feature grid has already misunderstood the question. Nextcloud is a file sync and groupware platform: files, calendar, contacts, shares, office documents, an app store. Paperless-ngx is a document management system: it OCRs, classifies and indexes finished documents and gives you no way to write one.

The question people are actually typing is "do I still need Paperless if I already run Nextcloud", and the answer for anyone who owns a scanner is yes.

What Nextcloud does with a scan, precisely#

You scan a bank statement. Your scanner produces a PDF that is, internally, a photograph of a page. You put it in Nextcloud. Nextcloud stores it, versions it, syncs it to your laptop and lets you share a link to it.

What Nextcloud does not do is read it. There is no text layer, so searching for the account number returns nothing. Nextcloud's search finds it by filename, which means the entire filing system is whatever naming discipline you personally sustain across ten years, and nobody sustains that.

Nextcloud's full text search is an app-store construction rather than a core feature: you install a provider app to extract content plus a platform app that talks to a search backend such as Elasticsearch, which is another service to run, tune and back up. And it indexes text that already exists in a file. It does not manufacture text from an image.

Paperless-ngx runs OCRmyPDF, Tesseract and Ghostscript over every incoming file, embeds a text layer, and stores a searchable PDF/A archive copy next to the original. That is the entire reason it exists.

What the spec table means here#

Compare these rows and ignore the rest. Container count is 5 against 4 and both are underestimates of the attention involved. Ops load is 3 against 4, and the extra point on Nextcloud is nothing to do with size, it is the release calendar. Idle RAM understates Paperless badly: it sits at roughly 450 MB doing nothing and then saturates every core you gave it the moment a document arrives.

The consume folder is the actual product#

Paperless's workflow is one directory. Anything that lands in ./consume gets picked up, OCRed, classified against your existing correspondents and document types, filed, and then deleted from the folder. Your scanner writes there over SMB. Your phone's scanning app syncs there. An IMAP mailbox rule drops invoices there. You never name a file.

Two configuration facts decide whether this works on day one:

environment:
  USERMAP_UID: 1000                        # match whoever writes into ./consume
  USERMAP_GID: 1000
  PAPERLESS_CONSUMER_POLLING_INTERVAL: 30  # required on NFS or SMB
  PAPERLESS_OCR_LANGUAGE: eng
  PAPERLESS_TASK_WORKERS: 1                # workers x threads must not exceed cores
  PAPERLESS_THREADS_PER_WORKER: 1

The polling interval is the one that wastes people's weekends. Paperless watches the consume directory with inotify, and network filesystems do not deliver inotify events. Files land, nothing happens, nothing is logged. It presents exactly like a broken scanner.

The worker arithmetic is the other one. PAPERLESS_TASK_WORKERS multiplied by PAPERLESS_THREADS_PER_WORKER must not exceed your core count or consumption gets slower rather than faster, and OCR chews several hundred megabytes per worker thread. On a 2 GB single-board computer that means 1 and 1, and a bulk import runs overnight. There is no GPU acceleration to reach for.

The uncomfortable part of each one#

Paperless: an export only restores into the same version it came from. The docs are explicit that a document_exporter archive cannot be imported into a different Paperless version, because the manifest mirrors the database exactly and migrations change the layout. So store the image tag alongside every export. Restoring a year-old backup means starting that exact tag first, importing, then upgrading forward through the normal migration path. Version 3.0 in July 2026 also swapped the Whoosh search index for tantivy, removed document and thumbnail encryption outright, deleted the positional arguments passed to pre and post consume scripts, and dropped API versions below 9. Custom hooks reading $1 and $2 stopped working silently.

Nextcloud: you cannot skip a major version, and there are three majors a year. Version 32 landed 27 September 2025, 33 on 18 February 2026, 34 on 9 June 2026, each supported for exactly twelve months. Drift for eighteen months and you are running four sequential upgrades, each with its own PHP window (32 wants PHP 8.1 to 8.4, 34 wants 8.2 to 8.5) and each gated on every installed app being marked compatible. This is why All-in-One exists: it pins the whole stack including PHP and moves it as a unit. An update strategy that does not lose data covers making that a calendar item rather than a crisis.

Backups, where the two differ most#

Paperless has exactly one safe backup and it is not a file copy:

docker compose exec -T webserver document_exporter ../export

That writes originals, archive PDFs, thumbnails and a manifest.json carrying every tag, correspondent, custom field and permission. A raw copy of the media volume gets you 0000123.pdf and no filing system at all. The exporter updates in place, so rsync the export directory for incremental backups; -d prunes deleted documents, and -na -nt skips archive files and thumbnails, which you can regenerate later with document_archiver and document_thumbnails.

Nextcloud needs three things taken at the same moment: config/, the data directory, and the database, with occ maintenance:mode --on first so the dump and the files agree about which uploads exist. Inside the data directory, appdata_*/preview is regenerable and is often the largest single tree, so excluding it is the one safe saving. Push both sets offsite with restic and rehearse the restore using Backups that actually restore; the database consistency details are in Backing up a running database.

The case for running both#

This is what most people who take paperwork seriously end up with, and it is a clean division of labor:

• Nextcloud owns the working files: things you are still editing, sharing and syncing to a phone. Calendar and contacts come along for free.
• Paperless owns the archive: things that are finished, need to be findable in seven years, and will never be edited again. Statements, invoices, warranties, tax paperwork, medical letters.

Wire them together with a dedicated inbox folder rather than a shared one. Point Paperless's consume directory at a path Nextcloud also serves, add PAPERLESS_CONSUMER_POLLING_INTERVAL because it will be a network mount, and remember that Paperless deletes files from the consume folder after ingesting them, which looks like data loss to whoever is watching that folder in the Nextcloud client. A folder named Scans/Inbox that nobody treats as storage avoids the argument.

If you only want file sync and none of the groupware, Nextcloud is the wrong half of this pair: see Nextcloud vs Seafile and Syncthing vs Nextcloud before you commit to three upgrade windows a year. If photos are the real driver, Immich vs Nextcloud for photos is the relevant page.

The verdict, by situation#

What to do next#

If you are adding Paperless to an existing Nextcloud, do it in this order: create the dedicated inbox folder, set PAPERLESS_CONSUMER_POLLING_INTERVAL, feed it ten documents by hand and check the OCR quality before you point a scanner at a decade of paper. Pin an exact image tag and record it next to your first document_exporter run. If you are starting from nothing, size both against your hardware in Stack planner, and browse Documents or Photos and files for the lighter options if five containers is more than you want to own.