Markdown team wikis

If you want a team wiki that stores everything as plain Markdown (.md) files without trapping your data in a proprietary or heavy SQL database, you have several great open-source, flat-file, or Git-backed options.

Top Flat-File / Markdown Team Wikis

1. An Otter Wiki
   • Storage: Plain Markdown files stored directly on the filesystem backed by a Git repository.
   • Best For: Teams that want full version history, a clean/minimalist UI, and the safety of Git (you can push/pull/backup via Git or run a built-in web viewer/editor).
   • Key Features: Live/easy Markdown editing, image paste-to-upload, Mermaid diagrams, formulas, user auth with self-registration.
   • Learn more: Check out An Otter Wiki.otterwiki.com
2. Wiki|Docs
   • Storage: Pure flat-file Markdown with YAML Frontmatter. No database required.
   • Best For: Small-to-medium teams wanting a modern WYSIWYG/Markdown hybrid editor that can run standalone locally or self-host via Docker.
   • Key Features: Namespaces for categorization, KaTeX math, Mermaid diagrams, dark mode, attachment handling, and optional remote sync.
   • Learn more: Explore the repo on GitHub - Wiki|Docs or try their public playground.github.com
3. DokuWiki (with Markdown plugins)
   • Storage: Plain text flat-files (traditionally uses its own syntax, though Markdown plugins are widely supported).
   • Best For: Maximum rock-solid stability and zero database dependencies. It has been around forever and runs on almost any basic web server.
   • Key Features: Fine-grained access control lists (ACLs), full revision history, huge plugin ecosystem.
   • The Catch: The default interface feels a bit dated out of the box.reddit.com
4. Git-backed Static Site Generators / Docs-as-Code (e.g., MkDocs with Material theme, or GitBook alternatives like Docusaurus)
   • Storage: Plain Markdown files inside a Git repository (GitHub, GitLab, or self-hosted Gitea).
   • Best For: Technical or engineering teams that already live in Pull Requests, code reviews, and CI/CD pipelines.
   • Key Features: Blazing fast search, version control via git, auto-deployment to the web.
   • The Catch: Editing requires a Git workflow or a web-based Git GUI rather than a native real-time multi-user wiki word processor.

Quick Comparison Guide

To help narrow down the best fit, tell me:

• How big is your team , and do people need simultaneous collaborative editing (like Google Docs) or just take turns editing?
• Do you prefer a web app interface your team logs into, or are you comfortable storing/editing files via Git / a local folder?

If your requirement is a team wiki where the actual source of truth is a directory of Markdown (.md) files, rather than content stored in a proprietary database, there are several good options.

I'd focus on self-hosted, open-source tools with filesystem or Git-based storage.

Best options

• 

1. LeafWiki

(Best overall for simplicity)

• Markdown files stored directly on disk.
• Single Go binary with embedded SQLite.
• No external database server.
• User roles, page hierarchy, search and Mermaid diagrams.
• MIT license.

Note: SQLite is used for application state; page content is Markdown.

Website ·GitHub

---

• 

2. Wiki|Docs

(Best for pure file storage)

• Plain Markdown files.
• No database required.
• Desktop and self-hosted Docker versions.
• User-friendly WYSIWYG editor.
• Revisions, attachments and namespaces.

Website ·GitHub

---

• 

3. Otter Wiki

(Best Git integration)

• Markdown content stored in a Git repository.
• Changes committed to Git.
• Page history and attachments.
• Collaborative editing and user login.
• MIT license.

GitHub

---

• 

4. Wikindie

(Interesting for small teams)

• Markdown files are the actual data model.
• No database.
• Self-hosted, single container.
• Team roles and read-only publishing.
• Includes Kanban boards and MCP integration.
• MIT license.

Currently early-stage (0.6.x).

GitHub

---

• 

5. Hold My Docs

• Markdown stored in an ordinary Git repository.
• Every save creates a Git commit.
• Namespaces and visibility controls.
• Search, backlinks, attachments and Mermaid.
• Single Go binary.

Early-stage project; evaluate maturity before production adoption.

GitHub

Comparison

My recommendation

I'd shortlist three:

1. LeafWiki – if you want a polished, relatively simple self-hosted team wiki.
2. Otter Wiki – if Git history, collaboration and portable content are priorities.
3. Wiki|Docs – if you want the cleanest separation from database-backed storage.

One important distinction: Wiki.js, for example, supports Git and filesystem synchronization, but its primary content storage is still a database. That's not the architecture you're asking for.docs.requarks.io

A question that will narrow this down

When you say no proprietary database, which architecture do you prefer?

1. Where should the Markdown files live?

Git repository (every change version-controlled)

Regular filesystem folder of .md files

Either is fine

---

2. Hosting preference

Self-hosted (Docker / Linux server)

Cloud-hosted SaaS

Either

---

3. Who needs access?

Multiple team members with permissions

Small internal team, shared access

Public documentation plus private pages

[Find my best match]

These answers will help distinguish a genuine file-backed collaborative wiki from a conventional wiki that merely offers Markdown export.

If you want a collaborative team wiki where the content stays in real Markdown files that your team owns, can version-control, and can move elsewhere, I’d focus on tools that use a filesystem or Git repository as the source of truth, rather than a wiki that stores everything in a proprietary database.

The key distinction is whether Markdown is merely an import/export format or the actual underlying storage format.

For a team, I’d compare options on five things:

• Markdown-first storage: pages are ordinary .md files.
• Collaboration: multiple people can edit, comment, and review changes.
• Git integration: history, diffs, branches, and pull requests where useful.
• Ease of use: teammates can edit pages without knowing Git.
• Deployment and ownership: self-hosted or managed, with a straightforward way to back up and migrate the content.

Best options to shortlist

• 

1. LeafWiki — best match for files-first

(Top pick)

Stores pages as ordinary Markdown files on disk, without requiring an external database server. It's a lightweight, self-hosted wiki with a web interface and a single Go binary. Its hosted beta is advertised as free through December 31, 2026.leafwiki.com+6

Best if you want the files themselves to remain the canonical content.

Website:LeafWiki

---

• 

2. Gollum — best for Git-native teams

A web-based wiki built around a Git repository. Wiki pages are stored as files, and Git supplies version history, diffs, and rollback. It fits teams comfortable with repositories and developer workflows.opensourcesoftware.io+1

Best if you want Git to be the source of truth.

Website:Gollum on GitHub

---

• 

3. Wiki.js — best for a more traditional web wiki

Provides browser-based editing and can synchronize content with Git repositories such as GitHub or GitLab. It offers a richer wiki experience, but verify the storage and synchronization setup carefully if Markdown files must be the authoritative copy.opensourcetools.org+1

Best if your team wants a polished web UI alongside Git workflows.

Website:Wiki.js

---

• 

4. MkDocs — best for engineering documentation

Builds a searchable documentation website from Markdown files in a directory or Git repository. It's excellent for version-controlled technical docs, but collaborative editing generally happens through your editor and Git hosting rather than a built-in wiki editor.baalda.com

Best if your team already uses GitHub or GitLab and values documentation-as-code.

Website:MkDocs

---

• 

5. Outline — best if collaboration matters more than file-based storage

Offers real-time co-editing, comments, permissions, search, and Markdown import/export. However, documents live within the application, so Markdown export is not the same as having a directory of .md files as your live source of truth.www.getoutline.com+1

Best if you want a polished team wiki and can accept application-managed storage.

Website:Outline

Quick comparison

My recommendation

Start by testing LeafWiki and Gollum. They are the closest fits for avoiding a proprietary content store. Choose LeafWiki if you want a straightforward wiki with files on disk, or Gollum if Git history and repository-based collaboration are central to your workflow.

One important caveat: ordinary Markdown files solve content portability, but not necessarily simultaneous editing, access controls, or file locking. Test those with your actual team before committing.

One question that would help narrow this down: Do you want teammates to edit everything in a browser, Google Docs-style, while the system transparently saves Markdown files—or is a Git-based workflow with pull requests acceptable?

If your team wants to avoid closed database systems and keep everything transparently in plain Markdown files under your direct control, you have a few strong architectural approaches depending on how you want to collaborate (real-time vs. Git-backed async).

Here are the best collaborative tools designed specifically around a Markdown-file source of truth:

1. Git-Backed / Web-Frontend Wikis (Best for Documentation & Async Work)

Wiki.js

• How it works: A feature-rich, modern wiki frontend that connects directly to a Git repository (GitHub, GitLab, local Git, etc.).
• The Markdown Handling: If you configure the editor to use Markdown mode, it saves and syncs clean .md files directly to your repo.
• Collaboration style: Web-based interface where multiple team members can log in, edit, and create pages, while changes automatically commit back to your flat-file repository.
• Get started: Explore setup details in the Wiki.js Git Storage Documentation.docs.requarks.io+2

GitLab / GitHub Wikis

• How it works: If your team is already technical or uses a code host, the built-in project wiki is literally a separate Git repository.docs.gitlab.com
• The Markdown Handling: Every page is a pure Markdown file that you can edit via their web UI or clone down to edit locally in your favorite text editor.docs.gitlab.com
• Collaboration style: Async, pull-request/commit-based, with full version history built into Git.
• Get started: Read more on the GitLab Wiki Documentation.docs.gitlab.com

2. Local-First & Real-Time Collaborative Tools (Best for Modern Workspaces)

CollabMD

• How it works: A lightweight, open-source tool built to turn local folders of Markdown files, Obsidian vaults, or Git documentation repos into real-time collaborative web workspaces.github.com
• The Markdown Handling: It uses your local filesystem as the absolute source of truth—no file migration or database lock-in required.github.com
• Collaboration style: Real-time multi-user editing (via Yjs), source-anchored comments, outline views, and collaborator presence, running directly over your flat files.github.com
• Get started: Check out the project repository on GitHub (andes90/collabmd).github.com

HedgeDoc

• How it works: A self-hosted, open-source collaborative Markdown editor that acts like a shared digital notebook.xda-developers.com
• The Markdown Handling: Content is written and rendered live in pure Markdown, and notes can be exported or managed as plain text.xda-developers.com
• Collaboration style: Excellent for simultaneous, real-time team note-taking, brainstorming, and meeting minutes where everyone edits the same document at once.xda-developers.com
• Get started: Learn more on the HedgeDoc Official Website.

3. VS Code + Git Ecosystem (Best for Engineering / Technical Teams)

Foam

• How it works: A personal and team knowledge-sharing system built entirely on top of Visual Studio Code and GitHub.sourceforge.net
• The Markdown Handling: 100% plain Markdown files with support for wikilinks, tagging, and graph visualization.github.com
• Collaboration style: Team members use VS Code locally, writing notes and linking ideas together, and share/sync changes via standard Git workflows and pull requests.
• Get started: Read the overview and setup guide on SourceForge's Foam vs. Logseq Comparison.sourceforge.net

To help narrow down the best fit, tell me:

• Do you need simultaneous real-time editing (like Google Docs/Notion) or an async Git push/pull workflow?
• Do you prefer a self-hosted web app your team logs into, or a local-first folder approach?