Find your fit
Who it is for
It fits a team that wants its own documentation hub and is prepared to run a server and database. Writers who prefer plain text can use Markdown, while other contributors can use the visual editor; an administrator can organize who may see and edit the wiki.
It is also relevant when a team needs public instructions beside private working material. Before importing sensitive content, test guest access and group rules against representative pages; a public/private mix depends on configuration.
The work it supports
Core capabilities
Create documentation in Markdown with live preview, toolbar and keyboard shortcuts, or use the visual WYSIWYG editor for contributors who prefer formatting without markup. The main site also lists direct HTML editing for existing preformatted material.
Page history tracks changes and lets an editor return to an earlier state or recover deleted content. Comparing two versions helps a maintainer see what changed before restoring; verify the result on a disposable page when planning a migration or recovery procedure.
Organize media in the asset manager and inspect where files are used. The main site lists a built-in search engine, so readers can find documentation without relying only on navigation links.
A wiki can carry alternate language versions of pages and right-to-left content. If localization is central to the project, pilot one page in each required language and check navigation and search before a broad translation effort.
Assign users to groups, then apply permissions and page rules to control access. Rules can target exact paths, path patterns or regular expressions, so test both a permitted and a denied reader account before sharing confidential pages.
Authentication modules include built-in account handling and integrations such as LDAP, SAML and OpenID Connect. Choose and test the sign-in method that matches your organization before enabling broad access.
Storage modules can synchronize or back up wiki content to Git, cloud storage or local/network destinations. Treat the module choice as part of a recovery plan and verify a sample restore; the site describes these as configurable options.
The separately labeled Wiki.js 3.0 beta site describes proposed edits awaiting approval and an audit trail. These beta behaviors should be evaluated in a beta pilot rather than assumed in a production 2.x installation.
Understand the offer
Pricing and getting started
Wiki.js is free and open source under the AGPL-v3 license. A self-hosted deployment still needs an operated server, database, backups and maintenance; confirm those costs and responsibilities for your environment.
The main site lists PostgreSQL, MySQL, MariaDB, MS SQL Server and SQLite as compatible databases. Its version selector labels 2.x Stable and 3.0 Beta, while 3.x installation instructions use beta image tags. Select the version first, then follow that version's requirements instead of mixing setup instructions.
Look a little closer
Before you choose
Build a small wiki before migrating a large library: write one Markdown page and one visual page, add an asset, revise a page, compare versions and restore it, then find it through search. This checks the authoring and retrieval path with the intended version.
Use separate guest, contributor and administrator test accounts to check private pages, path rules and sign-in options. Back up to one chosen destination and perform a sample restore before relying on the wiki for operational knowledge.
Keep Wiki.js 3.x beta evaluation separate from a stable 2.x production rollout. The vendor's 3.x documentation and beta site describe newer behavior, but the beta label means version-specific capabilities and installation requirements need a fresh check before adoption.
3 distinct sources behind this profile. Research observed Oct 18, 2026. Features and offers can change.
View sources and research →
