unsubbed.co

django-wiki

Self-hosted content management tool that provides wiki system with complex functionality for simple integration and a superb interface. Store your.

Open-source wiki for Django developers, honestly reviewed. Not a standalone product — a library you integrate.

TL;DR

  • What it is: A GPL-3.0-licensed Python library that adds a full wiki system to an existing Django web application — not a standalone app you deploy independently [README][5].
  • Who it’s for: Django developers who need wiki functionality built into a product they’re already building. Not for non-technical founders looking for a turn-key wiki [README][2].
  • Cost savings: $0 in licensing. Your costs are a VPS and developer time to integrate it. No SaaS tier exists because it’s not a standalone product — pricing comparisons with Confluence or Notion don’t apply in any direct way.
  • Key strength: Deep Django integration. If you’re already running Django, you get a full wiki engine that speaks your ORM, your auth system, your admin panel — no bridging, no separate database [README][5].
  • Key weakness: Requires existing Django skills and a Django project to embed it in. 1,915 GitHub stars over a long project lifespan suggests a narrow but stable niche. GPL-3.0 means anything you distribute that uses it must also be GPL. Not the tool a non-technical founder installs on a Saturday afternoon [README][2].

What is django-wiki

django-wiki is a wiki engine distributed as a Python package (pip install wiki). The one-line pitch from its GitHub README: “A wiki system with complex functionality for simple integration and a superb interface. Store your knowledge with style: Use django models.” [README]

The operative word is integration. django-wiki doesn’t run standalone. You install it into an existing Django project, add it to INSTALLED_APPS, wire up its URLs, run migrations, and the wiki becomes part of your application — sharing your users, your database, your authentication, and your Django admin [README]. It’s closer to how you’d add a Django REST Framework API or a Celery task queue than how you’d deploy BookStack or Wiki.js.

The project has been in active development long enough to track Django versions from 1.4 all the way up to Django 5.2 (current as of the 0.12.x release series) [README]. That version longevity is a signal: it’s a maintained library, not an abandoned experiment. It’s fully translated into 13 languages, with more in progress via Transifex, and has a live demo running the main branch at https://demo.django-wiki.org [README].

Community channels include IRC on libera.chat (#django-wiki), a Google Groups mailing list, GitHub Discussions, Fediverse, and Twitter — a modest but real support surface [README].

What the project is not: a competitor to Wiki.js, BookStack, Outline, or DokuWiki in the “install-and-run wiki” category [2][5]. Those tools are self-contained applications. django-wiki is a component.


Why people choose it

The r/selfhosted community [2] lists django-wiki in the same breath as BookStack, DokuWiki, Wiki.js, Outline, and a dozen others when someone asks for a wiki recommendation. But the actual comparisons in that thread don’t land on django-wiki as a winner for general use — it surfaces as an option, not a standout recommendation, because most people asking “what wiki should I run?” are not already running Django applications.

The real reason people choose django-wiki isn’t “I want a wiki.” It’s “I’m building a Django application and my users need wiki-like content management built in.” The killer use cases:

  • Documentation embedded in a SaaS product. You’re building a Django-based platform and want users to create and edit content without standing up a separate wiki instance.
  • Internal knowledge base inside a Django intranet. Your company already runs Django. You want wiki pages that respect your existing user permissions and groups.
  • Adding structured content to an existing codebase. The wiki uses standard Django models, so your existing Django ORM skills, migrations, and admin tools apply directly [README][5].

This is not a tool you choose because you surveyed the wiki market. It’s a tool you choose because you’re already in the Django world and stepping outside it would mean running two separate auth systems, two databases, and two user management flows.

The Medium publication called “Django Wiki” [1][3] covers Django development practices in general — thin views, security patterns — and while it operates under that name, it’s a development blog, not product reviews. Worth noting to avoid confusing the publication with the software.


Features

Based on the README and canonical feature list from the merged profile:

Core wiki engine:

  • Full article creation and editing with a rich interface [README][5]
  • Article revision history — every edit is versioned [README]
  • Article attachments [README]
  • Hierarchical article structure (parent/child pages) [README]
  • Markdown-based content editing [5]
  • Permission system per article or article tree, plugged into Django’s auth framework [README]

Integration features:

  • Uses Django models — wiki content lives in your existing database, queryable via ORM [README]
  • Plugs into Django admin for content management [README]
  • Reuses your Django user accounts — no separate user management [README]
  • Full Django migration support — upgrades follow standard Django migration workflow [README]

Extensibility:

  • Plugin API — the README describes it as “pretty stable” [README]
  • REST API support (listed as a canonical feature in the merged profile) [profile]
  • Docker support for containerized deployments [profile]

Internationalization:

  • Translated into 13 languages [README]
  • Translation managed via Transifex — community can contribute new languages without code changes [README]

Django version support:

  • Current 0.12.x release supports Django 4.0 through 5.2 [README]
  • Long track record of keeping up with Django major releases [README]

What’s missing or unclear from available data: search quality, attachment storage backends, real-time collaboration, and the depth of the REST API surface. The README doesn’t detail these and no thorough third-party review covers them.


Pricing: SaaS vs self-hosted math

There’s no SaaS tier. django-wiki is a library. You run it on infrastructure you control.

What you pay:

  • Software: $0 (GPL-3.0) [README][5]
  • Server: $5–20/mo on any Python-capable VPS (Hetzner, Contabo, DigitalOcean) — but this is the cost of your entire Django application, not just the wiki component
  • Developer time: this is the real cost, and it’s non-zero (see Deployment section below)

License cost of the GPL-3.0: If you’re building an internal tool or a product you don’t distribute to others, GPL-3.0 is effectively the same as MIT — use it freely, run it privately. If you’re building a commercial SaaS you plan to license to customers, GPL-3.0 requires that you also release your source code under GPL — a real constraint [README][profile]. For embedded internal wikis or developer tools, this rarely matters. For commercial product builders who want to keep their code proprietary, it matters a lot.

Comparison context: Confluence charges ~$5.75/user/month. Notion is $8–15/user/month. For a 20-person team, that’s $115–300/mo. django-wiki’s cost is your VPS (already running your Django app) plus developer time to integrate and maintain it. If that developer time is genuinely one day of work and you’re already running Django, the math is obvious. If it means hiring a Django developer, the math changes.

Data on specific pricing comparisons beyond this is not available from the sources provided.


Deployment reality check

This is the section where django-wiki most differs from every other wiki reviewed on this site. You are not deploying an application. You are integrating a library.

Prerequisites:

  • An existing Django project or willingness to create one
  • Python and pip
  • A database (PostgreSQL recommended for production; SQLite for local dev)
  • Basic Django knowledge — you will read code, not just click through a UI installer [README]

The install path:

  1. pip install wiki (or add it to requirements.txt)
  2. Add wiki, wiki.plugins.macros, wiki.plugins.notifications etc. to INSTALLED_APPS
  3. Include wiki URLs in your urls.py
  4. Run python manage.py migrate
  5. Configure storage backend for attachments
  6. Add to your templates or use the default ones

What can go sideways:

  • If you’ve never touched Django, this is not a beginner project. The r/selfhosted thread [2] didn’t surface django-wiki as a recommendation for someone who “just wants a wiki” — it appeared in a list but the community steered toward BookStack and DokuWiki for non-technical users.
  • Template customization requires Django template knowledge. The default look is functional but will need work to match your application’s design.
  • The plugin API is described as “pretty stable” in the README [README] — the hedge there is intentional. Plugins that worked on older Django versions may need updates.
  • Docker is listed as a supported deployment format [profile], but unlike BookStack or Wiki.js, there’s no official “one docker-compose and you’re done” single-app container. Docker here means containerizing your entire Django app.

Realistic time estimate: A Django developer who knows the framework can integrate django-wiki into an existing project in half a day to a full day. A developer learning Django from scratch to run django-wiki would need considerably longer. A non-technical founder cannot do this without technical help.


Pros and cons

Pros

  • Native Django integration. Shares your database, users, permissions, and admin. No foreign auth system, no data bridge, no separate service to keep running [README][5].
  • Stable, long-maintained project. Django version support going back to Django 1.4 and tracking through 5.2 shows real longevity [README]. Not an abandoned side project.
  • Plugin system. Extensible without forking the core. Notifications, macros, and other plugins ship with the project [README].
  • 13-language support. Unusually good internationalization for a niche library [README].
  • GPL-3.0 freedom for internal use. For internal tools and non-distributed applications, GPL-3.0 is no constraint — you get a full wiki engine at no licensing cost [README][5].
  • REST API. Listed as a canonical feature [profile], useful for headless or programmatic content management.
  • Live demo. You can evaluate the interface without installing anything at https://demo.django-wiki.org [README].

Cons

  • Not a standalone application. Every other wiki on the awesome-selfhosted list [5] can be deployed independently. django-wiki cannot — it requires a host Django project. This is the most important single fact about the tool.
  • GPL-3.0 copyleft. For commercial software you distribute to customers, this is a real constraint. Proprietary SaaS products that want wiki functionality need to budget for this or choose an MIT/Apache-licensed alternative [README][profile].
  • Modest adoption. 1,915 GitHub stars [profile] is small for a project this age. Compare with BookStack (~15K stars) or Wiki.js (~24K stars). The smaller community means fewer plugins, fewer tutorials, and thinner third-party support.
  • Limited third-party reviews. Unlike most tools reviewed here, almost no independent published reviews of django-wiki exist. The r/selfhosted community [2] lists it without detail. The homelab wiki [5] gives it one line. This is correlated with the narrow target audience — Django developers who need it know it, everyone else doesn’t look.
  • Requires Django expertise to deploy and maintain. Not a criticism of the software itself, but a real cost for teams without Django developers.
  • No standalone search. Search depends on Django’s capabilities unless you integrate a third-party backend (Elasticsearch, etc.) — the README doesn’t address this in detail.

Who should use this / who shouldn’t

Use django-wiki if:

  • You’re already building a Django application and want wiki pages as a native feature — same users, same database, same admin.
  • You’re a Python/Django shop building an internal knowledge base and want it integrated with your existing authentication and user management.
  • Your team has Django developers on staff who can handle the integration, customization, and occasional upgrades.
  • You need multilingual wiki content — 13 languages out of the box is genuinely useful [README].
  • GPL-3.0 is acceptable for your use case (internal tools, open-source projects).

Skip it (use BookStack instead) if:

  • You want a wiki you can install without writing code. BookStack is a standalone PHP application with a Docker installer and an admin panel that requires no programming knowledge [2][5].
  • You’re a non-technical founder. BookStack, DokuWiki, and Wiki.js all offer one-command installs and web-based administration.

Skip it (use Wiki.js instead) if:

  • You want modern UX, built-in search, multiple editor types (Markdown, WYSIWYG, AsciiDoc), and a standalone Node.js application with Docker compose support [2][5].
  • You’re switching from an existing wiki and want feature parity without integration work.

Skip it (use Outline instead) if:

  • You need a Notion-like team knowledge base with real-time collaboration, clean mobile UX, and Slack/Google integrations — and you’re willing to run Node.js [5].

Skip it (stay on Confluence/Notion) if:

  • You don’t have a Django application. Adopting Django just to use django-wiki is like building a kitchen to get access to one recipe.

Alternatives worth considering

From the same category lists [2][5]:

  • BookStack — PHP, MIT licensed, standalone, Docker-installable. The most recommended replacement for Wiki.js in the r/selfhosted thread [2]. Clean book/chapter/page hierarchy. No programming required.
  • DokuWiki — PHP, GPL-2.0, no database required (stores in flat files), extremely low resource footprint. Mature and widely deployed [5].
  • Wiki.js — Node.js, AGPL-3.0, modern editor, Git-backed storage option, good search [2][5]. The tool the Reddit poster was trying to escape, but many others prefer it.
  • Outline — Node.js, BSD-3-Clause (source-available for self-host). Notion-like UI, Slack integration, real-time collab. Requires more infrastructure [5].
  • MediaWiki — PHP, GPL-2.0. The Wikipedia engine. Extremely powerful, extremely complex. Only reach for it if you need Wikipedia-scale organization [5].
  • Gollum — Ruby, MIT, Git-backed. Minimal, developer-oriented, good for GitHub-style wikis [5].

For a non-technical founder choosing a self-hosted wiki: the realistic shortlist is BookStack vs Wiki.js vs DokuWiki. django-wiki doesn’t belong on that list — it’s a different category of tool.


Bottom line

django-wiki is well-suited to exactly one scenario: you’re building or running a Django application and you want wiki functionality that lives inside it rather than beside it. For that use case, it delivers — stable, maintained, multilingual, pluggable, and genuinely integrated with Django’s auth and ORM. The GPL-3.0 license is fine for internal tools but requires attention if you’re building commercial software.

For everyone else, it’s the wrong tool. If you want a wiki and don’t have a Django application already, there’s no sensible reason to build one just to use this library. BookStack, DokuWiki, and Wiki.js are each installable in under an hour with no programming knowledge. If you’re unsure which fits your situation, that’s what upready.dev is there to figure out with you.


Sources

  1. Django Wiki on Medium“Django Utilities That Keep Your Views Thin and Maintainable” (April 2026). https://medium.com/@djangowiki/django-utilities-that-keep-your-views-thin-and-maintainable-1d6e4d384006
  2. r/selfhosted“Looking for a better Wiki” (Reddit thread, 2 years ago). https://www.reddit.com/r/selfhosted/comments/196e77w/looking_for_a_better_wiki/
  3. Django Wiki on Medium“Common Django Security Mistakes Even Senior Devs Still Make” (March 2026). https://medium.com/@djangowiki/django-security-mistakes-even-senior-devs-still-make-advanced-eeb0c8c21f33
  4. awesome-selfhosted.net“Python — Awesome Selfhosted”. https://awesome-selfhosted.net/platforms/python.html
  5. The Homelab Wiki“Awesome Selfhosted — Wikis”. https://thehomelab.wiki/books/helpful-tools-resources/page/awesome-selfhosted-wikis

Primary sources:

Features

Integrations & APIs

  • Plugin / Extension System
  • REST API