OT

Otter Wiki

Lightweight Git-backed documentation wiki

Wikis & Documentation ★ 1.5k stars Easy setup MIT

Otter Wiki is a minimalistic open-source wiki that stores its pages as Markdown in a Git repository. It offers a simple web interface with editing, history, and search for small teams.

Key features

  • Git-backed Markdown pages
  • Built-in history and diffs
  • Full-text search
  • Minimalist interface

Pros & cons

Strengths

  • Easy to host and back up
  • Clean, simple UI

Trade-offs

  • Basic feature set
  • Smaller community

Otter Wiki replaces

Last reviewed Sep 13, 2026 · 766 words

The entire Otter Wiki backup procedure is git clone. Pages are Markdown files committed to a normal Git repository on disk, history is git log, and if the container vanishes tomorrow your documentation is a folder you can read in any editor. That property, plus a 128 MB footprint and a first boot that takes about 2 minutes, is why I recommend it for small teams and households who want a wiki and do not want to operate one. The trade is a deliberately basic feature set, and this page is about whether that trade suits you.

The Git repository is the product

Otter Wiki is a Python Flask app that writes every page save as a commit. The web interface exposes that directly: each page has a history tab with per-revision diffs, and you can revert to any of them. Attachments live in the same repository next to the page. Users, permissions and settings are the only things not in Git; they sit in a small SQLite database beside the repo. So a full backup is the data directory, and a git-only backup gets you all the content.

The consequence people underrate is that you can write from outside the web UI. Clone the repository, edit in your editor, push, and the wiki reflects it. Teams who keep runbooks under version control anyway get a rendered, searchable, linkable view of what they already have, without adopting a second source of truth.

Two minutes to a running wiki

services:
  otterwiki:
    image: redimp/otterwiki:2
    ports:
      - "8080:80"
    volumes:
      - ./app-data:/app-data
    restart: unless-stopped

The first visitor creates the admin account. Everything, repository and SQLite alike, ends up under ./app-data, so that one bind mount is the whole persistence story. Put Caddy in front for TLS and you are done; there is no worker, no cache service, no database container to babysit. I have run it on a 1 GB VPS alongside 6 other services and never seen it in the top of docker stats.

Permissions fit a team of 10, not a company

Access control is site-wide, not per page. You choose whether anonymous visitors can read, whether they can edit, whether registration is open or approval-based, and whether editing needs a confirmed email address. Admins are a flag on the user. That is enough for a family wiki, a club, a small engineering team, or a public documentation site with a handful of trusted editors. It is not enough once you need "this space is private to the finance group", and at that point you are shopping for BookStack, whose shelves, books and role permissions exist for exactly that, at the cost of a MySQL container and a heavier install.

What you do not get

No WYSIWYG editor; the editor is Markdown with a preview pane and a toolbar, which developers like and some editors resist. No page hierarchy beyond what you create with slashes in page names. No comments, no page templates, no plugin system, no SSO beyond the basic login (front it with an authenticating proxy if you need that). Full-text search is present and quick for a few hundred pages, and I would not push it past a few thousand. The MIT licence and single maintainer are also worth registering: the project is well kept and responsive, but the "smaller community" con means fewer ready answers when something odd happens.

Otter Wiki against the bigger names

Wiki.js has Git sync as a feature rather than as its storage model, and brings a visual editor, granular permissions and a much larger surface, on top of PostgreSQL. DokuWiki is the other no-database choice and has 20 years of plugins, with an older interface and its own markup rather than Markdown. Otter Wiki wins when Markdown-in-Git is a requirement rather than a nice-to-have, and loses the moment you need workflow features. The full field is on the wikis category page.

What I'd do

For a team under 15 people who already live in Git and Markdown, run Otter Wiki exactly as the compose file above, behind Caddy, with registration set to approval, and add a nightly git push from app-data/repository to a private remote as the off-site backup. If you need per-space permissions or a rich editor on day one, go straight to BookStack and do not look back; Otter Wiki is not a stepping stone, it is the right end state for a specific, modest need.

Compare Otter Wiki

26 head-to-head comparisons.

Similar wikis & documentation apps