NextSearch

Full-text search across the contents of your Nextcloud folders — without touching the files

Nextcloud stores and shares files, but it can't find anything inside them. If you need to know which PDF from 2019 holds a particular invoice number, you search by hand — folder by folder, and across several instances it turns into real work. Nextcloud's own full-text search exists, but it wants an Elasticsearch cluster next to it that someone has to run.

That's where NextSearch comes in. It indexes the folders you point it at — subfolders included, across as many instances as you like — and makes their contents searchable. Access to Nextcloud is strictly read-only: NextSearch cannot change, move or delete your files. That's not a promise in the fine print; it's enforced in the code.

The problem: stored isn't found

An archive grows over years. Contracts, invoices, minutes, scanned mail — all of it sits neatly in Nextcloud, shared and synced. Only the one sentence you remember is somewhere inside one of those documents, and Nextcloud searches file names only. For a single folder you can still do it by hand. For a grown collection across several instances, you can't.

The obvious answer would be Nextcloud's official Full Text Search app. It can do this too — but it needs a platform alongside it, in practice an Elasticsearch cluster that wants maintaining, updating and feeding with memory. For many setups the operating cost is out of proportion to the goal: just find the content.

NextSearch is the smaller answer to the same question. One stack, one command, and search is up.

How it works

NextSearch is a handful of building blocks wired together by Docker Compose: a Nuxt frontend, a Laravel backend on FrankenPHP, Meilisearch as the search index, Apache Tika for text extraction including OCR, plus Postgres, Redis and S3-compatible object storage.

A document's path into the index runs in four steps:

1. Crawl. A scheduler checks every minute which folder is due, and a worker reads it level by level over WebDAV. For each file it compares fileid and ETag against the stored state — unchanged means skipped, only new and changed files go on. A second run over a large folder therefore costs almost nothing.
2. Extract. The changed file goes to Tika. For PDFs without a text layer, OCR kicks in: a first pass without it, and if that yields too little text, a second pass with recognition. Only if that produces more is it kept — and the match later flagged as an OCR result, because recognition errors come with the territory.
3. Render a preview. A small preview image of the first page is produced, so a match is recognisable in the result list.
4. Index. Full text and metadata land in Meilisearch, the full text additionally as a blob in object storage.

git clone https://github.com/McGo/NextSearch.git
cd NextSearch
make init          # creates .env and generates the APP_KEY
$EDITOR .env       # set ADMIN_EMAIL and ADMIN_PASSWORD
make up

Then open the interface at http://localhost:3000, add a Nextcloud instance, pick a folder. The scheduler handles the rest.

What sets NextSearch apart from Nextcloud's own search

Three things the official Full Text Search app doesn't offer in this form:

One search across several Nextclouds. Instance is just another filter facet. You register as many instances as you like and search all of them at once. If you run a separate cloud per client, you no longer search five times — you search once.

Whoever searches needs no Nextcloud account. The cloud credentials stay on the server. NextSearch returns matches and streams the original document straight to the browser — without the person searching having any access to the source cloud. A whole team searches without you creating seats on Nextcloud.

Nothing to back up but a small database. Nextcloud stays the single source of truth. Everything NextSearch derives from it — search index, preview images, text blobs — can be rebuilt at any time. All that's left to back up is a small Postgres holding instances, folders, users and grants; one pg_dump, and the rest rebuilds itself on the next run. Moving to a different server is correspondingly frugal.

Two small things on the side that smooth the day-to-day: saved searches store a query, its filters and sort order under a name — you don't reassemble the monthly invoice search from scratch each time. And when the collection grows, WORKER_REPLICAS=6 scales exactly the bottleneck that matters: text extraction. The delta crawl keeps everything else cheap.

The alternatives — and why none solves the same thing

Nextcloud Full Text Search

The official app can do full-text search over one user's files, permission-accurate. The price is a platform next to it — usually Elasticsearch, version 8 from Nextcloud 26 on — that wants operating, updating and feeding with memory. It searches within one instance and respects its shares exactly. If that's precisely what you need and you can carry the cluster, that's the right place. NextSearch trades the permission-accurate mirror for a smaller, comprehensible model — and the cluster for Meilisearch in a container.

Paperless-ngx

Paperless-ngx is an excellent document management system — but a different tool. Documents come in through a consume directory, get processed and stored in Paperless's own collection. Which means: you move your files into Paperless. Wanting to make an existing folder searchable without relocating it is a frequently requested, deliberately declined feature in Paperless — the system is built around its own collection. NextSearch instead lays itself read-only over the folders already in Nextcloud, and moves nothing. Shut NextSearch down and discard the volumes, and it leaves no trace in Nextcloud. If you want a DMS with tagging, take Paperless. If you want to make your existing Nextcloud collection searchable without touching it, take NextSearch.

Recoll, DocFetcher and the like

Desktop full-text searches are powerful, but single-seat. They index local directories for one user on one machine. For a server-side index across several Nextcloud instances, shared by a team, they aren't built.

The core: trust as a design decision

A tool that reads foreign documents and makes them searchable across a team stands or falls on trust. NextSearch answers that in two places — and both are built that way on purpose.

Access to Nextcloud is enforced read-only. The only code that talks to an instance permits exactly four HTTP methods — GET, HEAD, PROPFIND, OPTIONS — and throws on anything else before a socket is even opened. The same check also sits in the HTTP client as middleware, so that future code can't bypass the path either. A test walks every write verb and proves none gets through. NextSearch creates no file in Nextcloud, changes none, moves none, deletes none.

Permissions are deliberately not mirrored. Nextcloud's permissions come from groups, shares, share links, group folders, external storage and encryption. Mirroring them reliably would mean replicating all of that and keeping it in sync — and a mistake in that mirror would be a silent leak. Instead there are two roles and a small model: administrators manage instances, folders and accounts; users see only the folders explicitly assigned to them. Whoever gets none assigned has an empty search. A model you can look at and understand is the more honest choice here than a mirror you'd have to trust blindly.

In practice that means: create a dedicated Nextcloud account just for indexing, with an app password rather than the account password, and share exactly the folders that should be searchable. Then the boundary is already drawn on the Nextcloud side. The app password sits in NextSearch's database encrypted with the APP_KEY, and can be revoked individually in Nextcloud at any time.

What else is in there

Beyond the big lines, a few things that matter day-to-day: the result list filters by facets — instance, folder, file type, year, size, author, language, whether OCR was involved, whether a preview exists. Values of the same facet are ORed, different facets ANDed. The stack runs bundled on one host, but can be pulled outward piece by piece: Postgres, Redis, Meilisearch and object storage can all point at external services, say an RDS instance or real S3 with its own prefix. And the format coverage reaches beyond the usual — PDF, Office, OpenDocument, but also emails as .eml/.msg with subject, sender, recipient and body, spreadsheets row by row, PowerPoint including notes, EPUB. Whatever else Tika can handle is enabled through a list in the .env.

Conclusion

NextSearch does one thing: make the contents of existing Nextcloud folders searchable, self-hosted, without touching the files and without a cluster alongside. It mirrors no permissions, imports nothing, and read-only can do no more than read. It's deliberately narrow — and manageable to run for exactly that reason.

If you have a grown document collection and search it by hand today, one docker compose up gives you a searchable index. It doesn't set out to be more.

Call to action

NextSearch is open source and available on GitHub: https://github.com/McGo/NextSearch

You can try it without a Nextcloud of your own: make demo spins up a throwaway instance, make demo-seed drops sample files into it — including a text-less scanned PDF you can use to verify OCR straight away.

If you want to set NextSearch up for a team or a whole organisation — with your own S3, behind a reverse proxy, connected to several instances — feel free to get in touch. As a backend & solution architect I know the places where self-hosted document search stumbles between "runs locally" and "runs in production".