# MrDoc: a self-hosted Django wiki for personal notes and small teams

> MrDoc is a Python and Django document system you deploy yourself, aimed at individuals and small teams. The install path is short, but the project's own documentation is the real manual, and the README leaves deployment and upgrade details to linked guides.

**zmister2016/MrDoc** — mrdoc,online document system developed based on python. It is suitable for individuals and small teams to manage documents, wiki, knowledge and notes. 觅思文档，适合于个人和中小型团队的在线文档、AI知识库系统。

- Repository: https://github.com/zmister2016/MrDoc
- Website: https://mrdoc.io/
- Stars: 3,238 · Forks: 586
- Language: JavaScript
- License: GPL-3.0
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/zmister2016-mrdoc

## What MrDoc replaces, and for whom

MrDoc is an online document system built on Python, described in its README as suitable for individuals and small teams managing documents, knowledge and notes. The unit of organisation is the project: documents, document templates, images and attachments all hang off a project, and a project has one creator plus collaborators with selectable permissions. That is a smaller scope than a corporate wiki with department hierarchies, and the README states the target plainly rather than claiming enterprise scale.

The permission model is where the intended audience shows. A project can be public, private, visible to specified users, or visible to anyone holding an access code. Those four modes cover a personal notebook, a shared team space and a link-shared draft. They do not cover per-paragraph access control or approval workflows. If your requirement is that a document must be reviewed and signed off before publication, the README describes no such mechanism.

The AI knowledge features are listed in the README as AI chat and AI-assisted document writing, and requirements.txt carries openai>=1.40 plus numpy and markdown-it-py under a comment reading AI knowledge base. The repository has an app_ai directory at the top level, so the feature is a first-class part of the code layout rather than a plugin. The README does not document which model providers beyond the OpenAI-compatible client are supported, and it does not describe how documents are chunked or indexed for retrieval.

## How the Django apps and the Markdown editor fit together

The repository layout is the clearest description of the architecture. manage.py sits at the root, and alongside it are app_admin, app_ai, app_api and app_doc, plus config, locale, media, static and template directories. That is a conventional Django project split by function: administration and site settings, AI features, the API surface, and documents themselves. The README states that the account-based API uses an account token to fetch a corpus, upload images and create documents, and app_api is where that lives.

Writing happens in a Markdown editor built on editormd and vditor, which the README says the project optimised and extended. The README lists image management and upload, table pasting, mind mapping, flow chart and sequence diagram drawing as editor capabilities. Reading is a two-column page with a three-level directory, adjustable font size and type, and export to PDF or ePub. Document history is stored: the README says you can view a historical version, compare it against the current one, and restore it.

Search is not mentioned in the README feature list, but requirements.txt includes whoosh, django-haystack and jieba. Those three together are the standard Django stack for a pure-Python full-text index with Chinese word segmentation. The presence of jieba is a signal that Chinese-language search was a design consideration, not an afterthought. The README itself does not document how to configure or rebuild that index, which is a gap you will notice the first time content changes and search results lag behind.

## Installing MrDoc from requirements.txt and running it

The README gives a simple installation tutorial for running from source. The first step is installing the Python dependencies, and Python 3.9 or later is shown in the project badge. Run this from the project path:

```bash
pip install -r requirements.txt
```

The README says to configure the database information before initialising. requirements.txt lists mysqlclient, and the Dockerfile installs mariadb-dev and postgresql-dev in its build stage, so both MySQL-compatible and PostgreSQL backends are plausible from the dependency set; the README does not spell out the settings keys to change. After configuring, generate and apply migrations:

```bash
python manage.py makemigrations
python manage.py migrate
```

When the migration completes, the README states the database is initialised. Next create the administrator account, and follow the prompts for username, email and password:

```bash
python manage.py createsuperuser
```

For a test run, the README points at the Django development server:

```bash
python manage.py runserver
```

That server is described in the README as the test environment option. For a real deployment, the README directs you to the deployment guide at mrdoc.io rather than giving production server commands. The Docker path is a single shell script from a separate repository:

```bash
git clone https://gitee.com/zmister/mrdoc-install.git && cd mrdoc-install && chmod +x docker-install.sh && ./docker-install.sh
```

The README says updates are run with docker-update.sh. The docker-compose.yml in this repository maps port 10086 and pins the image tag zmister/mrdoc:v9.5, while the README badges show MrDoc v1.1.0 and MrDocPro v1.6.8. Those version strings do not agree, and the README does not explain the relationship between the open source edition and the professional edition beyond linking a separate demo.

## Where MrDoc is the wrong tool

The README's own framing is the first limit: individuals and small teams. Nothing in the feature list describes multi-tenant isolation, audit logging, or single sign-on. If your organisation requires that every document read be attributable to a named account in an external identity provider, the README documents no integration for that.

The deployment story has a sharper edge. The Dockerfile is a two-stage Alpine build that installs Chromium, chromium-chromedriver and LibreOffice at runtime, which the README does not discuss. Those packages exist because something in the stack drives a headless browser and converts office documents, but the README does not say which feature uses them. The practical consequence is image size and attack surface: a document wiki that ships a full office suite and a browser is not a minimal container, and you should know that before you put it on a small VPS.

Maintenance signal is mixed and worth reading carefully. The last push to the default branch was on 2026-09-20, four days before this writing, and the repository is not archived. The most recent tagged release listed is v0.9.9 from 2026-01-04, with v0.9.8 in 2025-12-01 and v0.9.7 in 2025-09-30. Commits are landing more often than releases are cut, so if you track tags you are running code that is months behind the branch. The README does not document a rollback procedure, and neither docker-update.sh nor the compose file is explained beyond a one-line instruction.

## BookStack and Wiki.js as the comparison points

BookStack is the closest comparison in intent: a self-hosted wiki for documentation, written in PHP on Laravel, with a shelf, book, chapter and page hierarchy. The structural difference is the container. BookStack organises content as a fixed tree you navigate; MrDoc organises content as projects containing documents, with permission set at the project level and a Markdown editor as the primary writing surface. If your authors think in Markdown files and diagrams, MrDoc's editor is closer to that habit. If your authors think in a table of contents that mirrors a manual, BookStack's hierarchy is more direct.

Wiki.js takes a third approach, built on Node.js with a choice of database backends and a Git storage sync option. Its selling point is the sync: content can live in a Git repository and be pulled into the wiki. MrDoc's README documents no Git sync. It does document an account-based API for fetching a corpus and creating documents, and a separate local document synchronization tool is linked in the README's Other Tools section, but that tool is a third-party project, not part of MrDoc.

The honest summary is that these three overlap on the core job and diverge on stack and content model. Choosing MrDoc means choosing Python and Django, project-scoped permissions, and a Markdown-first editor. Choosing Wiki.js means choosing Node and, if you want it, Git-backed content. Choosing BookStack means choosing PHP and a rigid hierarchy. None of these is a superset of the others, and the README does not claim otherwise.

## Licence and the cost of staying current

MrDoc is licensed GPL-3.0. That matters if you plan to modify it and distribute the result, because the GPL requires derivative distributions to carry the same licence and to make source available. Running it privately for your own team does not trigger distribution obligations in the ordinary case, but the boundary is a legal question and this is not legal advice. The repository also carries DISCLAIMER.md and SECURITY.md at the top level, which the README does not summarise, so read those files directly rather than relying on the feature list.

The upgrade cost is the part the README understates. It documents docker-update.sh as the update path in one line and gives no migration notes, no version compatibility matrix, and no rollback command. Because the compose file pins an image tag, an update means changing that tag, and the README does not say which tags are safe to move between. The release cadence listed above shows roughly quarterly tags, so a year of neglect can put you several releases behind with database migrations in between. The makemigrations and migrate commands you ran at install time are the same mechanism an upgrade will use, and the README does not describe how to take a database backup before running them.

## Conclusion

MrDoc fits an individual or a small team that wants a private Django-based wiki and is willing to follow the linked deployment guide rather than the README alone. It is the wrong choice if you need a vendor-supported product with a documented upgrade and rollback path, because the README documents neither. Before adopting it, verify two things on your own server: that the app starts and serves on port 10086 with your database settings, and that the Docker image tag in docker-compose.yml matches the release you intend to run, since the file pins zmister/mrdoc:v9.5 while the repository badges list v1.1.0.

## FAQ

### How do I install MrDoc with Docker?

The README gives a one-line path: clone the mrdoc-install repository, make docker-install.sh executable and run it. Updates use docker-update.sh. The docker-compose.yml in the main repository maps port 10086 and pins the image zmister/mrdoc:v9.5.

### What database does MrDoc need?

requirements.txt lists mysqlclient, and the Dockerfile build stage installs mariadb-dev and postgresql-dev, so MySQL-compatible and PostgreSQL backends are both plausible from the dependency set. The README says to configure the database information before running makemigrations and migrate, but does not name the settings keys.

### Is MrDoc suitable for a large organisation?

The README describes it as suitable for individuals and small teams, with project-level permissions in four modes: public, private, visible to specified users and visible to an access code. The feature list documents no single sign-on, audit logging or multi-tenant isolation.

## Sources

- [License: GPL-3.0](https://github.com/zmister2016/MrDoc/blob/master/LICENSE)
- [Project website](https://mrdoc.io/)
- [README](https://github.com/zmister2016/MrDoc/blob/master/README.md)
- [Releases](https://github.com/zmister2016/MrDoc/releases)
- [zmister2016/MrDoc on GitHub](https://github.com/zmister2016/MrDoc)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zmister2016-mrdoc