Self-hosted wikis in 2026: revisit BookStack, Wiki.js and Outline before you write another runbook in a shared drive

Ask any support engineer in a growing Indian company where the runbook for a failed nightly job lives, and you will usually get three answers. There is a Word file in a shared drive, last edited by somebody who left two years ago. There is a page in an old Confluence Server that nobody dares to upgrade. And there is the real answer: “Ask Suresh, he knows.” Then Suresh goes on leave during a production issue, and the whole team learns how much knowledge was sitting in one head and one chat history.

This post is written for the week after that incident. A team wiki looks like a set of web pages, but underneath it is a database, a file store for images and attachments, an editor that decides the format of your content, a search index, a permission model, sign-in through your identity provider, and an upgrade path that you will follow for years. The software decides how many of those parts you own. It does not decide whether people actually write things down and keep them current. That part is yours.

We revisit three self-hosted options in 2026: BookStack (a PHP and Laravel application on MySQL or MariaDB, organised as shelves, books, chapters and pages), Wiki.js (a Node.js wiki that has just released a complete rewrite as version 3, on PostgreSQL only) and Outline (a Node.js and React knowledge base on PostgreSQL and Redis, with real-time collaborative editing, released under the Business Source License). The aim is not to pick a winner but to see what each asks of you over five years: in editing, structure, sign-in, backups, upgrades and licence terms.

There is real news this autumn. Wiki.js 3.0.1, the first stable release of the 3.x line, came out on 1 November 2026, after a long beta. It is a rewrite of both backend and frontend, needs Node.js 26 and PostgreSQL 17 or 18, and cannot be upgraded in place from 2.x; there is a migration package instead. The 2.x line has moved to its own repository, where 2.5.317 was published on 23 October 2026. BookStack released v26.09 on 24 September 2026 with user-customisable interface layouts, followed by v26.09.1 and a security release, v26.09.2, on 20 October; earlier in the year, on 30 April 2026, the project finished moving its repositories from GitHub to Codeberg. Outline released 1.11.0 on 12 October and 1.12.0 on 23 October 2026, the latter adding a private personal section for every user and moving its Docker image to a Node.js release with security fixes.

This post stays with internal team documentation: runbooks, how-to guides, onboarding notes, design decisions and customer procedures. For the pieces around it, see Keycloak and its alternatives for single sign-on, reverse proxies in 2026 for the front door, and backups in 2026 for the copy you will need on a bad day. If your documentation already lives next to code in Git, self-hosted Git forges is the better starting point.

A scenario to keep us honest

We will use one invented company through the post. Godavari Ghat Software Services is an invented example, not a real business: a Nashik company that builds and runs an ERP and traceability product for grape exporters, onion traders and cold storage operators in Maharashtra and Karnataka. The company has about 140 people. About 45 are engineers and testers, about 25 are in a customer support desk that handles calls and tickets in English, Marathi and Hindi, about 15 are implementation consultants who travel to customer sites, and the rest are in sales, accounts and HR. Infrastructure is a small team of three, led by Rohini, with production on a cloud provider and internal tools on two Proxmox hosts in the office.

What they use today:

  • An old Confluence Server, which reached the end of Atlassian support in February 2024. It still runs on a VM, holds about 1,800 pages, and nobody wants to touch it.
  • Word and PDF files in Google Drive for support procedures, each copied and edited by whoever needed it, so there are four versions of “how to reset a cold storage gate controller”.
  • README files and a few Markdown folders in the GitLab repositories, which engineers keep current, more or less.
  • Company mail and accounts on Google Workspace, and a Keycloak instance that the engineering team set up last year for internal tools.

What triggered the review: a large exporter customer asked, as part of an ISO 27001 supplier review, for documented and version-controlled operating procedures for incident handling and data restore. In the same quarter, a night-shift support engineer spent two hours on a cold storage sync failure that had a three-line fix written in a chat message eight months earlier. A senior engineer suggested Wiki.js “because it syncs to Git”. The support head asked for “something like Word, but in one place, where I can find things”.

Rohini’s questions: which wiki, how will support staff who do not know Markdown write in it, how will engineers keep docs close to code, how do we sign in with Google or Keycloak and remove leavers, how do we move 1,800 Confluence pages, and can three of us own it for five years?

The short version

  • Decide structure, ownership and review rules before software. A wiki makes it easier to write. If nobody owns a section or reviews old pages, it makes it easier to write things that go stale.
  • BookStack is the most settled and the simplest to explain: shelves, books, chapters and pages, a WYSIWYG editor by default with a Markdown editor as an option, roles with per-item permissions, LDAP, SAML 2.0 and OpenID Connect with group sync, under the MIT licence. It runs on PHP with MySQL or MariaDB. Feature releases come every two to four months, with frequent patch and security releases.
  • Wiki.js 3 is the most ambitious: Markdown, visual and AsciiDoc editors, live collaboration, content blocks, approvals and lifecycle rules, multi-site, SCIM, high availability with several replicas, and Git sync, under AGPL-3.0. It is also brand new as a stable release, needs PostgreSQL 17 or later and Node.js 26, and moving from 2.x is a migration, not an upgrade.
  • Outline is the most polished for fast, collaborative writing: real-time editing, collections, groups, an API and an MCP server for AI tools. It needs PostgreSQL, Redis and an external sign-in method, because it has no built-in email and password login. Its licence is BSL 1.1, not open source: internal use is allowed, offering it as a document service to others is not, and each version converts to Apache 2.0 four years after release.
  • For Godavari Ghat, our plan is: agree a structure and page owners first, then pilot BookStack v26.09 with the support desk and the infrastructure team, with sign-in through Keycloak over OpenID Connect and group sync, nightly database and file backups and one tested restore. Move Confluence content in batches, starting with the 200 most viewed pages. Keep engineering design notes in Git. Put Outline on a two-week side test with ten engineers if they push for real-time editing, and test Wiki.js 3 in early 2027 after a few point releases, mainly for its Git sync and approvals.

Where things stand on 2 November 2026

BookStack

  • Current releases: v26.09.2 on 20 October 2026 is a security release. It fixed comments of pages in the recycle bin staying visible to API users, and attachment changes being allowed on draft pages for people with attachment permissions. It also drops remember-me cookies when a user changes their password. Before that came v26.09.1 on 29 September and the v26.09 feature release on 24 September 2026.
  • What is new in v26.09: user-controlled interface layouts, with a drag and drop editor to move or hide sidebar and home page sections, layout blocks in the theme system, a scroll progress indicator, API endpoints to search within a book or chapter, a changelog field for page create and update through the API, and API docs downloadable as JSON or HTML. The upgrade notice: an APP_KEY value must now be set, as there is no fallback default.
  • Release rhythm: versions are named by year and month. Feature releases in the last eighteen months were v25.05, v25.07, v25.11, v25.12, v26.03, v26.05 and v26.09, each followed by several patch releases. v26.05 had five patch releases, v26.05.1 to v26.05.5, between June and September 2026.
  • Project home: the BookStack blog announced on 30 April 2026 that all repositories had moved from GitHub to Codeberg. v26.05 was the first feature release managed there. The GitHub repository remains with a note that it is now managed on Codeberg.
  • Requirements: PHP 8.2 or later with listed extensions, MySQL 8.0 or later or MariaDB 10.6 or later, Git and Composer for install and updates, and a PHP-capable web server. Install scripts are provided for Ubuntu 22.04, 24.04 and 26.04, and there is an official guide for subdirectory setups. Shared PHP hosting is not supported.
  • Licence: MIT.

Wiki.js

  • Current releases: 3.0.1 on 1 November 2026 is the first stable release of 3.x, after a long series of betas; the last beta, 3.0.0-beta.705, was published on 26 October. The 3.0.1 notes add drag and drop moves in the file manager, a “require signed response” option for SAML, an image editor, inline content blocks and a set of fixes, including some page-level permissions that were being handled as global permissions and a change so that users cannot tell whether a path exists if they lack access.
  • What 3.0 is: the project’s release post describes a complete rewrite of backend and frontend. Highlights are a Markdown editor built on Monaco, a new visual editor that stores Markdown underneath, an AsciiDoc editor, drawing, feedback board, blog and live notes page types, live collaboration in most editors, over 25 built-in content blocks, a file manager with a recycle bin, approval and lifecycle rules, comments and annotations, and multi-site, where one instance serves several wiki sites with shared users and groups.
  • Requirements for 3.x: PostgreSQL 17 or 18 with the ltree and pg_trgm extensions, Node.js 26 (earlier versions will not work), at least 1 GB of RAM on Linux, two or more cores recommended for background workers, and a dedicated domain or subdomain; subfolder installs are not supported. Docker is recommended, and the image is about 850 MB.
  • The 2.x line: 2.x releases moved to a separate repository, requarks/wiki-v2. 2.5.315 on 21 September 2026 was the last 2.x release in the main repository and fixed two security advisories. 2.5.316 on 2 October added the “Export for Wiki.js 3.x” tool, and 2.5.317 on 23 October rebuilt the image with Node.js security updates. The 2.x requirements page supports Node.js 22 and 24 and several databases, and warns that only PostgreSQL is supported from 3.x. We did not find a published end-of-support date for 2.x.
  • Licence: AGPL-3.0, for both lines.

Outline

  • Current releases: 1.12.0 on 23 October 2026, which adds a personal section for private documents for every user (admins can turn it off), rebuilt sidebar drag and drop, faster Mermaid diagrams, passkey sign-in in the desktop app, and MCP improvements. The release note asks operators to update soon, because the Docker image moves to Node.js 26.12.1 with fixes for several disclosed vulnerabilities. 1.11.0 on 12 October added block drag handles, reasons for archiving or deleting, and Open Knowledge Format import.
  • Release rhythm: 1.0.0 came on 26 October 2025. In 2026, minor releases have arrived roughly every one to two months: 1.7.0 in April, 1.8.0 in June, 1.9.0 in July, 1.10.0 on 2 September, 1.11.0 and 1.12.0 in October. The Docker hosting guide describes a monthly image cadence.
  • Requirements: a Unix-like system (Windows Server is not supported), PostgreSQL 14 or later, Redis 4 or later, at least 512 MB of memory with 1 GB or more recommended, a dedicated domain or subdomain, and a compatible authentication provider. Docker is the recommended and supported install method.
  • Licence: Business Source License 1.1, with details in the licences section below. Business and Enterprise editions are paid and add features such as SAML, a security audit log and a Confluence importer.

The first questions to ask

  1. Who will write, and in what? Support staff and managers often prefer a Word-like editor. Engineers often prefer Markdown and Git. Most companies have both groups.
  2. How should content be organised? A fixed hierarchy of books and chapters, a tree of paths and folders, or collections with nested documents. This shapes how people find things more than search does.
  3. Who can read and who can edit each area? Write the first version of the permission model on one page: groups, areas and who approves changes.
  4. How do people sign in, and how do leavers lose access? Local accounts, LDAP, OpenID Connect or SAML, and whether groups come from the identity provider.
  5. What are you moving in? Pages from Confluence, Word files, Markdown in repositories. Count them, and decide what to leave behind.
  6. Does any content need to live in Git? If yes, decide whether Git is the source of truth or a copy.
  7. Will anyone outside the company read it? Public help pages change licence, hostname and security decisions.
  8. Who owns it in year three? Upgrades, backups, restore tests, search, broken links and stale pages.

How each one works

A team wiki in one minute

A wiki stores pages, usually as HTML or Markdown in a database, with revision history for each page. Images and attachments go to disk or object storage. Around this core sit an editor, a structure for navigation, search, permissions, sign-in, export and an API. The choices that matter most for the long run are the content format, because it decides how easily you can leave, and the permission model, because it decides how easily you can make mistakes.

BookStack: shelves, books, chapters and pages

BookStack is a Laravel application written in PHP. It runs behind Apache or nginx with PHP-FPM and stores nearly everything in one MySQL or MariaDB database. Its content storage page says it is primarily database-driven, that page content is kept as relatively simple HTML, and that Markdown content follows CommonMark where the Markdown editor is used. The project says it has pushed back on many editor and format feature requests to keep content portable. Uploaded images and attachments live in folders on disk, or in S3-compatible storage if configured.

The structure is fixed and easy to teach: shelves hold books, books hold chapters and pages, and chapters hold pages. There is no deeper nesting. For many teams this is a strength, because it stops the endless folder trees that make shared drives hard to use. For some it is a limit.

Wiki.js 3: a rewritten Node.js wiki on PostgreSQL

Wiki.js 3 runs as a Node.js process, built on Fastify in the 3.0.1 package, with PostgreSQL as its only database. It uses PostgreSQL for search too, through trigram matching with pg_trgm, and the ltree extension for paths. Page content lives in the database, and assets can go to the database, local disk, S3-compatible storage, Azure Blob or Google Cloud Storage. Background workers handle rendering, search index rebuilds, webhooks and maintenance.

Several instances can connect to the same database for high availability; the admin pages list them and say replicas are kept in sync. Pages are organised by path within a site, with folders, a navigation menu and a file manager. One instance can host several sites, each with its own hostname, theme, storage, login options and editors, while users and groups are shared.

Outline: collections, documents and real-time collaboration

Outline is a Node.js server with a React front end. PostgreSQL stores documents, collections, users and history; Redis is used for caching, queues and, in larger setups, synchronising the collaboration server; files go to local disk or S3-compatible storage. Its hosting guide says plainly that Outline is engineered as a horizontally scalable cloud platform and needs DevOps experience to run in production.

Content is organised into collections, which hold nested documents. Every document is edited live by several people at once through a websocket-based collaboration service. The guide says a single collaboration process is fine for teams under about 1,000 active users, depending on resources, and that larger or redundant setups need a Redis URL for collaboration so several processes stay in step. The api, worker and web processes scale horizontally.

Editing and structure

BookStack

  • Editors: the default is a WYSIWYG editor that works like a word processor, with shortcuts for headings, callouts, code blocks and links to other BookStack content. A Markdown editor can be set as the default or chosen per page by people with the “change page editor” permission. Switching a page from WYSIWYG to Markdown offers “clean” or “stable” conversion, and BookStack warns about possible formatting loss.
  • A new editor in progress: the v26.09 notes list fixes and improvements to the “new WYSIWYG editor”. Treat it as work in progress and test it before relying on it.
  • Other features: page templates, page revisions with changelog messages, tags, draw.io diagrams, attachments, content reuse through includes, and comments, which use a WYSIWYG editor.
  • Export and import: books, chapters and pages export to a contained HTML file, PDF, plain text, Markdown and a portable ZIP with data, attachments and images that another BookStack instance can import. The docs say these are not a backup method.

Wiki.js 3

  • Editors: a Markdown editor built on Monaco, the editor engine of Visual Studio Code, an AsciiDoc editor, and a new visual editor that stores Markdown behind the scenes. Most editors support live collaboration with visible cursors.
  • Page types and blocks: drawings with Excalidraw, feedback boards, blog posts and live notes, plus more than 25 content blocks for things like folder listings, diagrams, maps, galleries, PDF viewers and including another page.
  • Workflow: approval rules let some groups, even guests, suggest edits that another group reviews. Lifecycle rules can, for example, show a stale banner on pages not updated for three months and notify page owners. Pages have a Talk tab for comments and annotations on specific passages.
  • Moving from 2.x: the upgrade guide lists Markdown changes. Admonitions should use the GitHub-style [!WARNING] syntax, Mermaid, PlantUML, Kroki and KaTeX diagrams must be wrapped in content blocks, draw.io diagrams must be exported from 2.x as XML and pasted into a new block, inline maths needs both dollar signs and backticks, and old tabsets show as plain text until converted. Budget time for this.

Outline

  • Editor: one rich editor that accepts Markdown shortcuts as you type, with slash commands, tables, code blocks, Mermaid diagrams, embeds, mentions and [[ to link or create a document. Recent releases added split view, numbered headings, drag handles on blocks and inline comments by read-only users.
  • Structure: collections with nested documents, templates, stars, a personal section from 1.12.0, and public sharing of documents if allowed.
  • Import and export: the hosting docs mention exports in HTML, Markdown or JSON from settings, and an API endpoint that scripts can call. Recent releases added imports from web pages, email, PDF and Open Knowledge Format. The Confluence importer is listed as a paid Business and Enterprise feature.
  • AI tools: Outline ships an MCP server, so tools that support the Model Context Protocol can work with your documents after an OAuth sign-in. Wiki.js 3 also added an MCP server in its late betas. Decide whether you want this on, and for whom, before AI tools start writing into your runbooks.

What to decide

Ask five support staff and five engineers to write the same runbook in each tool, with a screenshot, a table of steps and a code block. Then export it to Markdown and HTML and look at what comes out. That one hour tells you more than any feature list.

Security and accounts

Exposure

An internal wiki does not need to face the internet. Put it behind a reverse proxy with TLS, keep it on the office network or a VPN where you can, and if it must be public for consultants on customer sites, enforce single sign-on with two-factor at the identity provider. Our mesh VPNs post covers the access side.

Two specific notes. The Wiki.js 3 sample configuration listens on all interfaces (bindIP: 0.0.0.0) by default, and the container docs say the first admin account uses a well-known default password unless you set one. Set ADMIN_EMAIL and ADMIN_PASS, or change them at first login, and bind to localhost behind the proxy. For BookStack, the project posted a warning on 21 October 2026 about a critical PHP security release, with fixes in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you run BookStack, your PHP packages are part of your patch duty, not only BookStack itself.

Sign-in and leavers

  • BookStack supports local accounts with multi-factor authentication, LDAP, SAML 2.0, OpenID Connect and social logins such as Google. LDAP, SAML and OpenID Connect can sync groups to BookStack roles; for OpenID Connect you name the claim that holds group names, and BookStack matches them to role names or “external authentication IDs”. BookStack has used PKCE in OpenID Connect sign-in since v24.02, and supports RP-initiated logout if enabled. Note the September 2026 security release v26.05.5, which fixed a social login account mix-up when more than one social login option had been used.
  • Wiki.js 3 offers local accounts and strategies for LDAP and Active Directory, OpenID Connect or OAuth2, SAML 2.0, Google, Microsoft Entra ID, GitHub and Discord. Older 2.x strategies such as Keycloak, Okta and GitLab are covered through the generic OpenID Connect strategy. Each strategy must also be enabled per site. Wiki.js 3 is SCIM 2.0 compliant, so an identity provider can create and deactivate accounts. Passkeys and two-factor authentication appear in the audit log reference, and the local strategy has an “enforce two-factor” option, off by default.
  • Outline does not support email and password sign-in natively. The community edition supports Google, Microsoft Entra, Slack, OpenID Connect, Discord, GitLab, passkeys and email magic links, which need SMTP. SAML is only in the paid editions. With OpenID Connect discovery, three settings are enough to start: issuer URL, client ID and client secret.

Leaver handling is where wikis fail audits. Test what happens to a departing person’s account, drafts, private documents and API tokens.

Permissions

  • BookStack: users get roles, roles have system permissions and default “asset permissions” for content, and permissions can be overridden on a shelf, book, chapter or page. Many asset permissions have an “own” option, so people can edit only what they created. It is easy to understand and easy to audit.
  • Wiki.js 3: permissions belong to groups. A user in no group can do nothing, and a group with no page rules can do nothing. Page rules allow, deny or force-allow actions on paths that match a pattern, optionally per site and locale, with actions such as read, write, review, delete, view history, manage assets and write comments. The docs warn that the “use JavaScript” permission lets users inject scripts into pages. Give it to nobody you do not fully trust.
  • Outline: workspace-level roles, collections with member and group access, private collections, and document-level sharing. It suits teams where most people can read most things and some collections are private.

Audit trail

  • BookStack has an audit log of user actions in settings, which v26.09.1 updated to use the configured display timezone.
  • Wiki.js 3 records user-initiated events with filters and NDJSON export. Retention defaults to 90 days and cannot be set below 30 days. It does not store page content or setting values, only the action and context.
  • Outline lists a security audit log as a paid feature in the hosting docs.

Safety of content

All three render user content in the browser, so cross-site scripting matters. BookStack filters scripts by default and documents ALLOW_CONTENT_SCRIPTS as an opt-in for trusted environments only. Wiki.js 3 controls styles and scripts through permissions. In every case, keep the default filters on, and keep up with security releases, which all three projects publish.

Performance and how to read benchmarks

What the projects publish

There is no recent independent benchmark that compares these three on the same hardware, and we did not find one we could trust. What the projects publish is their own:

  • Outline describes recent work in its release notes as a focus on server and client performance and, in its own words, calls itself the fastest team knowledge base on the market. That is the vendor’s claim. The notes list specific changes, such as fewer queries per route and less content loaded in lists, but not before and after figures. The 1.10.0 notes say server memory use was reduced and container memory best practices documented.
  • Wiki.js gives sizing guidance rather than benchmarks: one core works, two or more are recommended, and at least 1 GB of RAM on Linux. Its 2.x docs said the process usually sits around 70 MB of RAM with short bursts during rendering and indexing; that figure is for 2.x, not 3.x.
  • BookStack does not publish hardware minimums in its requirements, and most of its performance depends on PHP-FPM, OPcache, the database and the cache driver, which its docs cover under caching and sessions.

What slows each one down in practice

  • BookStack: too few PHP-FPM workers, no OPcache, the file cache on slow disk instead of Redis or Memcached for larger teams, very large pages with many images, and PDF export of large books.
  • Wiki.js 3: an undersized PostgreSQL, search on a very large wiki without tuning, and many content blocks on one page. Live collaboration needs websocket support through the proxy.
  • Outline: Redis or PostgreSQL on slow disks, a proxy that breaks websockets, and many people editing one very large document.

What to measure yourself

Import 200 real pages, with images, and measure: time to open a long runbook from a phone on mobile data, search for an error message that appears in three pages, time to save a large page, and memory and CPU on the server during an import. Repeat with 20 people editing at once if live collaboration matters to you. Those numbers decide more than any vendor claim.

Licences and editions

BookStack: MIT, one edition

BookStack is MIT-licensed, and there is one edition with all features. The project offers paid support plans. BookStack is a registered trade mark of its creator, which matters only if you plan to rebrand and redistribute it.

Wiki.js: AGPL-3.0, one edition

Wiki.js is AGPL-3.0 for both 2.x and 3.x, with all features in the open source code and funding through sponsors and donations. The AGPL matters if you modify Wiki.js and let people use the modified version over a network: you must offer them the source of your changes. For an internal wiki you run as is, it changes little.

Outline: BSL 1.1 with a change date

Outline switched from a BSD-style licence to the Business Source License 1.1 in March 2020. The licence file for 1.12.0 says:

  • The licensor is General Outline, Inc.
  • The Additional Use Grant lets you use Outline in production, as long as you do not use it for a “Document Service”: a commercial offering that lets third parties, other than your employees and contractors, access Outline’s functionality by creating teams and documents controlled by those third parties.
  • The Change Date for 1.12.0 is 23 October 2030, and the Change License is Apache 2.0. The BSL text says the change happens on the change date or on the fourth anniversary of the first public release of that version, whichever comes first, and that each version has its own change date.
  • The licence states clearly that it is not an open source licence.
  • The hosting docs add that selling, reselling or hosting Outline as a service breaches the terms and automatically ends your rights under the licence.

For Godavari Ghat, an internal wiki for staff and contractors is within the grant. Hosting a documentation portal where customers create their own spaces would not be. If your company is a managed service provider, read the terms with your legal team before you build anything on Outline.

The paid Business and Enterprise editions use a separate Docker image with a licence key and add SAML, a security audit log, structured data attributes and a Confluence importer, according to the hosting docs.

Operations and day two

Sizing and hosting

  • BookStack for about 140 users: 2 vCPU and 4 GB of RAM is a comfortable start with PHP-FPM, the web server and MariaDB on the same VM. Add disk for uploads. The Ubuntu install scripts set up the full stack on a fresh server, and Docker images are maintained by the community, including LinuxServer.io.
  • Wiki.js 3: the documented minimum is 1 GB of RAM with two cores recommended, plus PostgreSQL 17 or 18. For our size, 2 vCPU and 4 GB for Wiki.js and a separate or co-located PostgreSQL with its own memory budget is a reasonable start. The container image is about 850 MB. It needs outbound access to api.github.com, github.com and api.iconify.design for update checks, locales and icons, plus whatever your sign-in and storage modules call.
  • Outline: the documented minimum is 512 MB, with 1 GB or more recommended, plus PostgreSQL and Redis. For our size, 2 vCPU and 4 GB for the Outline container, Redis and PostgreSQL together is a reasonable start, with a separate volume for file storage. The default upload limit in the docs is 25 MB per file.

All three sizes above are our starting points, not vendor figures. Measure during the pilot.

Backups

  • BookStack: dump the database with mysqldump, and copy .env, public/uploads (images), storage/uploads (attachments) and themes. After a restore, run php artisan migrate. The .env file holds APP_KEY, which you need.
  • Wiki.js 3: back up the PostgreSQL database with pg_dump, your config.yml or container environment, and any assets stored on local disk. If you use Git sync, the repository is a useful second copy of pages, but the docs do not present it as a full backup.
  • Outline: the backup page recommends daily PostgreSQL backups at a minimum, kept for a month, and a backup or snapshot before every upgrade, because releases run automatic migrations that are not always backwards compatible. Back up the environment file too. Losing SECRET_KEY makes all encrypted data in the database inaccessible. File storage must be backed up separately.

In all three, revision history is not a backup. It helps when someone deletes a paragraph. It does not help when the database disk fails. Copy dumps and files to a separate system with its own credentials, and test a restore every quarter. Our PostgreSQL backups post goes deeper for the two PostgreSQL-based tools.

Upgrades

  • BookStack: back up, then run git pull origin release, composer install --no-dev and php artisan migrate, and clear caches. A beta option downloads PHP dependencies in one file from a BookStack domain instead of through Composer. Read the upgrade notices for each feature release, such as the APP_KEY requirement in v26.09. Keep PHP itself patched.
  • Wiki.js 3: in-place upgrades within 3.x by pulling a new image (tags follow major, minor and patch; there is no latest tag in 3.x) or replacing the application folder. The docs say you cannot go back to an earlier version once the schema has been upgraded. From 2.x, upgrade to the latest 2.x, create a .wkbackup package with the export tool, install a fresh 3.x and import it. The import is safe to repeat. Module settings such as storage and authentication, security settings, the site logo and the hostname are deliberately not imported, so plan to set them again.
  • Outline: pin the image version, back up PostgreSQL, then move to the new image; migrations run at boot. With releases every one to two months, plan a monthly upgrade window, and read release notes for breaking changes.

Background work

  • BookStack: needs little scheduled work of its own. Set up mail early for password resets and notifications, and check webhooks if you use them.
  • Wiki.js 3: background workers and a scheduler are built in; the admin area shows scheduled jobs. Plan a history purge policy using the purge history utility, because page versions and audit logs grow over time.
  • Outline: schedule calls to the cron.daily and cron.hourly endpoints with the UTILS_SECRET token. Without them, cleanup of temporary files, trash removal and email reminders will not run.

Side by side

Architecture

  • BookStack: PHP and Laravel, MySQL or MariaDB, files on disk or S3-compatible storage.
  • Wiki.js 3: Node.js 26, PostgreSQL 17 or 18 only, assets in database, disk or object storage, optional Git sync.
  • Outline: Node.js and React, PostgreSQL and Redis, files on disk or S3-compatible storage.

Structure

  • BookStack: shelves, books, chapters, pages. Fixed depth.
  • Wiki.js 3: sites, paths and folders, navigation menus.
  • Outline: collections with nested documents, plus personal documents.

Editors

  • BookStack: WYSIWYG by default, Markdown as an option per page.
  • Wiki.js 3: Markdown, visual (stores Markdown) and AsciiDoc, with live collaboration.
  • Outline: one rich editor with Markdown shortcuts and real-time collaboration.

Sign-in

  • BookStack: local with MFA, LDAP, SAML 2.0, OpenID Connect, social logins; group sync.
  • Wiki.js 3: local, LDAP, OpenID Connect, SAML 2.0, Google, Entra ID, GitHub, Discord; SCIM 2.0.
  • Outline: no local passwords; Google, Entra, Slack, OpenID Connect, Discord, GitLab, passkeys, magic links; SAML paid.

Git

  • BookStack: no Git sync; export and API instead.
  • Wiki.js 3: Git storage module with sync, push-only or pull-only modes.
  • Outline: no Git sync; GitHub and GitLab integrations for links and issues.

Licence

  • BookStack: MIT.
  • Wiki.js: AGPL-3.0.
  • Outline: BSL 1.1, internal use allowed, each version becomes Apache 2.0 after four years.

Maturity of the current line

  • BookStack: steady, many years of the same model, frequent small releases.
  • Wiki.js 3: stable since 1 November 2026, a full rewrite.
  • Outline: past 1.0 since October 2025, fast-moving.

A worked plan for Nashik

Month 1: structure and owners before software

  • Agree a first structure: one shelf each for Support, Infrastructure, Product and Implementation; inside Support, one book per customer segment (exporters, traders, cold storage), with chapters per module. Name an owner for every book.
  • Write a one-page page standard: title format, a “last reviewed” line, owner, and a rule that every runbook has “symptoms”, “checks”, “fix” and “escalation” sections.
  • Count what will move: export a list of Confluence pages with view counts, and the support Word files. Mark the 200 most viewed or most recently edited pages. Plan to leave the rest in a read-only archive.
  • Decide sign-in: Keycloak over OpenID Connect, with a groups claim that maps to BookStack roles, so leavers lose access when their Google account is disabled and synced. Test with three accounts.

Month 2: BookStack pilot

  • One VM on the Proxmox host: 2 vCPU, 4 GB of RAM, 40 GB system disk and a separate 50 GB data disk, Ubuntu 24.04, BookStack v26.09.x with the official install script. Only reachable on the office network and over the VPN; TLS through the existing reverse proxy.
  • Pilot users: the 25 support staff and the infrastructure team. Support writes in the WYSIWYG editor; infrastructure may use Markdown per page.
  • Roles: “Support Writers” can create and edit in Support; “Readers” can read everything except HR and Security books; only infrastructure can edit the Security book.
  • Backups: nightly mysqldump and a copy of .env, uploads and themes to the NAS, plus a weekly offsite copy with restic. PHP patch checks added to the monthly patch list.

Month 3: measure and decide

  • Run the measurements from the performance section with real pages, including search for five common error messages.
  • Restore the pilot to a scratch VM from last night’s backup and open three books.
  • Ask the support head and five engineers one question: would you go back to the shared drive? If yes, find out why.
  • If engineers want real-time editing for design notes, run Outline for two weeks with ten engineers on a scratch VM with Keycloak OpenID Connect, then compare. Note the BSL terms in the decision record.

Month 4 onwards: own it

  • Move Confluence pages in batches by department, fixing formatting as you go, and make Confluence read-only after each batch. Keep the old VM for six months, then archive an export.
  • Monthly: upgrade BookStack to the latest patch release, check PHP, and review the audit log for role changes.
  • Quarterly: a restore test, and a “stale page” review where each owner checks pages not edited for six months.
  • Keep engineering design notes and API docs in Git next to code. Link to them from BookStack rather than copying them.
  • In early 2027, after a few 3.0.x point releases, try Wiki.js 3 on a test VM with its Git storage in pull-only mode against one repository, to see whether it could publish engineering docs from Git.

When not to adopt each

Do not adopt BookStack if

  • Your content does not fit a fixed hierarchy of shelves, books and chapters, and people will fight it.
  • You need Git as the source of truth for pages.
  • Nobody will own PHP patching, which, as October 2026 showed, can be urgent.

Do not adopt Wiki.js 3 if

  • You need a long, quiet stable record today; 3.x became stable on 1 November 2026.
  • You cannot run PostgreSQL 17 or later and Node.js 26, or you need a subfolder install on an existing hostname.
  • You have a large 2.x wiki full of draw.io diagrams, tabsets and custom Markdown, and no time to convert them.

Do not adopt Outline if

  • You need email and password sign-in without an identity provider or SMTP.
  • You plan to offer it to customers or other companies as a service, or your legal team requires an OSI-approved licence.
  • You need SAML or an audit log and will not pay for a licence.

Do not self-host a wiki at all if

  • You have no one who can own backups, restores and upgrades for five years.
  • Your company already pays for a hosted tool that meets your audit needs, and the real problem is that nobody owns the content. A new tool will not fix that.

Why not Confluence, Notion or a docs-as-code site

Confluence Server reached the end of Atlassian support in February 2024, so self-hosting Confluence now means Data Center, with its own licence costs, or moving to Atlassian’s cloud. If your company already lives in Jira Cloud and is happy with it, Confluence Cloud may be the simplest choice. Notion and similar hosted tools are pleasant to write in, but they are hosted only, so data location, export quality and leaver handling depend on the vendor and your plan. A docs-as-code site, such as Markdown in Git built by a static site generator, is excellent for engineering and API docs, because review happens in merge requests and history lives with code. It is a poor fit for a support desk that wants to fix a runbook in two minutes without a merge request. Many companies end up with two homes: a wiki for operations and support, and Git for engineering docs, with links between them.

A short history

BookStack began in 2015, created by Dan Brown, and has kept the same book-based model since then, with releases named by year and month. In April 2026 it moved its repositories from GitHub to Codeberg.

Wiki.js started in 2016 under Nicolas Giard. The 2.x line became the widely used version for several years, with Git sync and many databases. Work on 3.0 ran for a long time as a full rewrite; it reached its first stable release, 3.0.1, on 1 November 2026, with PostgreSQL as the only database and 2.x moved to its own repository.

Outline started in 2016 and was first released as open source under a BSD-style licence. In March 2020 it moved to the Business Source License 1.1. It reached 1.0.0 in October 2025, after many years of 0.x releases, and is developed by General Outline, Inc., which also sells a hosted version.

Decision guide

You want a simple, structured wiki that support staff will actually use

Choose BookStack, and keep PHP and BookStack patched.

You want Git sync, approvals and several wiki sites from one install

Evaluate Wiki.js 3 now and plan production after a few point releases. If you run 2.x today, practise the migration on a copy.

You want fast, collaborative writing for a team that already uses SSO

Choose Outline, read the BSL terms once with your legal team, and decide early whether you need the paid edition for SAML or audit logs.

Your docs are mostly for engineers and live next to code

Keep them in Git with a static site, and link from the wiki for everyone else.

Checklist

  • Structure agreed, with an owner for every top-level area.
  • Page standard written: title, owner, last reviewed, required sections.
  • Sign-in chosen, group mapping tested, leaver process tested.
  • Permission model written on one page and checked in the tool.
  • Migration list: what moves, what stays archived, who checks formatting.
  • Backups in the documented form, one copy offsite, one restore tested.
  • Background jobs, cron endpoints or workers scheduled and monitored.
  • Upgrade path written: current version, next version, date, and for BookStack, PHP version.
  • Release feeds and security advisories followed by two people.
  • Exit plan: which export format you would use to leave.

Common mistakes

  • Copying every old page across. Move the pages people use and archive the rest.
  • No owners. A page without an owner is a page that will be wrong in a year.
  • Leaving the default admin password. Set it at install time.
  • Treating revision history as backup. It does not survive a lost database.
  • Giving everyone script or style permissions. It is an easy path to cross-site scripting.
  • Upgrading without a database backup. All three run schema migrations that cannot be undone.
  • Ignoring the licence. Outline’s BSL is fine for internal use, but it is not open source, and that matters to some customers and auditors.
  • Expecting Git sync to solve review. Git sync copies content; it does not decide who approves changes.

A small hands-on check

We ran a small, static check on our box on 2 November 2026, around 6:23 AM IST, in a scratch folder only. We did not run any of the three servers. BookStack needs PHP and MySQL or MariaDB, Outline needs PostgreSQL and Redis, and Wiki.js 3 needs PostgreSQL 17 or later and Node.js 26; none of those were available on the box at the required versions, and we did not install system packages. What we did was download the Wiki.js 3.0.1 release package from GitHub and inspect it. What we saw:

  • The package was about 62 MB compressed and its SHA-256 matched the digest published with the GitHub release asset. It unpacked to about 375 MB, of which about 297 MB was the backend’s bundled node_modules. The upgrade docs say the package already includes amd64 dependencies and that arm64 needs a rebuild.
  • The backend package.json declared version 3.0.1, licence AGPL-3.0, and an engine requirement of Node.js 26 or later. Our box had Node.js 20, so it would not have run, which matches the requirements page.
  • The sample config.yml says PostgreSQL 17 or later is required and sets bindIP: 0.0.0.0, with a comment to leave it for all interfaces. Behind a reverse proxy, change it to listen only on localhost.
  • The authentication modules folder held eight strategies: local, LDAP, OpenID Connect, SAML, Google, Entra, GitHub and Discord, matching the docs. The local strategy’s “enforce two-factor authentication” setting defaults to off.
  • The storage modules folder held seven targets: database, local disk, Git, S3, Azure Blob, Google Cloud Storage and SFTP. SFTP is described as a copy target that cannot serve content.
  • The Git module offers three sync directions. “Sync” pulls then pushes; “push only” force-pushes the wiki’s commits so the wiki always wins; “pull only” makes the remote the authority. It supports SSH keys without a passphrase or basic authentication with a token, and has an option to commit every change as a default author so user names and emails do not reach the repository. If the repository URL is left empty, it keeps a local repository that needs a persistent volume and a single instance.

The point is not speed. Even without starting a server, the package shows the defaults that matter: what it listens on, who can sign in, and which way Git sync overwrites. It is easier to learn them on a scratch folder than in production.

Unlearn, re-learn

  • Unlearn “a wiki is a place to dump documents”. Re-learn that it is a structure with owners, review dates and permissions, and the software only holds it.
  • Unlearn “Git sync means our docs are reviewed”. Re-learn that sync direction, conflicts and approval are separate decisions.
  • Unlearn “source available means open source”. Re-learn to read the licence parameters: use grant, change date and change licence.
  • Practise: take one real runbook, write it in two tools with an owner and a “last reviewed” date, export it to Markdown and HTML, restore it from backup, and see which version your night-shift engineer finds first.

Sources

BookStack

Wiki.js

Outline

comments powered by Disqus

Releted Posts

Workflow automation in 2026: revisit n8n, Node-RED and Activepieces before you wire another business process to a webhook

Most teams first meet workflow automation as a shortcut: draw a few boxes, point a webhook at a SaaS, and declare the process automated.

Read more

Static code analysis in 2026: revisit Semgrep, Opengrep and SonarQube Community Build before you add another code scanner to CI

Most teams add a code scanner to CI in an afternoon. A YAML job, a default rule pack, a green tick.

Read more

Configuration management in 2026: revisit Ansible, Salt and Puppet before you write another server setup script

Almost every team has one: a setup.sh or bootstrap.sh written for the first production server and grown every year since. It installs packages, edits configuration files with sed, creates users and starts services.

Read more