Self-hosting MinerU for enterprise RAG: security, privacy, provenance, and license controls

Self-hosting MinerU keeps document processing under your operational control, but it does not make the ingestion boundary safe by default. PDFs and Office files are untrusted inputs, parser workers consume substantial resources, model downloads create outbound dependencies, and the resulting Markdown can enter a retrieval system that users treat as evidence. Security, provenance, and licensing therefore belong in the deployment design.

MinerU supports PDF, images, DOCX, PPTX, and XLSX inputs and exposes CLI, FastAPI, Gradio, and routing interfaces. Its pipeline, VLM, and hybrid paths also have different resource and network profiles. The right deployment is not “put the API behind SSO.” It is an isolated conversion tier with explicit admission and release controls.

Treat every upload as hostile

Validate the real file type rather than trusting the extension. Set limits for file size, page count, archive expansion, image dimensions, parse time, concurrent work, temporary disk, memory, and accelerator use. Password-protected, malformed, or policy-disallowed files need deterministic rejection states.

Run workers without privileged mounts, business-network access, or reusable cloud credentials. Use read-only base images and per-job writable scratch space. Block arbitrary outbound traffic after models and dependencies have been mirrored to an approved registry. A parser compromise should not become a route to internal systems.

Separate intake, parsing, review, and publication

intake → malware/policy checks → immutable object store
       → isolated parser queue → quality quarantine
       → human or automated approval → retrieval index

The parser API should never write directly to the production index. Store the source hash, tenant and access policy, parser release, backend, model/configuration identity, output manifest, timings, and reviewer decision. Every chunk must inherit the source access policy and resolve back to a document and page.

Pipeline and VLM require different governance

Pipeline can be the default for predictable digital documents. VLM or hybrid processing may be justified for scans and difficult layouts, but routing must be policy-driven. If a backend calls a remote OpenAI-compatible endpoint, the document may leave the trust boundary; that route requires a separate data-processing decision, endpoint allowlist, encryption policy, and logging rule.

Record why a page was escalated and whether the chosen backend was local or remote. Never let a silent fallback send confidential documents to an external service.

Resource exhaustion is a security event

A technically valid document can still be abusive. Large raster pages, repeated embedded objects, huge spreadsheets, or long-running visual inference can starve a shared service. Admission control should reserve resources by tenant and backend, cap queue depth, cancel expired jobs, and expose circuit breakers. Retries must be bounded and classified; deterministic failures should not loop.

Keep temporary artifacts short-lived and encrypted where required. Logs should contain job identifiers and structural metrics, not extracted document text. Support teams can inspect approved samples through audited tooling instead of copying sensitive output into chat or tickets.

Pin releases and test the output contract

Pin the package, model artifacts, container digest, and configuration. The 3.4.4 release changed font analysis and duplicate-character detection, a reminder that parser upgrades can alter downstream chunks even when the API stays stable.

Maintain a non-sensitive regression corpus with scans, multi-column pages, tables, formulas, and problematic fonts. Before promotion, compare reading order, heading hierarchy, table cells, formula markers, duplicates, empty pages, output file inventory, and citation coordinates. Sign the approved image and roll out by canary. Preserve the previous parser version until accepted artifacts have been sampled.

Provenance is part of answer security

RAG answers should cite accepted artifacts, not mutable paths. Store content hashes for the original and generated files. Mark parser-generated structure as derived data, keep the raw source immutable, and make reprocessing create a new version. This prevents an upgrade from rewriting historical evidence without an audit trail.

Quality checks also defend against prompt-like content embedded in documents. Parsing should preserve text as data; downstream agents must not treat extracted instructions as trusted control messages. Keep ingestion, retrieval, and agent execution permissions separate.

The license has operational obligations

The project uses the MinerU Open Source License, based on Apache 2.0 with additional terms. It permits commercial use without a separate license without a separate license while consolidated MAU does not exceed 100 million and consolidated monthly revenue for the preceding calendar month does not exceed USD 20 million; it requires a separate commercial license above either threshold and prominent MinerU attribution when providing MinerU-based online services to third parties. The GitHub API therefore reports the license as “Other” rather than plain Apache-2.0.

Track the license file alongside the pinned release, document the threshold owner, and make attribution a tested product requirement. Legal review should also cover affiliates and the exact service model rather than relying on a README summary.

Production acceptance criteria

• Untrusted files are processed in isolated, resource-limited workers.
• Remote model routes are explicit, allowlisted, and disabled for restricted data.
• Source, parser, model, configuration, output, and approval versions are traceable.
• Parser upgrades pass a fixed regression corpus and canary rollout.
• Workers cannot publish directly to the retrieval index.
• License thresholds and online-service attribution have named owners.

MinerU can be a strong self-hosted parsing layer. The safe version is not merely local; it is isolated, observable, versioned, reviewable, and licensed according to the service actually being offered.