Wiki.js

Last reviewed Aug 26, 2026 · 803 words

The Wiki.js you can install today is version 2, and version 3 has been "in progress" for years. Judge the 2.x line on its own terms: a PostgreSQL-backed wiki with 3 editors, a couple of dozen login providers, path-based permissions and Git sync that turns every page into a Markdown file in a repository you control. That last feature is the reason I still recommend it for a team knowledge base, and the rewrite status is the reason I would not plan around anything that is not shipped in the release you install.

Postgres is the only database worth choosing

Version 2 technically runs on MySQL, MariaDB, SQLite and MSSQL too. Choose PostgreSQL anyway: it is what the developer tests, it is the only engine the built-in full-text search backend supports, and it is the only engine version 3 will support at all. The install is 2 containers:

services:
  wiki:
    image: ghcr.io/requarks/wiki:2
    environment:
      DB_TYPE: postgres
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: wiki
      DB_PASS: change-me
      DB_NAME: wiki
    ports:
      - "3000:3000"
    depends_on: [db]
  db:
    image: postgres:16
    environment:
      POSTGRES_USER: wiki
      POSTGRES_PASSWORD: change-me
      POSTGRES_DB: wiki
    volumes:
      - ./db:/var/lib/postgresql/data

Open port 3000, and the setup wizard asks for an admin account and the site URL. Set the URL to the final HTTPS address behind your reverse proxy from the start; several auth callbacks and the sitemap are derived from it. Memory sits around 300 to 500 MB in normal use, in line with the 512 MB guidance.

Git sync is the backup that is also an export

Under Administration, Storage, enable the Git target with a repository URL, a branch and either an SSH key or a token. Every 5 minutes by default, Wiki.js commits changed pages as Markdown or HTML files with a small front-matter block, and in bidirectional mode it pulls edits made in the repository back into the site. Three consequences follow. Your backup is a git repository with full history, readable without Wiki.js installed. Your export problem is solved before it starts, since the pages are already plain files. And writers who prefer an editor can commit Markdown and watch it appear. Keep the nightly Postgres dump as well, because users, groups, permissions and comments live only in the database.

SSO in, local registration off

The authentication list is the longest of any self-hosted wiki: generic OIDC and SAML, LDAP, Keycloak, Authentik, GitHub, Google, Microsoft and a dozen more. Groups map to page rules by path, so /internal/* can be read-only for the staff group and hidden from everyone else, which is how you get Confluence-style spaces out of a flat path model. Turn off self-registration on the local provider, keep exactly one local admin account as the break-glass login for the day the identity provider is down, and test that account before you need it.

The things 2.x does badly

The page model is a path, not a tree. Moving a section means renaming paths and fixing links; there is no drag-and-drop hierarchy and no page templates. Search is weak until you switch the engine from the basic database option to the PostgreSQL full-text one, which is a single dropdown most people never find. The visual editor struggles with very long pages, and there is no real-time collaborative editing, so two people saving the same page compete. Version 3 promises to fix several of these, and I have stopped promising anyone a date.

BookStack, Outline and Docmost cover the other shapes

BookStack gives you a fixed shelf, book, chapter, page hierarchy, which is exactly what teams who miss Confluence spaces want, and its permissions are simpler to reason about; it is the safer choice for a non-technical team. Outline is the Notion-shaped option with real-time collaboration and a slash-command editor, and it needs an SSO provider from day one. Docmost is the newer, lighter take on the same idea. Wiki.js beats all three when the writers are technical, the content should live in git, and you want the widest choice of editors and auth providers. The Confluence alternatives page runs through the migration path from that direction.

What I'd do

Deploy the 2-container compose above behind Caddy, enable Git sync to a private repository on your own forge on day one, switch search to the PostgreSQL engine, and wire up your identity provider with one local admin held back. Treat version 3 as a pleasant surprise if it arrives, not a roadmap item, and if the team turns out to want a folder tree more than a git history, move to BookStack before there are 500 pages to move.