Otter Wiki

Self-hosted team wiki, honestly reviewed. No marketing copy, just what you get when you run it on your own server.

TL;DR

• What it is: A minimalist, self-hosted wiki where every page is a plain markdown file stored in a Git repository — no database, no migration anxiety [README][2].
• Who it’s for: Solo founders, small teams, and developers who want a clean place to write documentation or internal knowledge without paying per-seat SaaS fees or wrestling with Confluence’s configuration overhead [1][2].
• Cost savings: Confluence charges $5.75/user/month (minimum 10 users = $690/year). Notion Teams runs $16/user/month. Otter Wiki self-hosted costs $0 in licensing plus $5–10/month for a VPS, with no per-user fees.
• Key strength: Zero-database setup combined with genuine Git version control — every page edit is a commit, you can clone the entire wiki for backup, and there’s nothing to “export” when you want to leave [1][2][3].
• Key weakness: Still a small project (1,357 GitHub stars) with rough edges: no fine-grained per-page access control in the stable release, some UX friction in the editor, and no comments system [1].

---

What is Otter Wiki

Otter Wiki is a Flask-based Python web app that turns a Git repository of markdown files into a browsable, editable wiki. You point a Docker container at a folder, and in return you get a web interface where you and your team can write, edit, and search pages — with full version history provided by Git itself, not a custom audit table [README][2].

The pitch on the README is exactly what it is: “a minimalistic wiki powered by python, markdown and git.” No buried asterisks, no surprise SaaS layer. The project started as one developer’s personal tool and has grown slowly but steadily without VC money or a sales team [website].

What makes it distinct from the other two dozen self-hosted wikis:

First, no database. BookStack needs MySQL. Wiki.js needs PostgreSQL or MongoDB. Otter Wiki needs a mounted folder and a Docker image. Your content lives in plain .md files alongside their attachments, in a structure you can read with ls [README][3]. Backup is git clone. Migration is git push. There’s no schema to dump.

Second, it’s actually Git, not a Git-inspired abstraction. Pages are stored as real commits with real commit messages. The XDA Developers reviewer notes you can “add a commit message or just save the document quietly” — the choice belongs to the writer, not the software [2]. The experimental Git HTTP server feature means you can literally git clone your wiki content to any machine.

Third, the interface is honest about being minimal. It doesn’t try to look like Notion. It looks like a wiki — page tree, editor, history, search — and that’s it.

As of this review the project sits at 1,357 GitHub stars, maintained by a single primary developer (redimp on GitHub), with recent 2.x releases still shipping new features including experimental plugin support and embedding components.

---

Why people choose it

The r/selfhosted community reception is warm but clear-eyed. The original recommendation thread [1] lays out the case plainly: lightweight, fast page loads, plain markdown files in a local Git repo (easy backup), decent default styling, sensible permissions, and “it looks like a wiki” — which turns out to be a non-trivial bar to clear. The same post is honest about the gaps: no comments, limited per-page access control, and some editor UX issues with file uploads and syntax highlighting colors.

The XDA Developers review by Yash Patel [2] is the most detailed hands-on piece available. His summary: “It’s a small, thoughtful tool that fits perfectly into how I already work, and I wish I had started using it much sooner.” The things he specifically calls out:

The writing experience is calm. His phrase — not marketing copy. He contrasts it with tools that fight for attention with feature prompts. Otter Wiki puts you in the editor and gets out of the way. “Pages load fast, edits feel instant, and saving never breaks my rhythm” [2].

The Git backing feels like version control for writers, not developers. He makes an important distinction: you don’t need to think about Git. You save a page. Optionally you write a commit message. If something breaks, you revert. The mechanism is Git but the UX conceals it behind “History” and “Revert” — which is exactly the right call for a mixed-technical team [2].

Setup is genuinely fast. He spun it up with Docker in minutes, created an admin account, and started writing. “No configuration rabbit holes, no setup wizard fatigue” [2]. The docker-compose.yml in the README is six lines.

The Easypanel documentation [3] frames it well for the “small team” use case: no database requirement makes backups and migrations simple, the single-container deployment eliminates ops overhead, and the built-in editor with live preview keeps non-technical contributors in the web UI rather than forcing them to touch Git directly.

The primary critique across all sources is consistent: it’s deliberately small. If you need Confluence-style spaces, nested permission hierarchies, inline comments, or workflow approvals, you’ve already outgrown what Otter Wiki wants to be.

---

Features

Based on the README, website, and third-party reviews:

Core editing:

• Markdown editor (CodeMirror-based) with syntax highlighting and markdown toolbar [README]
• Extended markdown: tables, footnotes, alert blocks, MathJax formulas, Mermaid diagrams [README][website]
• Paste images directly into the editor [website]
• Upload and attach files to pages [README][3]

Version control:

• Full page history — every save is a Git commit [README][2]
• Compare revisions (diff view) [website]
• Revert to any previous version [3][2]
• Optional commit messages per save [2]
• Experimental Git HTTP server: clone, pull, and push wiki content from external Git clients [README]

Navigation and search:

• Full-text search across all pages [3]
• Customizable sidebar: manual menu and/or automatic page index [README]
• A-Z page index [website]

Access control:

• User authentication with self-registration [README]
• Password recovery [website]
• First-registered account becomes admin [README]
• Settings tab for admin configuration [README]
• Note: per-page granular access control is limited in the current stable release [1]

Interface:

• Dark mode support [README][3]
• Customizable appearance [website]
• Responsive design via halfmoon CSS framework [README]

Experimental (labeled as such in docs):

• Embeddings: DataTable, ImageFrame, InfoBox, AttachmentList (new in 2.18.0) [website]
• Automatic push/pull to a remote Git repository [website]
• Plugin support [website]

What it does not have:

• Comments or discussion threads on pages [1]
• Fine-grained per-page access control (e.g., unpublished/draft status) [1]
• Code block copy button and line numbers (mentioned as a gap by r/selfhosted) [1]
• Any SaaS or managed cloud option — this is self-host only

---

Pricing: SaaS vs self-hosted math

Otter Wiki has no SaaS tier, no freemium, no usage-based billing. It’s self-hosted or nothing.

The real comparison is against the tools it replaces:

Confluence (Atlassian):

• Free: up to 10 users, limited storage
• Standard: $5.75/user/month — for 10 users that’s $690/year; for 20 it’s $1,380/year
• Premium: $11/user/month
• The pricing scales directly with team size, and Atlassian has a track record of aggressive price increases

Notion:

• Free: single user, limited blocks
• Plus: $12/user/month
• Teams: $16/user/month — for 5 users that’s $960/year
• All your data lives on Notion’s servers

BookStack (self-hosted alternative):

• Free software, requires a MySQL/MariaDB database and a PHP/Apache stack
• More features than Otter Wiki (chapters, books, shelves, LDAP) but heavier to run

Otter Wiki self-hosted:

• License: $0 (MIT) [README]
• VPS: $5–10/month on Hetzner, Contabo, or DigitalOcean
• Zero per-user fees regardless of team size

Concrete example: A 10-person team currently on Confluence Standard pays $690/year. Switch to Otter Wiki on a $6/month Hetzner VPS: $72/year — saving $618/year — with no per-user ceiling. Add more team members: still $72/year.

The trade-off is real: you own the infrastructure, you handle updates, and you don’t have Atlassian’s support SLA. For a 10-person startup that’s a reasonable trade. For a 500-person company that needs SSO, compliance logging, and an enterprise support contract, it’s not.

---

Deployment reality check

Every source agrees on this: setup is genuinely fast. The XDA Developers reviewer had it running in minutes [2]. The r/selfhosted thread mentions it repeatedly as a lightweight option [1]. The Easypanel template exists precisely because single-container deployment is that simple [3].

What you need:

• A Linux VPS (1–2GB RAM is sufficient for a small team)
• Docker and docker-compose
• A domain and reverse proxy (nginx, Caddy, or Apache) for HTTPS — the README provides example configs for all three [README]
• Nothing else: no database, no separate caching layer, no message queue

The actual docker-compose.yml (from the README):

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

That’s the complete file. Six lines. [2][README]

Realistic time estimates:

• Technical user with Docker experience: 15–30 minutes to a working HTTPS instance
• Non-technical founder following the installation guide: 1–2 hours including domain setup
• If you’ve never touched a Linux server, budget a full afternoon or hire someone for a one-time setup

What can go sideways:

• Editor UX friction: the r/selfhosted thread [1] mentions issues with file uploading from within the editor and color rendering in the editor view. These are not blockers, but they’re noticeable compared to a polished SaaS tool.
• Per-page access control is absent in the stable release. You can have authenticated and anonymous access, but you can’t mark individual pages as private or draft [1]. If your use case requires “this page is for the finance team only,” you’re working around this with separate wiki instances.
• Small maintainer team. Otter Wiki is primarily one developer’s project. Feature velocity is steady but slow. If something breaks on your setup, community support is through GitHub issues — there’s no enterprise support tier.
• Experimental features carry real “experimental” caveats. The Git remote sync and plugin support are marked experimental for a reason [website]. Don’t build a critical workflow dependency on them without testing first.

---

Pros and cons

Pros

• Zero database. Plain markdown files in a folder. Backup is cp -r or git clone. Migration is moving a folder. Nothing to schema-upgrade [README][2][3].
• Real Git history, not a fake audit log. Every save is a commit. Revert, diff, clone — standard Git tooling works on your wiki content [2][3].
• Fastest possible setup. Six-line docker-compose.yml, one container, done [2][README]. Lowest ops overhead in the wiki category.
• No per-user pricing. Add 5 users or 50 — the VPS bill doesn’t move [README].
• MIT license. Fork it, modify it, embed it in your own product — no commercial licensing discussion required [README].
• Writing experience is genuinely calm. Multiple reviewers independently describe the same thing: distraction-free, fast, no feature prompts competing for attention [1][2].
• Extended markdown without plugins. Tables, alerts, Mermaid diagrams, MathJax formulas are built in, not add-ons you have to configure [README][website].
• Dark mode included [README].

Cons

• No per-page access control. You can’t set a page as draft or restrict it to specific users. It’s all-or-nothing at the instance level [1]. If you need selective visibility, you’re running multiple instances.
• No comments or discussion. Pages can’t be annotated inline or threaded. If your team reviews documents with feedback, you’re doing it elsewhere [1].
• Editor UX has rough spots. File upload from within the editor and color handling were specifically called out as friction points by the r/selfhosted community [1]. Not deal-breaking, but noticeable if you’ve used Notion or Confluence recently.
• Small project, single primary maintainer. 1,357 stars and growing, but there’s no company, no enterprise support, no SLA. If a critical bug appears, you’re waiting for an open-source fix [README].
• Experimental features are genuinely experimental. Git remote sync, plugin support, and the new embedding components are all labeled experimental and shouldn’t be treated as production-stable [website].
• No search ranking or page weighting. Full-text search works, but it’s basic — no relevance ranking, no fuzzy matching. For a large wiki this gets unwieldy.
• Self-host only. There’s no managed Otter Wiki cloud if you later decide you don’t want to maintain infrastructure [README]. You commit to the ops work from day one.

---

Who should use this / who shouldn’t

Use Otter Wiki if:

• You’re a solo founder or small team (2–15 people) paying Notion or Confluence per-seat fees and the content is mainly internal documentation.
• You want your wiki content in plain markdown files you can read, backup, and migrate without any vendor.
• You’re comfortable with or can learn Docker and basic reverse proxy setup, or you’ll pay someone once to do the initial deploy.
• Version control of your documentation matters — knowing who changed what, when, and why.
• You want minimal ops footprint: one container, no database to babysit.

Skip it (use BookStack instead) if:

• You need nested organization: books, chapters, pages, shelves — structured documentation hierarchy beyond flat markdown files.
• Your team is non-technical and needs a familiar interface closer to Confluence.
• You need per-page or per-section permissions without running separate instances.

Skip it (use Wiki.js instead) if:

• You need multiple storage backends (database, S3, Git) with a toggle.
• You want a more polished editor with WYSIWYG mode for non-technical contributors.
• You need LDAP/SAML authentication out of the box.

Skip it (stay on Notion) if:

• You need databases, kanban views, and relational linking between pages.
• You’re not interested in maintaining infrastructure and the per-user cost is acceptable.
• Your team already lives in Notion and switching costs outweigh the savings.

Skip it (use Outline) if:

• You want a modern SaaS-quality self-hosted option with comments, reactions, and a more polished collaborative editing experience — and you’re willing to run a more complex stack (Postgres, Redis, S3).

---

Alternatives worth considering

• BookStack — structured wiki with books/chapters/pages hierarchy, MySQL-backed, richer permissions. More complex to run but more feature-complete for teams [1].
• Wiki.js — JavaScript-based, supports multiple storage backends including Git, polished UI, SAML/LDAP support. Heavier stack than Otter Wiki.
• DokuWiki — PHP, file-based (no database like Otter Wiki), large plugin ecosystem, mature project. UI shows its age but it’s rock-solid.
• Outline — the closest to a “self-hosted Notion for teams.” Excellent editor, comments, Slack integration. Requires Postgres + Redis + S3; more like a real app deployment.
• TiddlyWiki — single-file wiki, extreme portability, zero server required. Good for personal notes, impractical for team collaboration.
• Obsidian — local-first markdown notes. Not a wiki, not collaborative in the traditional sense, but relevant if the use case is personal knowledge management rather than team docs.
• Notion — the SaaS incumbent. Feature-rich, expensive at scale, your data lives on their servers.
• Confluence — the enterprise standard. Powerful, complex, priced to feel it.

For a small team escaping Notion or Confluence bills, the realistic shortlist is Otter Wiki vs BookStack vs Outline. Otter Wiki if you want the simplest possible stack and Git-native storage. BookStack if you need structured organization. Outline if you need a polished editor and are willing to run a heavier deployment.

---

Bottom line

Otter Wiki is what it says it is: a minimalistic wiki powered by Python, markdown, and Git. It doesn’t try to be Notion. It doesn’t try to be Confluence. It tries to be the cleanest possible web interface over a folder of markdown files, with Git doing all the version control work underneath. That constraint is also its biggest strength — there’s no database to break, no schema to migrate, no vendor lock-in to unwind when you eventually want to move. You run one Docker container, your content lives in plain text, and Git keeps the history.

The trade-offs are real and the project is honest about them: no per-page permissions, no inline comments, some editor rough edges, single maintainer. For a solo founder writing internal SOPs or a 5-person team documenting their product, those trade-offs are invisible next to the alternative of paying Confluence $690/year or Notion $960/year for the same job. If you need the more advanced stuff — nested permissions, comments, SAML, complex structure — budget the extra ops overhead for BookStack or Outline. But if a clean place to write markdown with full Git history is what you’re actually after, Otter Wiki gets out of your way better than anything else in this category.

If the Docker setup is the blocker, that’s a one-time job that upready.dev handles for clients — you own the infrastructure from day one.

---

Sources

1. AlexFullmoon — r/selfhosted — “An Otter Wiki is a nice alternative”. https://www.reddit.com/r/selfhosted/comments/1ge0of3/an_otter_wiki_is_a_nice_alternative/
2. Yash Patel, XDA Developers — “The version-controlled markdown wiki I should have started using sooner” (Jan 1, 2026). https://www.xda-developers.com/version-controlled-markdown-wiki-i-should-have-started-using-sooner/
3. Easypanel — “OtterWiki | Self-Host on Easypanel”. https://easypanel.io/docs/templates/otterwiki

Primary sources:

• GitHub repository and README: https://github.com/redimp/otterwiki (1,357 stars, MIT license)
• Official website and documentation: https://otterwiki.com
• Installation guide: https://otterwiki.com/Installation
• Configuration guide: https://otterwiki.com/Configuration