How to Self-Host a Private Wiki: MediaWiki vs. BookStack vs. Wiki.js

A self-hosted wiki stores shared notes and documentation on a server you manage. You need to control who can reach the server and what each person can read or change after connecting to keep its pages private. A home network or private server alone does not guarantee that only authorized readers can access the wiki.

Choose MediaWiki when you need extensive configuration and extensions, BookStack when you want a structured documentation interface with visual and Markdown editing, or Wiki.js when you want detailed group permissions and external login options. In every case, set access rules before adding sensitive material, then test those rules and confirm that you can restore a backup.

How the three wikis differ

These are differences in authoring and administration, not guarantees about security or ease of use. The projects’ published hardware and software requirements also do not provide a controlled performance comparison.

MediaWiki gives you room to configure

MediaWiki runs with a web server, PHP, and a database. Its documentation lists PHP as a requirement and supports MariaDB, MySQL, SQLite, and PostgreSQL. The installation documentation recommends MariaDB or MySQL if you are unsure which database to choose. Check the current requirements before selecting a server image or database package.

To make MediaWiki private, configure who can read pages, edit them, and create accounts. Administrators set these permissions by user group in LocalSettings.php. A group is a set of users with shared rights, and MediaWiki’s group grants are cumulative: a user’s rights can come from more than one group. Test what a user can actually do when they belong to multiple groups.

MediaWiki’s access-control documentation warns that its basic private-wiki examples are incomplete and may not cover every access path or extension. After configuring access, test the wiki as a logged-out visitor, a regular user, and an administrator. Also check whether installed extensions expose content through separate pages or features.

MediaWiki suits administrators who want to tailor the wiki or add specialized features. Extensions add flexibility, but administrators need to check each one for compatibility and maintain it during upgrades. VisualEditor, for example, provides rich-content editing and is bundled with MediaWiki 1.35 and later, but administrators still need to enable and configure it. The extension documentation explains the setup and version considerations.

BookStack emphasizes structured documentation

BookStack offers a default visual editor and a Markdown editor, where authors format text using plain-text symbols. Its documentation explains how to organize content and use roles and permissions. The guided interface suits authors who want help structuring documentation. The BookStack documentation index links to its authoring and administration guidance.

BookStack requires PHP 8.2 or newer, MySQL or MariaDB, and a compatible web server. It also requires Composer to manage PHP dependencies and Git to track changes to code. Before installing, compare those requirements with the operating system and packages you plan to use. The installation instructions also warn that their scripts target specified fresh Ubuntu systems and can install or affect server components.

For privacy, review public-access and registration settings, then assign roles deliberately. Test image and attachment access separately: BookStack documents that locally stored attachments follow its authentication and permission checks, while images have different handling. Its security guidance also recommends limiting database and filesystem permissions and serving only the public directory.

Plan to back up BookStack yourself: it has no built-in backup and restore feature. Administrators must back up the database and files. The files include configuration and uploaded images, as well as attachments and themes. Preserve the APP_KEY, which BookStack uses for encryption-related functions, and test a restore before relying on the wiki as the only copy of important documentation. The backup and restore instructions describe the items to preserve.

Wiki.js combines page rules with external login options

Wiki.js runs on Node.js, the software runtime for its server code. Its current setup documentation recommends containers, which package the wiki and its runtime for deployment. The project lists at least 1 GB of RAM and 1 GB of dedicated storage as Linux recommendations; uploaded content requires additional space. Check the requirements and installation instructions for the release you plan to run. The project advises against using the moving latest container tag.

Wiki.js assigns permissions through groups and page rules. A user who belongs to no group has no page access, and a group without a rule for a page also has no access to that page. Rules can control actions such as reading, writing, reviewing, and deleting. Before adding sensitive pages, sign in with accounts in different groups and test which pages they can read, write, review, and delete. The permissions documentation explains the rule options.

For login, Wiki.js supports local accounts and external services, including LDAP and Active Directory directories, OpenID Connect, OAuth 2.0, and SAML. If you place a reverse proxy in front of the wiki, configure trusted forwarded headers and the proxy’s host and protocol settings. A reverse proxy passes requests to the wiki server; incorrect header settings can cause login redirects to use an internal hostname or the wrong connection scheme. See the authentication documentation.

Back up the database before upgrading. Wiki.js warns that a database schema upgrade, which changes the database's structure, cannot simply be rolled back to the earlier version. Verify that you can recover before upgrading. Wiki.js documentation covers different releases. Some older pages recommend a production version that differs from the one in the current installation instructions. Match the setup, upgrade, and backup instructions to the exact release you install. The upgrade guidance covers the database backup warning.

Make privacy and recovery part of the deployment

Decide how readers will reach the wiki before configuring accounts. You might limit access to a local network, require a virtual private network (VPN), or expose the service through a public address protected by a gateway. A login screen controls access inside the wiki; a firewall or VPN controls which network connections reach it. Use HTTPS, which encrypts traffic between the reader’s browser and the server, when readers connect over a network.

Then configure permissions before importing sensitive pages. Disable or restrict self-registration if readers should not create accounts. Create a low-privilege account and test it alongside a logged-out browser session. Check pages, search results, images, attachments, and any enabled extensions or integrations.

Before launch, record the installed wiki version and database version, back up the database and required files, and perform a restore test. The three wikis have different backup instructions, and deploying a wiki in a container does not replace backups. A backup that has never been restored does not confirm that you can recover the wiki.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com