Choosing self-hosted document management
A self-hosted document management system keeps the application and its data in infrastructure you control. It can bring scans, downloads, statements, warranties, tax records, and other long-lived files into one searchable library without requiring a vendor-hosted account.
The right tool is not the one with the longest feature list. It is the one whose intake, access, export, backup, and failure behavior you can verify on the deployment you will actually operate.
Start with the retrieval problem
Write down three questions your household regularly asks, such as “Where is the current insurance policy?”, “Which appliance warranty is still active?”, or “Can I find last year's property notice?” Use representative files to test those questions end to end.
A useful evaluation includes:
- browser upload and any capture source you truly need;
- correction of titles, dates, senders, kinds, and tags;
- search using words a second person would know;
- restrictions for exceptional private documents;
- download of preserved originals plus a portable export with understandable metadata; and
- a restore into a new, isolated destination.
Evaluate ownership, not only hosting
“Self-hosted” describes where software runs, but not necessarily how portable or private it is. Check each layer:
| Question | Evidence to look for |
|---|---|
| Where are original bytes stored? | Documented local or remote backend and a way to verify objects |
| What owns searchable metadata? | A supported database with a coherent backup procedure |
| Can the archive leave? | Exported originals and enough context to understand them elsewhere |
| What calls external services? | Explicit, opt-in connectors and telemetry boundaries |
| Who can see an exceptional record? | Testable per-person or per-group access, including denied paths |
| What happens after interruption? | Durable admission, visible state, retries, and idempotent operations |
| How are upgrades reversed? | Versioned configuration, release notes, backups, and rollback steps |
Where Jiandu is distinctive
Jiandu is designed for a household or another small, trusted group rather than a records department. It preserves originals separately from filing decisions, starts on loopback with remote telemetry off, supports several operator-chosen storage and sign-in backends, and keeps accepted filing rules inspectable and reversible.
The supported deployment remains one Jiandu process per installation. SQLite is the default database; PostgreSQL 17.x and 18.x are the supported external families. Blobs can use local disk, S3-compatible storage, or WebDAV. The library is shared by default, with explicit grants for exceptional documents.
When Jiandu is not the right choice
Choose something else, or keep evaluating, if you need any of the following today:
- a mature packaged release with a published support lifecycle;
- a current open-source license—the repository has not selected one yet;
- a drop-in Paperless-ngx replacement;
- guaranteed OCR accuracy or a remote OCR provider surface;
- SAML or managed identity provisioning;
- multiple active application replicas; or
- a compliance certification or blanket production-readiness claim.
Being explicit about these boundaries is part of trustworthy self-hosting documentation. The support matrix is the short, current contract.
Compare the operating models
No single self-hosted tool is the default answer for every archive. Evaluate the current product and its documentation on your own files:
| Option | Prefer it when | Reconsider when |
|---|---|---|
| Paperless-ngx | You want a mature, scan- and OCR-centered paper archive with broad capture, filing, and workflow features | You specifically want Jiandu's household trust model or are testing a reviewed Paperless export migration into Jiandu |
| Nextcloud Files | File synchronization, folders, desktop/mobile access, and sharing across a broader collaboration suite are the main job | You want a purpose-built filing model, document lifecycle, and recovery contract rather than a general file workspace |
| Mayan EDMS | An organization needs formal document types, fine-grained operational permissions, versioning, workflows, events, and enterprise-scale administration | A smaller household archive and simpler operating model matter more than breadth |
| Plain files and folders | Names, folders, operating-system search, and an ordinary backup already solve retrieval reliably | Multiple people need consistent metadata, content search, exceptional restrictions, capture, or an auditable application workflow |
| Jiandu | You are prepared to evaluate evolving source-built software and value preserved originals, explicit household access, operator-selected storage, and rehearsable recovery | You need a packaged, licensed, mature release or any exclusion in the evidence matrix |
This table is a decision aid, not a benchmark score. Product capabilities change; follow each project's current documentation and test the failure paths you will actually own.
A practical trial
- Follow the quickstart.
- Add a born-digital PDF and an image-only scan.
- Ask another person to retrieve them without using the original filenames.
- Restrict a sample document and test both an allowed and denied account.
- Download the preserved originals, then create and inspect a portable export.
- Back up and restore into an empty destination.
- Review every manual workaround the trial required.
If those steps are understandable and repeatable, you have better evidence than a feature checklist can provide. Continue with the household rollout guide; otherwise preserve your source archive and record the missing capability before choosing a tool.