Wiki|Docs: a databaseless Markdown wiki you can run on your own machine or host yourself

The bet is that a wiki should still be a folder of text files

Wiki|Docs describes itself in one line as a databaseless Markdown flat-file wiki, and that single phrase explains the whole product. Pages are plain Markdown files with YAML frontmatter, and the project lists no database requirement among its features. The stated motivation is ownership over information: you can read, edit and version the content with any tool, including the LLM tools of your choice, and nothing is locked inside a proprietary store. The audience is a person documenting a project, building a personal knowledge base, or running a small team wiki who has been burned by a hosted wiki that raised its price or shut down. It is not aimed at documentation teams that need granular permissions, review workflows or an audit trail. The tradeoff is explicit from the start: less convenience from a service, more control over plain text.

Version 2 replaced the PHP stack with NestJS, Angular and Electron

The current release is a full rewrite, and the change is large enough to affect adoption decisions. Version 2 moved the entire stack to TypeScript: a NestJS backend, an Angular web client and an Electron desktop application. The project keeps the original PHP implementation on a separate branch named legacy, which is a useful detail for anyone with an existing installation. The rewrite also introduced a standalone desktop application that keeps Markdown files on your computer, a self-hosted Docker service that can serve the same data, and sync between the two. Alongside that, the backend exposes REST APIs, and the screenshots section shows a Swagger documentation page, which means the wiki is meant to be a component in a larger tooling setup rather than an island. The repository layout backs this up, with separate backend, frontend and desktop directories plus a shared directory and a pulse directory, and a VERSION file that the Makefile uses to keep the three package manifests in step.

Running the container and reaching the web client

Two deployment shapes are supported and the Docker route is the one the project calls the recommended way to host it yourself, described as the easiest and fastest way to get started. A Docker image is published on Docker Hub under the wikidocs repository, and the README links to it directly. Once the container is running, the web client is served at the local address http://localhost:3210, and the backend API and its Swagger documentation are exposed on a separate local port, though the README excerpt ends before that port number is given, so you should read the current documentation rather than guess. The repository ships a docker directory and Compose targets in the Makefile for bringing the stack up and down, and there is a dev.env file for local configuration. Because the data stays on disk, the container is replaceable, which is the practical argument for running it yourself in the first place.

Building from source means keeping three package versions in step

The Makefile is the entry point for development, and its most interesting target is a consistency check rather than a build. A check-versions target reads the VERSION file with jq, pulls the version out of backend, frontend and desktop package.json files, and fails with a version mismatch message if the four values disagree. That is the project telling you that a release is a coordinated cut across three packages, and a contributor who bumps one manifest will be stopped by it. Dependency installation and the test run follow the same pattern, with separate npm ci calls per package and a shared test-results directory that a Node script turns into a summary. Localizations get their own check, run from the frontend directory. The build itself compiles the backend and the frontend, and a separate target produces the desktop artifact.

What the editor does beyond plain Markdown

The feature list goes well past file storage. There is a full WYSIWYG editor on top of the Markdown source, YAML frontmatter for metadata, support for KaTeX math and for Mermaid diagrams, syntax highlighting, and unlimited page revisions, with separate screenshot pages for versions and for a trash view, which implies deleted pages are retained and recoverable. Attachments and images can be uploaded, images can be pasted from the clipboard, and content can be organised into namespaces. Browsing can be public or private, and the interface offers multiple languages and a dark mode. Put plainly, this is a feature set comparable to a hosted wiki product, with the flat file model underneath. The private versus public distinction is a hosting concern, not a file format one, so a self-hosted instance can be private to your network without changing how the Markdown is stored.

The desktop app and the remote instance are two views of one folder

Sync is the piece that distinguishes this from a plain Markdown folder viewer. The desktop application keeps your files on your machine and the Docker instance can store and serve the same data, and the two are kept in step. That design targets a specific working pattern: write offline or on a laptop, and the same knowledge base is available on a hosted instance for a phone or for other people. What the documentation does not describe is how simultaneous edits from two copies are reconciled. There is no account model for multiple editors, no lock file, and no merge semantics in the visible documentation, so the safe reading is that this is one user with two locations, not a collaborative editor. Anyone planning to put several people on the same wiki through this path should test it directly before relying on it, because conflict handling is exactly where a flat-file design has to earn its complexity.

Where Wiki|Docs is the wrong choice

There are two clear boundaries. The first is collaboration. A wiki product for a team normally implies accounts, roles and a record of who changed what, and the visible feature list offers namespaces, public and private browsing, revisions and sync, but no user management or permission model. The second is the operational cost: a self-hosted instance means running the container, keeping the data directory safe and handling upgrades yourself, and the rewrite to version 2 is a good reminder that a major version can move the ground under an installation. The project also ships a public demo playground with shared credentials, which is convenient for evaluation but is not a template for how you should run a real instance. Finally, the older PHP code survives only on a legacy branch, so an existing installation has no obvious upgrade path other than migrating content.

Release rhythm, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-14. The release history shows a major step from 1.0.93 on 2026-08-06 to 2.0.0 on 2026-08-18 and 2.0.1 on 2026-08-19, so the 2.0 rewrite landed in August 2026 and the patch release followed the next day. Patch numbering has been climbing quickly before that, which suggests a frequent release habit during development. The licence is MIT, which keeps commercial use and redistribution straightforward, though a reader embedding it in a larger product should still read the LICENSE file. The homepage is www.wikidocs.app and the Docker image lives on Docker Hub. For anyone upgrading, the practical cost is data migration rather than licensing, and the version check target in the Makefile means a clean upgrade path has to keep the backend, frontend and desktop manifests aligned with the VERSION file.

Editorial conclusion

Wiki|Docs suits people who want their knowledge base to remain readable Markdown on disk, who are willing to run a Node backend and an Angular client, and who want a desktop app and a self-hosted instance to share the same files. It does not suit teams that need multi-user permissions, revision conflict handling or a managed service, because the sync path is one user at a time and the project documents no conflict resolution. Before you commit, verify that the 2.0 rewrite covers the plugins or extensions you relied on in the PHP version, test a round trip of desktop to remote sync on a copy of your pages, and check whether your hosting budget covers running the container yourself.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. Zavy86/WikiDocs on GitHub