Wiki.js 3.0 landed November 1 after four years of development. It is a complete rewrite — new Fastify backend, Vue 3 frontend, Monaco editor engine, real-time collaboration, and a built-in MCP server that lets AI coding agents search, read, and edit your internal documentation. If your team runs Wiki.js 2.x, there is no in-place upgrade path. Here is what changed, what broke, and what your migration checklist looks like.
The Catch: No In-Place Upgrade, and PostgreSQL Only
Before anything else: you cannot upgrade from 2.x to 3.0 in place. Wiki.js 3.0 is a fresh install with a migration import tool — not a standard update. If your 2.x instance runs on MySQL, MariaDB, SQLite, or MS SQL Server, you are facing a double migration. Wiki.js 3.0 drops every database engine except PostgreSQL 17 or later.
The PostgreSQL-only decision is deliberate. Live collaboration requires PostgreSQL’s pub/sub capabilities. High-availability multi-pod deployments (Kubernetes) already mandated PostgreSQL in 2.x anyway. The team decided that supporting five database engines while adding features like real-time co-editing was an unsustainable drag. This is the right call, but it creates real work for self-hosters who chose SQLite or MySQL for simplicity.
One more removal to note: GraphQL is gone. The 2.x GraphQL API is entirely replaced by a REST API documented at /_api per the OpenAPI spec. If you built custom integrations or tooling against the GraphQL endpoint, those will break and need rewriting.
What Is Actually New
Once past the migration friction, 3.0 delivers a substantially better editing experience. The Markdown and AsciiDoc editors now run on Monaco — the same engine powering VS Code. You get a mini-map, multi-cursor editing, smarter autocomplete, and consistent syntax highlighting. The Visual editor is rebuilt from scratch and stores content as Markdown under the hood, so you are not locked into a proprietary format.
Live collaboration is the other headline feature. Multiple people can edit the same page simultaneously, Google Docs-style. Edits appear in real time, the history is continuous rather than version-snapshot-based, and readers can join to watch a document take shape before it publishes. This works across the Markdown, Visual, and AsciiDoc editors — Feedback Boards and the new Blog page type are the exceptions.
Multi-site is now first-class. A single Wiki.js instance can serve multiple independent wikis — each with its own hostname, theme, storage backend, authentication setup, and editor configuration. Users and groups are shared across the instance. This matters for teams that need separate internal and external wikis without running two servers.
New page types include Drawing (a real-time collaborative Excalidraw whiteboard), Feedback Boards (idea submission and upvoting built into your wiki), Live Notes (a scratchpad-style collaborative Markdown editor), and Blog. The platform also ships 25-plus built-in content blocks — folder listings, diagrams, PDF viewers, page includes, infoboxes — that work in any editor. Developers can build custom blocks.
The MCP Server: AI Agents Can Now Edit Your Docs
Wiki.js 3.0 is the first open-source wiki to ship a built-in Model Context Protocol server at /_mcp. It is off by default. Once enabled under Administration Area > MCP, AI assistants — Claude Code, Claude Desktop, VS Code, Cursor, the claude.ai and ChatGPT connectors — can search your wiki, read pages and comments, and, if you grant write access, edit pages directly.
Every AI-assisted edit is marked with an AI badge in the page history alongside the author’s name. The wiki itself runs no model; it does not summarize, embed, or rewrite anything. It just exposes the MCP interface and lets your AI tools operate on the documentation the same way a human editor would.
This has real implications for teams already using AI coding agents. Your internal architecture docs, runbooks, and onboarding guides become directly accessible to agents in your development flow — they can look up an API spec, verify a service name, or update a runbook without leaving the tool. No copy-pasting from a browser tab.
Migration Checklist
The official upgrade documentation is straightforward. Here is the condensed version:
- Upgrade your current 2.x instance to the latest 2.x release.
- In the 2.x admin panel: Utilities > Export for Wiki.js 3.x > Download package.
- Stand up a fresh Wiki.js 3.x instance (Node.js 26, PostgreSQL 17 required).
- In the 3.x admin panel: Utilities > Import from Wiki.js 2.x > Upload package.
- Manually reconfigure authentication, storage, analytics, and comments — these settings do not transfer automatically.
Your 2.x wiki keeps running during the entire process. There is no downtime window imposed by the migration itself.
Docker Compose Quickstart
To run Wiki.js 3.0 locally or in a fresh environment:
version: '3'
services:
wiki:
image: ghcr.io/requarks/wiki:3
environment:
DB_TYPE: postgres
DB_HOST: db
DB_PORT: 5432
DB_USER: wikijs
DB_PASS: wikijsrocks
DB_NAME: wiki
ports:
- "3000:3000"
depends_on:
- db
db:
image: postgres:17
environment:
POSTGRES_DB: wiki
POSTGRES_PASSWORD: wikijsrocks
POSTGRES_USER: wikijs
volumes:
- postgres-data:/var/lib/postgresql/data
volumes:
postgres-data:Should You Migrate Now?
If your team actively uses Wiki.js and your 2.x instance runs on PostgreSQL, migrate. The editor upgrade alone — Monaco plus live collaboration — closes the gap with Notion and Confluence on the features most teams actually use daily. The MCP server is a genuine advantage no competing open-source wiki offers.
If you run MySQL or SQLite, budget time for the database migration first. The double migration is manageable but not trivial, especially for instances with custom integrations against the GraphQL API. Wait for 3.0.x patch releases to stabilize before migrating production.
The official release notes and the community migration guide both have the detail you need. The GitHub repository (29k stars) is active and issue responses have been fast since launch.
