GitBook vs Wiki.js: which to choose

GitBook or Wiki.js: which fits your documentation in Git

Wiki.js fits a docs team that already keeps Markdown in GitHub or GitLab, can run a small server, and needs both the editing workspace and the published pages inside its own network. GitBook fits a team that prefers a hosted service to operating infrastructure and has no residency rule that excludes a vendor-hosted site. A renewal notice or the per-site and per-user fee is a reason to price both options, but it does not settle the choice on its own. Four questions decide it.

The first is who operates the server. Wiki.js needs a dedicated domain or subdomain, because it cannot be mounted under a subfolder, and Linux hosts need at least 1 GB of RAM. The production database is PostgreSQL 9.5 or later, and its search module needs the pg_trgm extension, so someone must own patching, backups and upgrades. The second question is where public docs are served. GitBook hosts published sites for you, while Wiki.js serves its own pages, so you must plan the public domain, TLS certificates and caching for readers outside your network. The third is whether SAML is required. Wiki.js includes a SAML 2.0 module alongside OpenID Connect, LDAP and TOTP two-factor authentication. Ask GitBook which plan includes SAML and what it costs before assuming parity.

The fourth question is which Wiki.js line to run. Wiki.js 2.x is licensed AGPL-3.0, and its stable release is v2.5.316, published on October 2, 2026, in the requarks/wiki-v2 repository (release page). The main requarks/wiki repository holds Wiki.js 3.0, which its README marks as beta and advises against for production. Storage through Git synchronizes both ways, so decide early which side is the source of truth and confirm the 2.x release notes before each upgrade. AGPL also requires you to share modified source when users interact with a modified instance over a network, so have legal review any customization.

Which option fits which scenario

This table maps six common situations to the option that fits better, with the condition that drives each choice. Read each row against your own requirements, and treat the 'Why' column as the test to confirm before you decide. The main takeaway is that Wiki.js fits best when Git-based content and self-hosting matter, provided your team can run it, and that the 3.0 beta is a poor fit for production.

Scenario	Better fit	Why
Public product docs on a custom domain	GitBook, unless you can host Wiki.js on a dedicated domain	GitBook publishes hosted docs sites out of the box. Wiki.js needs its own domain or subdomain and cannot run from a subfolder, and you must provide the server and public access yourself.
Internal engineering docs in a private Git repo	Wiki.js 2.x	Wiki.js Git storage synchronizes content in both directions with the repository, so engineers can keep editing Markdown in Git while readers use the wiki. Confirm the sync behavior with your own repository before relying on it.
Regulated data that must stay in your infrastructure	Wiki.js 2.x	Wiki.js is AGPL-3.0 and runs on Linux, Docker or Kubernetes in your own accounts or data centers, with sideloading for offline environments. GitBook is a hosted service, so confirm where your content would be stored before deciding.
A team with no platform engineers	GitBook, or a managed Wiki.js host	Self-hosting Wiki.js means someone maintains the server, a PostgreSQL or MySQL database, upgrades, backups and TLS. Without that capacity, the hosted service removes operational work, and the trade-off is the recurring fee.
A team that needs SAML on a budget	Wiki.js 2.x	Wiki.js lists SAML 2.0 among its authentication modules with no separate license tier. Check the current GitBook plan terms for SAML, since the GitBook Cost page in this series covers that comparison in detail.
A team that wants the 3.0 features now	GitBook, or wait for a stable Wiki.js 3.0	The main requarks/wiki repository marks Wiki.js 3.0 as beta and not for production use. Use the stable 2.x line, which is v2.5.316 in the requarks/wiki-v2 repository, for production work.

How Wiki.js Git storage keeps Markdown in step with GitHub or GitLab

The key difference for a team moving off GitBook is direction. Wiki.js Git storage synchronizes in both directions: edits pushed to the configured branch of your GitHub or GitLab repository appear on the wiki, and pages changed in the Wiki.js editor are committed back to the repository. The Wiki.js storage documentation lists Git among the modules that work this way, which is the property that matters here. Teams that publish from a repository one way and treat the web as read-only will find that Wiki.js can serve both audiences from one source of truth, but only if the team agrees on which side is authoritative for each page. That agreement is the decision to make before cutover. Engineers who write in their IDE and open pull requests will expect Markdown changes to land cleanly, while content editors who use the web editor will expect their saves to reach the repository without a manual export. Plan a short rule set: which branch is live, whether web edits go straight to that branch or to a review branch, and who resolves a page edited on both sides at once. Conflict handling in this situation is a question to confirm with the current Wiki.js documentation and by testing a concurrent edit in a staging instance, since the behavior when the same page changes in both places is not something this comparison establishes.

The repository structure also needs to be settled early. Wiki.js maps repository paths to page paths, so the folder layout, file naming and any front matter your Markdown carries determine the resulting URLs and navigation. Confirm how the Git module handles subfolders, attachments and images, and whether a deleted file removes the page on the wiki. GitBook Git Sync is one-way from the GitBook site to GitHub or GitLab, and it covers the content of the space rather than site settings or integrations, so the repository it produces is a snapshot you then publish from. Wiki.js has a different scope: it is a storage layer that the wiki reads and writes, so the repository becomes part of the running system. Before you cut over, run a test with a copy of your content and check the rendered pages, links and assets against the GitBook originals.

Markdown and visual editing: what each side gives writers

Content authors are product managers, support staff, technical writers and other contributors who need to publish pages without learning Git. GitBook's visual editor is the managed experience for this group: the vendor maintains the editor, its formatting, and the publishing flow, so authors work inside a single hosted interface. Wiki.js offers a visual editor as well, and it runs on your own servers, so the editor's upkeep, updates and access control sit with your platform team.

Editor choice: Wiki.js provides Markdown and visual editing modes, so authors can pick the one they know. Confirm which editors ship in the version you plan to run.
Publishing path: In GitBook, publishing is handled by the hosted service. In Wiki.js, an author's change reaches the site through the editor and, if Git storage is enabled, reaches the repository too.
Permissions: Wiki.js controls who can create or edit pages through its own group and page rules, so confirm these rules match your current GitBook space permissions.
Upkeep: Your team owns editor updates and plugin issues in the self-hosted case, which is a recurring task.
Non-technical use: This group matters most when contributors rarely touch Git.

Before committing, run a sample export from GitBook and open a few representative pages in Wiki.js to see which GitBook-specific blocks need cleaning.

Why SAML at no extra cost changes the sign-in decision

Sign-in is often the first question a security team asks about a documentation platform, and it is where licensing choices become access decisions. The cards below cover what Wiki.js includes in its authentication layer, how public and private content is separated, and what to confirm about GitBook's SAML terms before comparing costs.

SAML 2.0 is included in Wiki.js

Wiki.js ships a SAML 2.0 authentication module in the base product, so enabling single sign-on does not depend on a higher commercial tier. For an organization that already runs a SAML identity provider, this means the wiki can sit behind the same sign-on, group mapping and session policy as other internal applications. Check that your identity provider can issue the assertions and attributes Wiki.js expects, and test group-to-permission mapping with a non-admin account before rollout.

Choose the module that matches your directory

Wiki.js offers Azure AD, Okta, Keycloak OpenID Connect, LDAP and Active Directory, generic OpenID and OAuth2, GitHub and Google modules. The right choice depends on where your staff accounts already live, not on the wiki itself. Organizations with an on-premises Active Directory often use LDAP or SAML, while cloud-first teams usually use OpenID Connect. Confirm which attributes carry group membership, since that drives who can edit or read each space.

Add TOTP two-factor for local accounts

Wiki.js supports TOTP two-factor authentication. This matters most for local accounts, such as break-glass administrators, service accounts used during an identity provider outage, or contractors who sign in without corporate federation. Decide whether second factors are enforced by the identity provider, by the wiki, or both, and record that decision in the access control documentation so an assessor can trace it.

Public and private docs need separate rules

GitBook's published docs sites and Wiki.js pages both serve readers in different ways, so the sign-in model should be designed per content type. Public documentation can remain anonymous, while internal runbooks, architecture notes and customer-specific material need authenticated access. Map each Git repository or wiki path to an audience before migration, and test that anonymous visitors cannot reach private pages through search, cached copies or attachment URLs.

Confirm GitBook SAML terms by plan

GitBook's SAML support is tied to its plan structure, and its terms can change. Ask GitBook in writing which plan includes SAML, whether SCIM provisioning is included, and how sign-in works for guests and contractors. Compare those answers with the GitBook cost page, which sets out how per-site and per-user fees add up, so the identity requirement is priced alongside the rest of the subscription.

Plan contractor and offboarding access

Contractors and external writers are where identity gaps usually appear. With Wiki.js, access for an outside writer can be scoped to specific paths and removed when the identity provider deactivates the account, provided group sync is configured correctly. Before go-live, list every account type that needs access, document who approves it, and confirm that deprovisioning in the identity provider removes wiki sessions as well as future logins.

Should you run the 2.x stable line or wait for the 3.0 beta

For a production documentation site, the answer today is to run the 2.x stable line. The main requarks/wiki repository holds Wiki.js 3.0, and its README marks that code as beta and not for production use. The stable 2.x line lives in the requarks/wiki-v2 repository, where v2.5.316 was published on October 2, 2026, according to its GitHub releases page. Pin the exact release tag in your deployment manifest, whether that is a Docker image, a Kubernetes manifest or a Node.js install, so an unplanned update never changes the platform under your published docs.

Do not treat 3.0 as a drop-in upgrade. Before you plan anything, read the 3.0 release notes and confirm three things: the upgrade path from 2.x, whether your database engine and version remain supported, and whether the Git storage module, the SAML 2.0 authentication module and your theme or custom code behave the same way. If your GitBook migration depends on Git sync in both directions, confirm that behavior explicitly in the 3.0 documentation rather than assuming it carried over. Ask your DeployOpen or internal platform team to run a staging copy of your content through any 3.0 build you are considering, and record the results against your own test cases.

Plan the 2.x deployment so it can move forward later without a rebuild. Keep your content in the Git repository, which is the source of truth, and keep the Wiki.js database backed up on its own schedule. That way, if you decide to move to 3.0 once it is no longer beta, you are restoring a known configuration rather than re-importing pages. Check the official release notes before each planned upgrade, and do not set a target date for 3.0 based on expectations of when it will ship, since no release date has been confirmed for this page.

Capability comparison from supplied facts

This table compares the documentation capabilities that matter most when docs live in Git, using only researched facts for Wiki.js and plan-dependent checks for GitBook. Read the Wiki.js column as confirmed behavior and the GitBook column as items to verify against your current plan before you decide. The main takeaway is that Wiki.js 2.x covers Git sync, SAML and self-hosted storage, while GitBook's published docs features and plan limits need confirmation in writing.

Capability	GitBook	Wiki.js 2.x
Git sync direction	Bi-directional Git Sync to GitHub or GitLab; confirm sync scope and plan availability with GitBook	Git storage module synchronizes content in both directions
Markdown editing	Confirm Markdown import and export behavior for your spaces with GitBook	Markdown editor supported; content is stored as Markdown in the repository
Visual editing	Block-based visual editor; confirm which blocks round-trip through Git	Visual editor available alongside Markdown; confirm supported blocks for your content
SAML sign-in	Confirm whether SAML is included on your plan or limited to a higher tier	SAML 2.0 authentication module included in the open-source release
Other auth modules	Confirm supported SSO and identity options with GitBook for your plan	Azure AD, GitHub, Google, Keycloak, LDAP and Active Directory, generic OpenID and OAuth2, Okta, plus TOTP two-factor
Public and private docs	Hosted public and private sites; confirm access controls and custom domain options for your plan	Public and private pages supported; public access needs a dedicated domain or subdomain
Storage options	Content hosted by GitBook with Git as the sync target; confirm export options	Git, AWS S3 and DigitalOcean Spaces storage modules; sideloading for offline environments
License	Commercial hosted product; confirm terms in your contract	AGPL-3.0 open source; no license fee
Database support	Not applicable for hosted use; confirm data location and hosting region with GitBook	PostgreSQL 9.5 or later recommended; also MySQL 8.0 or later, MariaDB, MS SQL and SQLite

Where documentation lives and who controls it

Moving from GitBook to Wiki.js changes where pages are stored, who runs the servers and who restores them after a failure. The cards below cover the decisions that follow from that change, and the conditions your own environment has to meet before cutover.

Data location and residency

GitBook stores published and draft content on its hosted service, so your residency position depends on its hosting terms. With Wiki.js, pages sit in the PostgreSQL or MySQL database you run and in the Git repository you own, so the location is whatever your infrastructure provides. Confirm where attachments, search indexes and logs will be stored, since each may land in a different system. Public docs served through a CDN still need a separate residency check.

Hosting models to choose from

Wiki.js runs on any platform that supports Node.js, including Linux, macOS, Windows, Docker and Kubernetes. A single virtual machine suits a small internal wiki, while a container or Kubernetes deployment fits teams that already run those platforms. Environments without internet access can use sideloading for files. Pick the model your operations team can patch and monitor, because that work now falls to you.

Conditions before installation

Wiki.js requires a dedicated domain or subdomain and cannot be mapped to a subfolder of an existing site, so plan DNS and certificates before the build starts. On Linux, the server needs at least 1 GB of RAM. Decide early whether the docs domain stays on its current name, because search engines and existing links depend on it.

Identity and access control

Wiki.js authentication modules include SAML 2.0, OpenID Connect providers such as Keycloak and Okta, LDAP and Active Directory, with TOTP two-factor authentication. Your identity provider then governs who can sign in and who can edit, and removing a leaver stops access at the source. Confirm that group mapping and page permissions match your access review process before users move over.

Backup responsibility

Under GitBook, the vendor operates the service and its backups. With Wiki.js, your team owns database backups, attachment storage backups and restore testing. Schedule backups of the database and the storage backend, and test a full restore on a separate host. Document who runs the restore and how long your organization accepts the wiki being unavailable.

Git repository as a second copy

Wiki.js Git storage synchronizes content in both directions, so the repository holds Markdown that can rebuild the wiki on a new server. Protect that repository with branch rules, access control and its own backups, because a compromised remote can change published content. Keep the repository on infrastructure you control and check that it contains every page before you end the GitBook contract.

What moving from GitBook to Wiki.js involves

The sequence turns a GitBook space into a Wiki.js instance that reads from a Git repository, keeps private and public access under your control, and has a verified cutover of the docs domain. Each step ends with a check you can confirm before moving on.

Confirm the repository is complete
Enable GitBook's Git Sync so every page lands in a GitHub or GitLab repository as Markdown, then compare the repository against the published site. Your team lead or documentation owner does this, and a GitBook admin with the right permissions may need to turn Sync on. Site settings, integrations and some GitBook-only blocks do not sync, so list them by hand now. You know this step is done when every page and asset in the site has a matching file in the repository and the gap list is written down.
Decide the repository layout
Choose how folders, navigation and assets will map to Wiki.js paths before anything is imported. Decide whether the docs live in one repository or several, where images go, and which file holds the navigation order. The platform or documentation lead should write this down and agree it with the content owners. It is done when a short layout document exists and a sample of ten to twenty pages has been placed in the intended structure in a test branch.
Stand up Wiki.js on a dedicated domain
Install Wiki.js 2.x in your own infrastructure on a dedicated domain or subdomain, since Wiki.js cannot be mounted under a subfolder of an existing site. Use PostgreSQL 9.5 or later, which is the recommended database, and enable the pg_trgm extension if you want the PostgreSQL search module. The platform engineer does this work. Confirm the server meets the Linux minimum of 1 GB of RAM and check that Node.js runs on the host or that the Docker or Kubernetes option fits your standards. The step is done when the instance loads over HTTPS and a test search returns results.
Connect Git storage and sync the content
Configure the Git storage module against the repository from step one and run an initial sync. Wiki.js synchronizes content in both directions with this module, so decide which branch is authoritative and who may commit to it before enabling the connection. Check that page paths, titles and attachments arrive as expected, and note any pages that failed to render. The step is done when a sample of pages matches the GitBook originals and the sync log shows no unresolved errors.
Clean GitBook-specific blocks and map navigation
Convert GitBook-only blocks such as hints, tabs, embeds and reusable content into standard Markdown or Wiki.js-compatible syntax, then rebuild the navigation tree from your layout document. The documentation team reviews each converted page, and an engineer scripts repetitive replacements where the pattern is consistent. Effort depends on page count and how heavily the spaces use GitBook blocks, so measure a representative sample before estimating the full job. The step is done when the sample pages render without broken blocks and the navigation matches the agreed structure.
Map redirects for the old URLs
Build a table that maps every published GitBook URL to its new Wiki.js path, then configure redirects at the web server or DNS layer for the pages that people or other sites link to. The platform team owns the redirect rules, and the documentation owner checks the highest-traffic links. Ask GitBook support or your analytics data for the most-visited URLs if you have no list. The step is done when a test crawl of the old URL list returns the expected redirect or the new page for every entry.
Configure SAML or OIDC and test access
Enable the authentication module that matches your identity provider, such as SAML 2.0, Keycloak OpenID Connect, Azure AD, Okta or LDAP, and map groups to Wiki.js permissions. Wiki.js includes SAML 2.0 at no extra license cost, and TOTP two-factor authentication is available. Test private spaces with a user from each permission group, and test public pages from a logged-out browser. The identity team and the documentation owner do this together. The step is done when each group sees exactly the pages it should and public pages load without sign-in.
Cut over the docs domain
Freeze edits in GitBook, run a final Git Sync, repeat the sync check from step one, and then point the public docs domain at the Wiki.js instance. Keep the GitBook site reachable for a period agreed with the business, and confirm that the redirects from step six respond correctly after the DNS change. The platform lead signs off the cutover, and the documentation owner announces it to readers. The step is done when the docs domain serves Wiki.js, the redirect check passes and the repository is recorded as the source of truth.

Questions buyers ask before choosing Wiki.js

How much does switching from GitBook to Wiki.js cost?

Wiki.js itself has no license fee, so the cost is the work and the infrastructure around it. Expect one-time costs for planning, content migration, cleanup of GitBook-specific blocks, configuration, authentication setup and testing, plus recurring costs for servers, a PostgreSQL or MySQL database, backups, a CDN if you publish public docs, and staff time for upgrades. GitBook's own fees are per site and per user, so your saving depends on your seat count and how many sites you run. Ask any implementation partner for a quote built from a written scope that lists the spaces to migrate, the identity providers to connect and the environments to build. Compare that quote with your current GitBook invoices over the same period, including Enterprise-only features you would otherwise need.

How long does a GitBook to Wiki.js migration take?

The timeline is set by scope, not by the tool. The main drivers are how many spaces and pages you have, how much GitBook-specific markup (embeds, custom blocks, variables and integrations) needs manual rework, how many navigation and redirect rules must match existing URLs, how many identity providers you connect, and how many review cycles your content owners require. Your team's familiarity with Git, Docker or Node.js and PostgreSQL also matters. Ask for a timeline in the written scope with milestones for a pilot space, a full content sync, a cutover of the docs domain and a rollback plan. Do not accept a duration that is not tied to a defined inventory of content.

Can our own team run Wiki.js without outside help?

Often yes, if you have people comfortable operating a Node.js application behind a reverse proxy and maintaining a relational database. Wiki.js needs a dedicated domain or subdomain, cannot be mounted under a subfolder, and needs at least 1 GB of RAM on Linux according to the Wiki.js requirements documentation. You will also own backups, TLS certificates, patching, monitoring and the upgrade path. Be aware that the 3.0 line is still beta and not for production, so plan on the stable 2.x line. Estimate the ongoing effort honestly against the people you have, and decide whether a retainer for upgrades and support would cover the gaps.

Does Wiki.js sync with GitBook content directly?

No. Wiki.js does not connect to GitBook as a source. The practical route is to use GitBook's Git Sync to export your content as Markdown into a GitHub or GitLab repository, then connect that repository to Wiki.js through its Git storage module. Wiki.js Git storage synchronizes in both directions, so edits made in Wiki.js can be pushed back to the repository. You will still need to clean GitBook-specific blocks and review how navigation and links map to the new site. Check that the repository is complete before you end the GitBook contract.

Is Wiki.js 2.x safe for production use?

The stable 2.x line is the version intended for production. Its code lives in the requarks/wiki-v2 repository, where the latest release listed in our research is v2.5.316, published on October 2, 2026. The main requarks/wiki repository holds Wiki.js 3.0, which its README marks as beta and not for production use. Check the release notes before every upgrade, confirm your database version meets the requirements (PostgreSQL 9.5 or later is recommended for 2.x), and install the pg_trgm extension if you use the PostgreSQL search module. Confirm the licensing position with your legal team, since Wiki.js is AGPL-3.0 licensed.

When should we hire outside help for a Wiki.js migration?

Consider outside help when the migration touches regulated content, several identity providers, large volumes of attachments, or a docs domain that customers depend on. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. DeployOpen also offers ongoing support and upgrades as retainers. It does not issue audit reports or certifications, so any compliance evidence still goes to your independent auditor. Ask for a written scope that names the spaces, integrations, environments and acceptance criteria before you commit.

When staying with GitBook is the right call

Staying with GitBook is the right call when your documentation team has no capacity to run a server, patch it, back it up and keep a database healthy. Wiki.js is self-hosted software, so every upgrade, TLS certificate, backup job and database maintenance task becomes your responsibility. If nobody on your platform or security team has that time, a hosted publishing service is a reasonable cost, and the per-site and per-user fees buy you that operational burden being carried by someone else. The same applies when public documentation is business-critical and you want a vendor accountable for uptime and content delivery on the docs domain. Before deciding, confirm what your current plan includes in writing, because the fee structure is the main variable and it changes by plan and seat count.

Staying also makes sense when GitBook's Git Sync already covers how your team works. If your writers edit Markdown in GitHub or GitLab, review changes through pull requests and publish from the repository, the Git layer you need is already in place. Wiki.js's Git storage module can also sync in both directions, but adopting it means reproducing your review and publishing flow on the Wiki.js side. Confirm that Git Sync is enabled on your site and that the repository holds everything you need, including the navigation structure, so you know what you would be giving up. The switch rarely pays off when the Git repository is the source of truth and the hosted site is only a rendering layer.

The switch does not pay off in several specific cases. It is weak if your organization has no plan to meet a data residency or exit requirement, since the content already lives in a Git repository you control. It is weak if you need GitBook's managed publishing and analytics features and cannot staff their replacement. It is also weak if the migration cost, which includes cleaning GitBook-specific blocks, mapping redirects and cutting over the docs domain, exceeds the savings in the next renewal period. Before you commit, get a written quote that separates one-time migration work from recurring hosting, database and maintenance effort, and compare the total against the fees on your current contract.

How DeployOpen helps evaluate, implement and migrate Wiki.js

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your own infrastructure. For GitBook vs Wiki.js, we start from how your documentation is kept in Git today, then decide whether Wiki.js 2.x, the stable line, fits your authentication, hosting and public-docs needs.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope lists which GitBook spaces, repositories, public sites and sign-in methods are in or out.
We confirm the Wiki.js version to deploy, choosing between the stable 2.x line and the 3.0 beta for your use case.

How we build

We deploy Wiki.js 2.x in your cloud account, data center or air-gapped network, with a dedicated domain or subdomain.
We configure Git storage to synchronize Markdown with your GitHub or GitLab repository in both directions.
We connect your identity provider, including SAML 2.0 or OpenID Connect, and test public and private page access.

How we hand over

We document the deployment, storage sync settings, backup routines, upgrade steps and access model for your team.
We test restores and the Git round trip so content changes made in either place reach the other as expected.
We deliver a runbook that lists the checks to confirm before ending your GitBook contract.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover Wiki.js version upgrades, including when a stable release or the 3.0 line changes your plan.
Security testing of the deployed wiki can be scoped separately, based on your written requirements.

GitBook vs Wiki.js