A wiki engine that stores pages in a database and can mirror them to Git, S3 or disk, with a choice of Markdown, WYSIWYG or AsciiDoc editors. It replaces Confluence and MediaWiki for teams that want per-page permissions and a modern editor.
Our verdict on Wiki.js#
Version 3 has not shipped. As of September 2026 the newest stable release is v2.5.314 from 1 May 2026, and the 3.0 line is still publishing prerelease builds (3.0.0-beta.550 dated 7 September 2026) that are labeled not for production use. The developer preview was announced in October 2022, and the project's own roadmap gates beta on full feature parity with 2.x with no date attached. So what people actually run is 2.x, and what that means practically: 2.x gets maintenance releases a few times a year, roughly six in the last twelve months, mostly dependency and build fixes rather than features. It works, it is stable, and it is not going anywhere new. Version 3 will also drop every database engine except PostgreSQL, so if you are starting today, start on Postgres. Otherwise your eventual migration acquires a second problem on top of an already undefined one.
Who Wiki.js is for#
Choose it if
- Teams that want the Git storage module, so pages exist as Markdown files in a repository as well as in the wiki
- Anyone who needs fine-grained per-page or per-path permissions with OIDC groups
- Documentation sites where multiple editor formats (Markdown, WYSIWYG, AsciiDoc) need to coexist
- Operators who will accept a frozen feature set in exchange for a stable, well-understood 2.x
Look elsewhere if
- You need a project with forward momentum, because 2.x is in maintenance and 3.0 has been in preview since 2022
- You want to mount the wiki at a subfolder like example.com/wiki, which Wiki.js explicitly does not support
- You are on MySQL, MariaDB, MSSQL or SQLite and want a future, since 3.0 drops all of them for PostgreSQL only
What running it actually looks like#
Two containers: requarks/wiki on port 3000 and PostgreSQL, with arm64 built into the same tags since 2.4 so a Raspberry Pi 4 works. Wiki.js requires its own domain or subdomain and cannot live under a path. If you use the PostgreSQL search module, the pg_trgm extension must be available; the official Postgres image includes it, a minimal distro package may not. First run is a browser setup wizard where you create the admin account and pick a locale, and it phones home for update, language and theme checks unless you sideload. Configure authentication, storage and search modules from the admin UI afterwards. Upgrades within 2.x are a tag bump and a restart, and migrations apply on start.
Resource profile#
- Memory
- 260 MB idle, around 500 MB in ordinary use. The docs put the Node process at around 70 MB with short bursts during page rendering and indexing, and state 1 GB minimum on Linux. The rest of the figure is PostgreSQL.
- CPU and acceleration
- Near zero at rest. Bursts come from page rendering, search index rebuilds and the Git storage module running a fetch and commit cycle on a timer.
- Storage growth
- All content lives in the database, including uploaded assets, so the Postgres volume is what grows. Enabling a storage module writes a second copy to disk, Git or a bucket without shrinking the database.
- Operational load
- 3 of 5, Moderate. Two services and a database that holds everything, including assets, so restore is a dump plus a config file. It scores a 3 rather than a 2 because the Git storage module needs occasional attention when it desyncs, and because there is no defined upgrade path off 2.x.
Figures describe a small single-household install and are the working assumptions behind our stack planner. Your numbers will differ with library size, user count and hardware. See methodology.
Data and backup surface#
The documentation states it plainly: all content is stored in the database. Pages, revisions, users, permissions, configuration and uploaded assets are all rows in Postgres, so a pg_dump plus your config.yml is the complete backup and there is no separate uploads tree to chase. Nothing in the container filesystem is worth keeping. If you enable the Git storage module you get a second, human-readable copy of page content as Markdown in a repository, which is worth having as a disaster-proof export, but it does not carry users, permissions or assets, so it is a supplement to the dump and not a replacement.
Derived backup shape
Postgres dump. pg_dump (or pg_dumpall) into a file, then snapshot that file plus the app's data volume.
Traps and surprises#
3.0 has been almost ready since 2022
A developer preview shipped in October 2022 with a beta promised in weeks. Four years later the tags are still prereleases marked not for production, and the roadmap gates beta on feature parity with 2.5.x with no date. Do not plan a deployment around 3.0 landing. Treat the version you install today as the version you will run for years.
Version 3 drops every database except PostgreSQL
Wiki.js 2.x supports PostgreSQL, MySQL 8.0+, MariaDB 10.2.7+, MS SQL Server 2012+ and SQLite 3.9+. Version 3 removes support for all of them except PostgreSQL. If you install on MariaDB now because you already run one, you are choosing a database migration on top of an application migration later. Start on PostgreSQL.
Assets live in the database, not on disk
Every uploaded image and file is stored in Postgres. That makes backup pleasantly simple but means the database grows with your media, dumps get slow, and you cannot point a CDN at an assets directory. On a media-heavy wiki, budget for a database an order of magnitude larger than the page text would suggest.
Git storage sync is bidirectional and will conflict
The Git module can pull external changes back into the wiki as well as push wiki edits out. That is the feature people install it for, and it is also where operational attention goes: a force push, a rebase or an edit to the same page on both sides leaves the module wedged and needing a manual resync from the admin panel. Point it at a repository nobody else rewrites history in.
It will not run under a subpath
The requirements page states Wiki.js needs a dedicated domain or subdomain and cannot be mapped to a subfolder. Every reverse proxy attempt at example.com/wiki ends in broken asset paths and a login loop. Allocate wiki.example.com before you start rather than after.
Specifications#
- Category
- Documents, notes and knowledge
- Licence
- AGPL-3.0 (Copyleft)
- Written in
- JavaScript / Node.js (Vue frontend)
- First release
- 2017
- Maturity
- Slowed
- Datastore
- PostgreSQL 9.5+ recommended (MySQL, MariaDB, MSSQL and SQLite still supported in 2.x)
- Default ports
3000- Ships as
- docker compose, node from source, kubernetes helm
- arm64 builds
- Yes
- Identity
- Native OIDC. Generic OpenID Connect plus a long list of first-party strategies (Azure AD, Google, GitHub, Keycloak, Auth0, LDAP, SAML), all configured in the admin UI rather than in environment variables.
- Replaces
- Confluence, MediaWiki, Notion, GitBook
- Project site
- js.wiki
- Source
- github.com/requarks/wiki
- Documentation
- docs.requarks.io
Alternatives to Wiki.js#
Everything else in documents, notes and knowledge, closest in operational weight first.
| Tool | Ops load | Idle RAM | Licence |
|---|---|---|---|
| Docmost | 3, Moderate | 500 MB | AGPL-3.0 core, proprietary Docmost Enterprise licence for `ee` directories |
| Paperless-ngx | 3, Moderate | 450 MB | GPL-3.0 |
| BookStack | 2, Light | 260 MB | MIT |
| HedgeDoc | 2, Light | 250 MB | AGPL-3.0 |
| Outline | 4, Heavy | 550 MB | BUSL-1.1 (Change Date 2030-09-01, converts to Apache-2.0) |
| Trilium Notes | 2, Light | 200 MB | AGPL-3.0 |
Where Wiki.js comes up elsewhere#
Head to head
Sources#
Facts on this page were checked against the project's own material. Where a number is our own estimate rather than a published figure, the text says so.
Published . Last reviewed . Found something out of date? Tell us and we will fix it and log the change.