Self-hosting Noplag on your own hardware

Most plagiarism checkers have exactly one deployment model: their cloud. Your documents go to their servers, their retention policy applies, and your compliance team gets a sub-processor list to review. For a student essay that's usually fine. For a legal brief, an unpublished manuscript, or a grant application under embargo, it's a real problem — and "trust our privacy policy" is the only answer the industry offers.

Noplag's answer is different: the engine is open source, and self-hosting is a supported, documented deployment mode — not a leaked internal build. Run it yourself and no document, fingerprint, or report ever leaves your network.

Who actually needs this

Being honest about this cuts both ways — most people don't need to self-host. The cloud service exists because operating a large corpus is genuinely expensive. Self-hosting earns its keep when:

• The documents are privileged. Law firms checking filings, journals screening unpublished submissions, companies checking internal reports. If a document leaking would be a serious incident, the safest upload is the one that never happens.
• Policy forbids third-party processors. Some institutions simply cannot send student or patient-adjacent text to an external service, whatever the DPA says.
• You're checking against your own archive. A publisher's back catalog or a firm's document store makes a better comparison corpus than the public web for many jobs — and it's a corpus we could never index for you.

What a minimal deployment looks like

The engine is deliberately boring to operate: one Python process (FastAPI, with background work in the same event loop) and one Postgres 16 database. No queue, no Redis, no GPU, no worker fleet.

git clone https://github.com/NoplagLabs/noplag-engine
cd noplag-engine
docker compose up -d

First start migrates the schema, loads a small bundled sample corpus so you can try a check immediately, and serves the API with a demo page on port 8000. From there, real usage is two steps: put your own documents in the corpus, and put the service behind your own authentication — the API is an unauthenticated backend service by design, so a reverse proxy or private network is not optional. The self-hosting guide covers both, with copy-paste deployment recipes for nginx, oauth2-proxy, Caddy, and systemd.

The honest trade-offs

What you give up compared to the cloud service:

The corpus row is the one that matters. A plagiarism checker is only as good as what it compares against, and an empty self-hosted instance detects nothing. That's not a defect — it's the deal. Internal-corpus use cases (the publisher's archive, the firm's precedent bank) get better coverage than our cloud could give them; open-web coverage stays a cloud strength. Corpus loading is a documented, scriptable pipeline — see corpus patterns for the common setups, including Wikipedia at full scale.

Sizing is mostly a disk question: fingerprints and snippets for about a million documents fit comfortably on a small VM, and the guide covers the Postgres settings that matter as you grow past that.

The same engine, verifiably

A self-hosted instance isn't a lesser fork. It's the same detection code that runs noplag.app, producing the same report format down to character offsets, benchmarked by the same published evaluation. When we improve detection, you get it with a git pull — the upgrade guide is short because upgrades are.

That's the point of the open-core model: the trust-critical part runs wherever you need it to, and you can read every line of it first.