MediaWiki

Last reviewed Sep 13, 2026 · 955 words

MediaWiki is engineered for one shape of wiki: large, public, edited by strangers, with every revision kept forever. That is what running Wikipedia demands, and it is why the software is 24 years old, GPL-2.0, and still the safest bet for a knowledge base that might one day have 10,000 pages and 200 contributors. It is also why most small teams who install it for internal documentation give up within a year. The permission model assumes the world can read, page-level access control is not a first-class feature, and the editor speaks wikitext. Pick it for the encyclopedia-shaped job and you will never outgrow it. Pick it for a 6-person team's runbooks and you will fight it.

The Docker setup, and the file you must not lose

The official mediawiki image on Docker Hub serves PHP on port 80 and needs a database; MariaDB is the conventional pairing, PostgreSQL and SQLite are supported but get less testing.

services:
  mediawiki:
    image: mediawiki:lts
    ports:
      - "8080:80"
    volumes:
      - ./images:/var/www/html/images
      # after the installer runs, add:
      # - ./LocalSettings.php:/var/www/html/LocalSettings.php
    depends_on: [db]
  db:
    image: mariadb:11
    environment:
      MARIADB_DATABASE: wiki
      MARIADB_USER: wiki
      MARIADB_PASSWORD: change-this
      MARIADB_ROOT_PASSWORD: change-this-too
    volumes:
      - ./db:/var/lib/mysql

Open the site, walk through the installer, and it hands you a LocalSettings.php to download. Every setting, every extension, every permission lives in that file; mount it into the container, put it in git, and back it up with the database and the images directory. A MediaWiki without its LocalSettings.php is a database with no way to read it.

Two follow-ups people skip: run php maintenance/run.php runJobs from cron or set $wgJobRunRate sensibly, because thumbnail generation, category updates, and search indexing all go through the job queue, and the default of running jobs on page views makes a quiet wiki feel stale. And after every upgrade run the update maintenance script or the schema drifts.

Making it private is possible, coarse, and worth doing properly

The lines that turn a public wiki into a private one:

$wgGroupPermissions['*']['read'] = false;
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['createaccount'] = false;
$wgWhitelistRead = ['Main Page', 'Special:UserLogin'];

That makes the whole wiki login-only, and for a company intranet that is often enough. What MediaWiki will not do without a fight is "this namespace is HR-only." The Lockdown extension gets you namespace-level restrictions, but the core caches, search, and page-history features were built assuming everything is readable, and the MediaWiki manual itself says per-page access control is not supported securely. If your requirement includes granular permissions, this is the point to look at BookStack, which has role-based permissions down to the page, or Wiki.js, which has a rules engine for them. Both are in the wikis category and both are lighter to run.

The extension library is the reason to stay

What MediaWiki has that nothing else in the category matches is 20 years of extensions. VisualEditor now ships in the tarball, so the wikitext learning curve is optional for casual editors while power users keep the syntax. Semantic MediaWiki and Cargo turn pages into queryable structured data, which is how game wikis and internal catalogues generate tables from infoboxes. CirrusSearch with OpenSearch or Elasticsearch gives search that scales past the default database backend. PluggableAuth with LDAPAuthentication2 or an OpenID Connect provider handles single sign-on. Templates, with Lua via the Scribunto extension, let a wiki build its own components. If your wiki will be big and heavily structured, this ecosystem is the deciding factor.

What running it costs in practice

The catalogue's 512 MB is the honest floor for PHP plus MariaDB serving a small wiki; a wiki with CirrusSearch adds a search engine that wants 1 to 2 GB on its own. MediaWiki ships a long-term-support release every 2 years with security fixes for around 3 years, and the mediawiki:lts tag tracks it; stay on LTS unless you need a feature, because extensions lag behind the latest branch. Major upgrades are a database-schema change plus re-checking every extension's compatibility, and a wiki with 15 extensions can take an afternoon to move. Confluence refugees should read the Confluence alternatives page before assuming MediaWiki is the direct replacement; the export path from Confluence is XML-to-wikitext conversion via third-party tools, and page trees do not map onto MediaWiki's flat namespace model.

Where it beats the modern wikis

Scale, revision history, and openness. A team of 3 will never see the difference between MediaWiki and BookStack. A community of 500 editors on a fan wiki, a public documentation site that wants anonymous contributions, a research group that needs every edit attributable and reversible forever: those want MediaWiki, and the newer tools start to creak. The "powers Wikipedia" line is not marketing; it means the concurrency, vandalism handling, and history features have been tested harder than anything else you could install.

What I'd do

For a public or community wiki, an open documentation project, or anything I expected to pass a few thousand pages, I would install MediaWiki on the LTS image with MariaDB, VisualEditor on, LocalSettings.php in git, and a cron job for the job queue. For a private team wiki with a handful of writers, I would install BookStack instead and never look back. The one exception is a team that already knows wikitext from Wikipedia editing and wants Semantic MediaWiki-style structured pages; for them MediaWiki private-mode is the right call, with the understanding that per-page permissions are not on the menu.