DokuWiki

Last reviewed Sep 13, 2026 · 808 words

A DokuWiki backup is tar czf wiki.tgz dokuwiki/ and a restore is untarring it onto any box with PHP. Twenty-two years after its first release, that is still the reason to pick it: every page is a .txt file under data/pages/, every old revision is a file under data/attic/, every upload sits in data/media/, and there is no database anywhere to dump, upgrade, or corrupt. On 128 MB of RAM it serves a team wiki without noticing. The trade is a default theme that looks its age and a markup that is DokuWiki's own rather than Markdown. For a documentation wiki that must still open in 2036, I would take that trade.

Install is a tarball or a container, and either takes ten minutes

Bare-metal: unpack the release into a PHP-capable web root, visit install.php, set the wiki name and the admin account, delete install.php. Docker: the linuxserver.io image (lscr.io/linuxserver/dokuwiki) is the maintained one most people use, with a single /config volume that holds the whole wiki, and Bitnami publishes another. Either way the entire state is one directory, which is what makes the backup line above true.

Two things need doing before the wiki is public. Block web access to data/, conf/, bin/, and inc/: the shipped .htaccess files handle Apache if AllowOverride is on, and nginx needs the equivalent location denies from the DokuWiki docs, or the raw text of every page (including access-controlled ones) is readable by URL. Then turn on ACLs in the admin panel and set the default policy to read-only or none for anonymous users, depending on whether the wiki is public.

Namespaces, ACLs, and versioning do the wiki work

Pages are addressed as namespace:subnamespace:page, mapping directly to directories on disk, so ops:runbooks:postgres is data/pages/ops/runbooks/postgres.txt. ACLs apply per namespace or page, per user or group, from a single conf/acl.auth.php that you can also edit by hand. Every save writes a revision to the attic with a diff view and one-click revert, and the recent-changes page is a real audit trail. Users live in conf/users.auth.php by default, or in LDAP, Active Directory, or OAuth through plugins, and the authplain file backend is fine up to a few hundred users.

Search is built in and indexes on save. It is good enough for a team wiki and gets slower at tens of thousands of pages, which is well past where most installs end up.

The plugin library is the ecosystem, and 5 plugins cover most needs

The extension manager installs from within the admin panel. The ones I put on every install: move (renames pages and fixes every link, which core cannot), wrap (boxes, columns, and notes without HTML), include (transclude pages), edittable (a table editor for the markup's weakest area), and struct if the wiki holds anything list-like, because it turns pages into typed data you can aggregate. For people who cannot live without Markdown, the commonmark plugin lets pages be written in it. On the look, the bootstrap3 template fixes the "dated default" complaint in five minutes and is what most modern-looking DokuWikis are running.

Because content is text, git works too: commit data/pages/ and data/media/ on a schedule and the wiki has off-site history for free.

BookStack, MediaWiki, and Wiki.js draw the lines

BookStack is the modern-looking team documentation tool with a WYSIWYG editor, a book/chapter/page hierarchy, and a MariaDB dependency; pick it when the writers are non-technical and will judge the tool by its editor. MediaWiki is for encyclopaedia-shaped wikis with heavy templating and thousands of contributors, and it is far heavier to run. Wiki.js has the nicest interface and Markdown-first editing with a PostgreSQL requirement and a project that has been slow to ship its next major. DokuWiki's position: the lowest operational cost of the four, the most durable storage, the plainest look. For a sysadmin's runbook wiki, a hobby project's docs, or a small company that wants a wiki nobody has to maintain, it is the right shape. For a design team that wants pretty pages, it is not.

What I'd do

linuxserver.io container, /config on a volume that your nightly backup already covers, nginx denies for data/ and conf/ checked by fetching a raw page URL yourself, ACLs set to no anonymous access, move, wrap, include, and struct installed, bootstrap3 template. Then leave it alone for a decade. In the wikis category it is the default I hand to anyone whose first question is "what happens when I stop maintaining this", because the answer is nothing bad.