Like a company wiki, anyone at the table can add a card, link it to the others and replace one that's out of date.
MediaWiki as a Company Knowledge Base: Strengths and Limits
A company’s working knowledge can end up in too many places: shared drives, old email threads, a few documents only one person can find, and whatever the longest-serving employee remembers. An internal wiki puts that knowledge in one searchable place that anyone on staff can update.
MediaWiki, the free software behind Wikipedia, is one option for that job. It handles shared editing, page history and linked reference material at enormous scale. It was not built to hide some pages from some employees, and its own documentation says so. This guide covers what MediaWiki does well, how non-technical staff edit it, how it grows when you need more, where it fits poorly, and what running it involves. It expands the MediaWiki section of our guide to website platforms you can start without code and extend later.
Every MediaWiki fact below was checked against the documentation on mediawiki.org on October 7, 2026.
MediaWiki for a company knowledge base: key facts
| Question | Answer |
|---|---|
| What is MediaWiki? | Free, open-source wiki software. It runs Wikipedia and other Wikimedia sites, and organizations install it for their own wikis. |
| Can non-technical staff edit it? | Yes. VisualEditor, bundled with MediaWiki since version 1.35, lets people edit pages without writing wiki markup. |
| What is it good at? | Shared editing with a full history of every change, reusable templates, automatic category indexes and linked reference pages. |
| Can you make the whole wiki private? | Yes. Core MediaWiki can require a login to read anything. |
| Can you hide certain pages from certain employees? | Not reliably. MediaWiki’s documentation says it “was not designed to support per-page or partial-page access restrictions.” |
| How does it grow? | From wiki templates to Lua modules (through the bundled Scribunto extension) to PHP extensions. More than 1,500 extensions are listed on MediaWiki.org. |
| What does hosting need? | A web server, PHP (at least 8.3.0 for the current stable version) and a database such as MariaDB or MySQL, plus command line access for maintenance. |
| How long is a version supported? | Regular releases get security fixes for about a year. Long-term support (LTS) releases come every two years and get three years. 1.43 LTS is supported until December 2027, and 1.47, due November 2026, will be the next LTS. |
What does MediaWiki do well as a knowledge base?
MediaWiki’s strengths for a knowledge base are a complete edit history, reusable templates, automatic category indexes and search, all tested at Wikipedia’s scale. They follow from what MediaWiki’s documentation calls “the wiki way, which is to make bad changes easy to fix rather than hard to make.”
Every change is recorded
Every edit to every page is saved as a separate revision. A page’s history shows who changed it, when, and with what edit summary. Help:History explains how to compare any two revisions side by side and how to restore an earlier version of a page.
For a company, that history is accountability. When a procedure changes, you can see exactly what it said before, who updated it and when. A bad edit can be undone without asking IT to restore a backup.
Staff can also follow the pages they’re responsible for. Each person’s watchlist shows recent changes to the pages they watch, and the same preferences can send an email when one of those pages changes.
Templates keep repeated content consistent
A template is a wiki page whose content is pulled into other pages. Help:Templates gives the example of a welcome message used on 100 pages: edit the template once, and all 100 pages show the new text.
In a company wiki, templates suit anything that repeats: a standard box at the top of every procedure with its owner and review date, a warning banner for outdated pages, or a summary panel for each product or client.
Categories build the index for you
Adding a category tag to a page lists it on that category’s page automatically. Help:Categories describes categories as “automatic indexes that are useful as tables of contents,” and categories can sit inside other categories to form a hierarchy. Tag each procedure with its department and each department gets an up-to-date index without anyone maintaining a list by hand.
Search works, with limits worth knowing
Built-in search covers the whole wiki, and a search that exactly matches a page title opens that page directly. According to Help:Searching, the default search looks at each page’s wikitext rather than the rendered page, so text that comes from a template isn’t found. It also matches whole words: a search for “book” won’t find a page that only says “books,” unless you add an asterisk (book*).
Wikipedia’s more capable search comes from the CirrusSearch extension, which requires a separate Elasticsearch or OpenSearch server. Better search is possible on your own wiki, but it is one more service to run.
It has been tested at very large scale
MediaWiki powers Wikipedia, and new code is deployed to Wikipedia and the other Wikimedia sites in stages before each release. The Wikimedia Foundation describes Wikipedia as covering “Nearly 300 languages, more than 45 million articles.” The English edition alone has more than 7.2 million articles and more than 1.3 billion edits, according to its statistics page on October 7, 2026. An internal knowledge base is unlikely to come anywhere near that load.
How do non-technical staff edit MediaWiki?
Through VisualEditor, a word-processor-style editor bundled with MediaWiki. Underneath, pages are stored in wikitext, a markup language where '''bold''' makes bold text and [[Page name]] links to another page. Some editors prefer to work in wikitext directly for its speed and precision, and a wiki can offer both.
VisualEditor “allows for editing pages as rich content”: headings, links, tables, images and templates are edited on the page itself, much like a word processor. It has been bundled with MediaWiki since version 1.35, so there is nothing extra to download, though an administrator still has to turn it on and configure it. By default it’s enabled for content pages, user pages, file pages and category pages.
| VisualEditor | Wikitext | |
|---|---|---|
| Feels like | A word processor | Writing in a markup language |
| Best for | Staff who edit occasionally | Staff who edit often, and template or module authors |
| Templates | Filled in through a form | Typed with their parameters |
| Setup | Bundled, but an administrator enables it | Works out of the box |
Each person can choose which editor to use. Templates are easier to use in VisualEditor when their authors add TemplateData, which describes each template’s parameters so VisualEditor can show a form for them. TemplateData has also shipped with MediaWiki since 1.35.
How do you extend MediaWiki? Templates, Lua modules and extensions
MediaWiki can be extended in stages, and each stage needs more technical skill than the last. Templates and Lua modules are written as wiki pages, so once an administrator has enabled Scribunto, neither needs server access.
| Level | Who builds it | What it’s for | Where it lives |
|---|---|---|---|
| Templates | Experienced editors | Reusable boxes, banners, page layouts | Wiki pages in the Template namespace |
| Lua modules | Technical editors or developers | Logic templates can’t handle well: calculations, formatting lists, processing data | Wiki pages in the Module namespace |
| Installed extensions | An administrator with server access | Features others have already built: login systems, forms, search, diagrams | The server’s extensions folder |
| Custom PHP extensions | A developer | Features specific to your organization, such as integration with internal systems | A package of code loaded by the wiki |
Lua modules
The Scribunto extension adds scripting to wiki pages. It has supported one language, Lua, since its release in 2012, and it has shipped with MediaWiki since version 1.34. Lua scripts are stored as pages in a “Module” namespace and called from templates, so they keep the wiki’s page history, and they don’t require server access to write.
Extensions
Extensions add features to MediaWiki itself. MediaWiki.org’s extension catalog lists 1,558 of them. Their quality and maintenance vary, so check that an extension supports your MediaWiki version and has been updated recently before relying on it.
A custom extension is the right home for anything specific to your company. MediaWiki’s hook system calls extension code “at the appropriate point in the main MediaWiki code,” for example on login or when someone saves a page. The extension developer guide also tells developers: “Make sure the extension doesn’t modify the core database tables.” The principle is the same one WordPress follows, covered in Plugin, Theme or functions.php? Where WordPress Code Belongs: custom code goes in a separate package, not in the platform’s own files, so updates don’t wipe it out.
Can MediaWiki restrict pages to certain teams?
Not reliably. MediaWiki can make the whole wiki private, but it was not designed to hide individual pages from people who can log in. This is the question to settle before choosing it: if you need some pages hidden from some staff, MediaWiki is likely the wrong tool.
Manual:Preventing access describes two access modes MediaWiki is designed for:
- Everyone can read every page, as on Wikipedia.
- Visitors who aren’t logged in see only the main page and the login page, and logged-in users can read everything.
The manual is direct about anything in between: “If you intend to have different view permissions than that, MediaWiki is not designed for your usage.” It adds, “Other wiki software may be more suitable for your purpose.”
Extensions that claim to restrict reading by page or namespace exist, such as Lockdown, which sets permissions for each namespace. MediaWiki.org puts the same warning on every extension of this kind:
MediaWiki was not designed to support per-page or partial-page access restrictions. If you require this level of control, you are strongly advised to use a content management system that supports it natively.
It goes on to say such extensions “may not work in all cases, potentially exposing confidential data.”
The reasons are set out on Security issues with authorization extensions, a list of flaws found in these extensions in real use. Wiki content can reach a reader by many routes besides the page itself: one page included inside another as a template, page exports, RSS feeds, search results that list page titles, the API, the page cache, other extensions that query the database, and Lua modules that read a page’s text. A restriction has to block every one of those paths. The page concludes that denying read access should be treated as “a ‘nothing to see here, move along,’ sort of thing rather than a guarantee of secrecy.”
Uploaded files have a separate problem. The web server normally serves them directly, without MediaWiki checking who is asking. The access manual warns that on a login-only wiki, “Uploaded images will still be viewable to anyone who knows the image directory’s name,” unless files are routed through MediaWiki’s image authorization script or protected in the server configuration.
If you must use MediaWiki with mixed audiences, the manual suggests:
- A private wiki with a few public pages. Require login for everything and list the exceptions in
$wgWhitelistRead. - Separate wikis. One wiki per audience, sharing a user database, with links between them. This is the most reliable option because the restricted content is never in the other wiki at all.
- A third-party extension, accepting the warnings above.
Editing restrictions are a different matter. Protecting a page so that only certain groups can edit it is built into MediaWiki. The weakness is specifically in hiding pages from people who can log in.
Where else is MediaWiki a poor fit?
- Approval workflows. Pages change as soon as someone saves them. Review-before-publish needs an extension, and MediaWiki’s documentation lists those among the add-ons for “restrictions not possible in the software proper.”
- Structured records. MediaWiki’s documentation notes that “Wikis primarily focus on text and media” and that managing data takes extensions. A ticket queue, CRM or inventory system belongs in software built for it.
- A wiki nobody tends. The same page lists “Diffusion of responsibility” among the disadvantages of wikis: “A wiki may remain empty or unattended as everyone is expecting others to make the necessary changes.” A knowledge base needs named owners for its main areas, whatever software it runs on.
- Teams with no one to run a server. MediaWiki’s documentation calls wiki software “relatively difficult to administer” compared with blogging software. Hosted MediaWiki services exist, but someone still has to make decisions about extensions, upgrades and access.
What does it take to host and maintain MediaWiki?
Server requirements
According to the installation requirements, MediaWiki needs:
- A web server. Most installations use Apache, and Nginx also works.
- PHP. The current stable version requires at least PHP 8.3.0.
- A database: MariaDB 10.3.0+ or MySQL 5.7.0+, PostgreSQL 10.0+, or SQLite 3.31.0+. The requirements page recommends MariaDB or MySQL “as Wikimedia uses MariaDB.”
- Command line access to the server to run maintenance scripts.
Some features, such as image thumbnails, need PHP to run outside programs, which the requirements page notes cheap shared hosts often disable.
Versions and long-term support
The version lifecycle policy calls for major releases twice a year, security and bug-fix releases each quarter, and a long-term support release every second year. On October 7, 2026:
| Version | Released | Supported until | Status |
|---|---|---|---|
| 1.43 (LTS) | December 21, 2024 | December 2027 | Current long-term support |
| 1.45 | December 4, 2025 | December 2026 | Legacy stable |
| 1.46 | June 30, 2026 | July 2027 | Current stable |
| 1.47 (LTS) | Expected November 2026 | November 2029 | Next long-term support |
For a company wiki, an LTS release is the lower-maintenance choice: three years of security fixes, with a year of overlap to move to the next LTS. Since version 1.36, a wiki can upgrade in one step from either of the previous two LTS versions. Older versions have to upgrade in stages.
Versions past their end-of-life date get no security fixes, and the lifecycle page warns they “may contain critical security vulnerabilities.” A wiki left on an old version for years ends up where many Drupal 7 sites are now, as covered in Drupal 7 End of Life: Migrating to Current Drupal or WordPress.
Updates
Minor releases within a version carry security patches and bug fixes. Major upgrades take more care. The upgrade manual asks you to read the release notes, back up the database and files, unpack the new version into a new folder rather than over the old one, update every extension to a matching version, then run the database update script. Extensions need the most attention. The manual notes that “old extensions aren’t guaranteed to work with a newer version of MediaWiki,” so an extension nobody maintains anymore can hold the whole wiki on an old version. Keeping the extension list short makes every upgrade easier.
MediaWiki’s release manager advises anyone running a wiki to join mediawiki-announce, the mailing list where every release, including each security fix, is announced.
Backups
The backup manual says MediaWiki keeps important data in two places:
- The database: pages, their full history, users, preferences and the search index.
- The file system: configuration (
LocalSettings.php), extensions, skins and uploaded files.
A usable backup needs both. The manual also recommends making an XML dump of the pages alongside the database backup. It contains every page with all its revisions, though not user accounts or logs, and makes a good fallback if a database dump can’t be restored. Test a restore on a spare server at least once, so you know the backups actually work.
Signing in with company accounts
To let staff sign in with the accounts they already use, the PluggableAuth extension works through companion extensions for LDAP, OpenID Connect and SAML. When local login is turned off and a single sign-in method is used, MediaWiki skips its own login page and sends people straight to the company’s sign-in.
Combine that with a login-only wiki and new account sign-ups turned off, and only company accounts can read the wiki. Uploaded files still need the extra protection described above.
Is MediaWiki right for your knowledge base?
| Your situation | Good fit? | Why |
|---|---|---|
| All staff may read everything; the goal is shared, current reference material | Yes | This is how MediaWiki is designed to work |
| A public documentation or community wiki | Yes | The same model Wikipedia uses |
| Lots of repeated, structured page layouts (products, sites, clients, equipment) | Yes | Templates and Lua modules handle it well |
| You need a full record of who changed what and when | Yes | Every revision is kept and can be compared or restored |
| Some pages must be hidden from some staff (HR, legal, finance, client confidential) | No | Per-page read restrictions are not reliable, per MediaWiki’s own documentation |
| Content must be approved before anyone sees it | Only with extensions | Pages publish on save by default |
| No one can maintain a server or decide on upgrades | Weak | Self-hosted MediaWiki needs ongoing administration |
| A handful of people, a few dozen pages | Probably overkill | A shared document folder or a simpler tool may be enough |
If the mixed-audience row applies to only a small, clearly separate set of documents, separate wikis or keeping those documents outside the wiki entirely can work. If it applies across the whole knowledge base, choose a tool built for it.
When does another tool fit better than MediaWiki?
When you need permissions by page or section. Tools built around content-level permissions handle this natively. BookStack, an open-source (MIT-licensed) documentation platform you install on your own server, says “Permissions can be overridden at a Shelf, Book, Chapter or Page level where required.” Confluence Cloud lets teams restrict pages within a space, with one rule: “A content item cannot have greater access than its container.” Its documentation also notes that restricting content isn’t available on its Free plan.
When the docs are mainly public product content. If your documentation lives on your public website, managed by marketing alongside other pages, a CMS may fit better than a wiki. WordPress can also serve content to a separate front end, which Headless WordPress: When It’s Worth It and When It Isn’t covers.
When the readers are developers. Documentation for software can be kept as Markdown files next to the code, reviewed and versioned like the code itself.
Questions to answer before choosing MediaWiki
- Can everyone who logs in read everything? If not, which content is restricted, and can it live in a separate wiki or system?
- Who will run the server, apply quarterly security releases and plan the move to each new LTS?
- Which extensions do you need, and are they maintained for the LTS version you plan to run?
- Will staff sign in with existing company accounts, and does your identity provider support LDAP, OpenID Connect or SAML?
- Is the built-in search enough, or will you run CirrusSearch with Elasticsearch or OpenSearch?
- Who owns each main section of the wiki and keeps it current?
- Where are backups stored, and when was a restore last tested?
If question 1 has a clear “yes” and question 2 has a name next to it, MediaWiki is a strong, free foundation for a company knowledge base.
When to bring in a developer
Start by listing what the knowledge base must hold, who needs to read each part, and which systems it should connect to. That list answers the permissions question, and a developer can use it to plan the setup: hosting, single sign-on, the extensions you need, a backup and upgrade routine, and any templates, Lua modules or custom extensions that fit how your company works.
If you’d like help, see custom app development. The process and pricing are published, and you can get in touch to talk through what your knowledge base needs.
