Which should you choose: GitBook or BookStack for your documentation?
Choose GitBook if your documentation is written by developers in Git and must be published as a docs site. Choose BookStack if the main job is internal knowledge that people edit in a browser and that must stay on your own servers. The deciding factor is whether Git workflow and public docs sites are hard requirements. If they are, GitBook's Git Sync and published sites fit the work, and a self-hosted BookStack would leave you to build that publishing path yourself. If they are not, the case for BookStack grows quickly when renewal pricing, per-user fees or data residency are on the table.
BookStack suits internal knowledge that teams maintain in a browser. Its shelves, books, chapters and pages give a clear hierarchy for handbooks, runbooks and onboarding material. The WYSIWYG editor has an optional Markdown mode and built-in diagrams.net diagrams, so people who do not write Git can still produce structured content. Sign-in can use SAML2, OIDC or LDAP, multi-factor authentication can be enforced per role, and the MIT license removes a software license fee from the cost model. Before committing, confirm that your identity provider and role model map onto BookStack's permission system, and check the PHP 8.2 and MySQL 8.0 or MariaDB 10.6 requirements against your server standards, since the project does not publish official Docker images.
GitBook fits when developers write Markdown in pull requests, when the docs must be a published site, and when the content already lives in GitHub or GitLab. Before deciding, ask these questions: Do engineers need to review documentation changes the way they review code? Must external readers reach a public docs site on your domain? Does the Git repository need to be the source of truth? Will your team accept running a server, applying PHP upgrades and managing backups? Which sign-in options does your current GitBook plan include, and which need an upgrade? If the answers favor Git and publishing, keep GitBook or plan a Git-based migration. If they favor browser editing and internal access, BookStack is the stronger candidate.
Which scenario favors which tool
This table maps common documentation scenarios to the tool that fits better, with the condition that decides it. Read it against your own content types and publishing needs, since the right choice often depends on whether docs must be published to a public domain or written in Git.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Internal policies and onboarding wiki | BookStack | Staff need shelves, books and pages with a WYSIWYG editor, and sign-in through your existing SAML, OIDC or LDAP directory |
| Product docs published on a public domain | GitBook (or confirm another publishing tool) | You need a hosted public docs site with your own domain; BookStack's published-site capability should be confirmed with the vendor before you rely on it |
| Docs written by engineers in Git pull requests | GitBook or a Git-native wiki | Your authors work in branches and reviews; BookStack has no native Git workflow, so you would need an export pipeline |
| Multi-team knowledge with per-role permissions | BookStack | You need a full role and permission system and MFA enforced per role, applied across shelves and books |
| Strict data residency on your own servers | BookStack | Content, user records and sign-in must stay on infrastructure you control, and your team can run PHP 8.2 with MySQL or MariaDB |
| Small platform team wanting minimal moving parts | GitBook | Your team cannot staff a self-hosted PHP and database stack, and the cost of a hosted service is preferable to ongoing server upkeep |
How BookStack organizes knowledge differently from GitBook
The central difference is where the source of truth lives. In BookStack, content is authored inside the web application, organized as shelves that group books, books that contain chapters and pages. Editors work in the WYSIWYG editor or, if enabled, the optional Markdown editor, and can insert diagrams from the built-in diagrams.net integration. Nothing is required to sit in a Git repository. In GitBook, the space is treated as a docs site whose content can be synced to GitHub or GitLab through Git Sync, so the repository is the place where content is versioned and changed. Before you plan a move, confirm with your team which of these two models matches how documents are actually written today.
That difference changes the review process. A GitBook team that works through Git Sync usually gets pull-request review, diff history and branch-based drafting for free, because the repository already handles them. A BookStack team gets page revision history inside the application, but it does not get automatic pull-request review of content unless it builds that process. If review is a requirement for policy, product or compliance documents, decide early whether reviewers will use BookStack's own page workflow, an approval step in a separate tool, or a Markdown repository kept alongside BookStack. Each choice has a different owner and a different set of controls to document, so ask whoever signs off on documentation how approvals must be evidenced.
Publishing is the other gap to plan for. GitBook's docs-site model gives you a published documentation site as part of the product, while BookStack is primarily an internal knowledge base with role-based access, and its public or external publishing depends on how your team configures permissions and where it hosts the instance. If you rely on a public docs domain, test how the BookStack instance will serve those pages, who can see them, and what happens to existing links before you cut over. Ask the implementation partner to write down that publishing path as part of the scope, so the migration does not stall on the docs domain.
Capabilities side by side: GitBook and BookStack
This table compares GitBook and BookStack on the capabilities that matter when internal and product documentation moves off a hosted service. Treat the GitBook column as a checklist to confirm against GitBook's current plan documentation, since plan features change. The main takeaway is that BookStack covers wiki structure, editing and sign-in well, while the Git-backed docs workflow is the gap to plan for.
| Capability | GitBook | BookStack |
|---|---|---|
| Content structure | Spaces with a page navigation tree; confirm current hierarchy options in GitBook's documentation. | Shelves group books, books hold chapters, and chapters and pages hold content. |
| Editors | Visual editor with Markdown-backed content through Git Sync; confirm current editor options for your plan. | WYSIWYG editor, optional Markdown editor and built-in diagrams.net diagrams. |
| Git sync | Bi-directional Git Sync with GitHub or GitLab, available on every plan. | Not a built-in feature; a Git workflow needs a separate import or scripted step. |
| Published docs sites | Hosted published docs sites; confirm access, domain and visibility options for your plan. | Guest access through permissions, but not a static docs-site generator. Test public and custom-domain needs. |
| Sign-in (SAML, OIDC, LDAP) | SAML is reported as Enterprise-only; confirm OIDC and LDAP options in GitBook's plan documentation. | SAML2, OIDC and LDAP sign-in on the free MIT release. |
| MFA and role-based permissions | Confirm MFA enforcement and role options for your plan with GitBook. | Built-in MFA that can be enforced per role, plus a full role and permission system. |
| License and hosting | Proprietary vendor-hosted service, priced per site plus per user. | MIT licensed and self-hosted on your servers; latest v26.09.1 released September 29, 2026. |
| Install requirements | Nothing to install; the vendor runs the service. | PHP 8.2 or later, MySQL 8.0 or MariaDB 10.6 or later, official installers for Ubuntu 22.04, 24.04 and 26.04. |
| Docker images | Not applicable. | No official Docker images; community setups such as LinuxServer.io are available. |
Where your documentation lives and who controls access
Moving from GitBook to BookStack changes where pages, attachments and user records live, and who is responsible for keeping them available and provable. The cards below cover the decisions that follow from that shift, from hosting model and identity to backups and public exposure. Each one has a check you can run before the contract ends.
Data location and ownership
BookStack stores pages, attachments, images and user records in the database and file store you provision, whether that is a single VM, a container host or a private cloud account. GitBook content currently sits in GitBook's hosted service, so the residency question moves to your side of the fence. Confirm which region and which network zone will hold the MySQL or MariaDB database and the uploads directory, and who in your organization holds administrative access to both.
Hosting model options
BookStack ships official installation scripts for Ubuntu 22.04, 24.04 and 26.04, which suits a single VM run by your platform team. BookStack does not publish official Docker images, so a container deployment depends on community images such as LinuxServer.io, which your team would need to vet, pin and patch. Air-gapped networks are workable because the application is self-contained, but you must mirror the PHP, Composer and OS packages yourself. Decide the model before you size the server.
Identity integration with existing SSO
BookStack supports OIDC, SAML2 and LDAP sign-in, so staff can keep their current directory credentials instead of a separate wiki password. This matters because GitBook gates SAML behind its Enterprise tier, while BookStack's sign-in options are part of the MIT release. Test group-to-role mapping with your IdP before cutover, because a misconfigured claim can leave editors without access or grant admins to the wrong people. Confirm MFA enforcement by role in your identity provider and in BookStack.
Roles, permissions and shelf scope
BookStack's role and permission system controls access at the shelf, book, chapter and page level, which lets you separate internal engineering runbooks from company-wide policy. Map GitBook's space and member settings to these roles on paper first, since default permissions can be broader than they look. Review who can export, edit and manage users, because those rights are the ones auditors and incident responders ask about first.
Public versus internal access
GitBook publishes docs sites with their own domain and visibility settings. BookStack is designed around authenticated internal use, so a public docs site is a separate decision that you must engineer, such as a reverse proxy with an unauthenticated route or a static export from another tool. Inventory every GitBook space that is public today, decide which ones must remain reachable, and confirm the publication path before you change DNS for the docs domain.
Backup, audit evidence and responsibility
With GitBook, the vendor operates the platform and its backups, while with BookStack your team owns database dumps, uploads, restore tests and the retention period for each. Audit evidence such as access reviews, change logs and backup restore records also becomes your responsibility to collect and keep. DeployOpen can help prepare these controls and the evidence trail, but independent auditors and certification bodies issue any audit report or attestation. Ask your auditor which evidence they expect before you finalize the design.
What the MIT license means for a BookStack deployment
BookStack is released under the MIT license, so the software itself carries no per-user or per-site license fee. Your cost is the infrastructure to run it, the people who operate it, and any support you choose to buy. The BookStack project site states that paid support plans and sponsorship are available, and the community release is what most self-hosting organizations run. Before you rely on that, have your legal or procurement team read the license text in the repository and confirm that your use, including any internal modifications or redistribution to contractors, fits its terms.
This is where the comparison with GitBook becomes concrete. GitBook charges per site and per user, so its bill grows as you add editors and publish more documentation sites. With BookStack, adding users does not change the license line, but it does change your server sizing, your identity provider load and the number of people you need to administer roles. Ask GitBook for a written quote based on your actual site count, seat count and the tier that includes SAML, and build a parallel estimate for BookStack using the same headcount and the hosting, backup and maintenance costs in your own environment. Compare the two totals over the same period, not the sticker price of one.
Check the releases page before you plan an upgrade. At the time of writing, the latest release is v26.09.1, published on September 29, 2026, following v26.09 on September 24, 2026. Release notes and the changelog are where you will find database migration steps, PHP version changes and security fixes that affect your schedule. Confirm the current version on the BookStack releases page on the day you plan, and treat any version number in internal planning documents as a snapshot that may already be out of date.
What drives the total cost of each option
Self-hosted BookStack has no license fee, so its cost sits in infrastructure, database, identity setup, backups and people. GitBook's cost is a subscription that scales with sites and users, plus the internal effort to keep docs flowing. The cards below show who is paid for what, what recurs, and what to ask for before comparing the two totals.
GitBook subscription fees
GitBook charges per site plus per user, and SAML sign-in is limited to its Enterprise tier. Ask for the per-site and per-user fee in writing for your site count and seat count, the billing period, and whether the quote includes SAML. Check how seat changes are prorated, since contractors and read-only reviewers often inflate the user count. This is the one recurring line item that grows with headcount.
BookStack license cost
BookStack is MIT licensed, so there is no license fee to pay for running it. Costs that remain are the optional paid support plans from the BookStack project, which are not required to run the software. Ask any implementation partner to state separately which work is included in a fixed-scope quote and which is a retainer, so the free license is not confused with a free operation.
Server and cloud compute
BookStack runs on PHP 8.2 or later, so you pay for one or more application hosts in your own cloud account, data center or private network. Size them for expected concurrent editors and attachment volume, and confirm with your team whether you need a staging copy for upgrades. Compute is recurring, and it rises with users, uploads and the number of environments you keep.
MySQL or MariaDB and backup storage
BookStack requires MySQL 8.0 or MariaDB 10.6 or later, so the database is a managed or self-run service you must license or staff. Backups of the database and the uploaded files need separate storage, retention and restore testing. Ask your provider whether database backups, point-in-time recovery and cross-region copies are included or billed by volume.
SSO, MFA and identity setup
BookStack supports OIDC, SAML2 and LDAP sign-in and enforces multi-factor authentication per role, which replaces a per-seat SAML tier. The cost is one-time configuration against your identity provider, role mapping and testing, plus recurring review when groups change. Ask for the scope of identity work, the test plan, and whether the quote covers handover documentation.
Public docs delivery and CDN
GitBook publishes docs sites as part of the subscription. If your product documentation is public, a self-hosted BookStack needs a content delivery network, a public hostname, TLS certificates and caching rules, all of which are recurring. Confirm expected traffic patterns with your team and ask providers whether CDN usage is billed by bandwidth or by request.
How a move from GitBook to BookStack proceeds
The sequence moves GitBook content, users and access into a self-hosted BookStack instance in an order that keeps the source intact until the new wiki has been checked. It ends with the GitBook site retired only after the published docs domain has its own cutover plan.
Inventory spaces, users and published sites
List every GitBook space, its owner, its editors and readers, and any site that is published on a custom domain. Separate internal documentation from public docs, because they follow different cutover paths. Record which spaces use integrations, embedded content or GitBook-only blocks, since these need decisions before import. Confirm the list with the content owners. The inventory is done when every space has a named owner and a target decision: move, archive or retire.
Export all content to Git as Markdown
Enable Git Sync on the GitBook spaces in scope and let the content land in a GitHub or GitLab repository as Markdown. Check the repository against the space page by page, including images and attachments, because Git Sync does not carry every site setting or integration. The full export procedure is covered in our guide on how to export your content from GitBook. The step is complete when the repository holds every page you inventoried and a second person has spot-checked it.
Map GitBook structure to shelves, books and chapters
Decide how GitBook spaces become BookStack shelves, books and chapters. A space usually maps to a book, and groups of related spaces can sit on a shelf. GitBook sections and nested pages map to chapters and pages, so review the navigation tree before importing. Record every URL that will change so redirects can be planned later. The output is a written mapping document that the content owners have approved.
Import content and clean GitBook-specific blocks
Bring the Markdown into a test BookStack instance and import it book by book. BookStack offers a WYSIWYG editor and an optional Markdown editor, so review how each page renders in the editor you intend to use. Replace GitBook-specific blocks such as hints, embeds and tabs with standard Markdown or BookStack equivalents, and re-link images and internal references. Check the result on sample pages from each book. The step is complete when the test instance matches the approved mapping and the cleaned pages have been reviewed.
Configure SSO, roles and permissions
Connect BookStack to your identity provider using the SAML2, OIDC or LDAP option that matches your directory, and confirm that users sign in with their corporate accounts. Set up roles and permissions so that each book and shelf reflects who may read or edit it, and enable multi-factor authentication where your policy requires it. Test with accounts from each group. Confirm the sign-in and permission model with your security team before any user is invited. The step is done when every test account receives the access it should have and no more.
Run a parallel period and cut over
Keep GitBook and BookStack available together for a period you agree in advance, with the Git repository as the source of truth for changes made during that time. Announce the cutover date to readers, then sync the final changes and switch internal links and bookmarks to the new location. Confirm that the BookStack copy matches the repository before anyone stops editing in GitBook. The cutover is done when the internal users work only in BookStack and the agreed checks have been signed off.
Retire the GitBook site with a separate docs plan
Retire GitBook spaces only after the cutover has held and the export has been archived. A published docs domain needs its own plan, because public readers, search engine indexes and external links depend on it. Decide where that content will be served, how redirects will be set, and who owns the domain change. Confirm the contract terms and data retention options with GitBook before ending the subscription. The step is complete when the archive is stored, the public docs cutover has its own signed-off plan, and the subscription is closed.
Questions buyers ask before choosing BookStack over GitBook
How much does switching from GitBook to BookStack cost?
The switch replaces a subscription with a one-time project plus running costs. BookStack is MIT licensed, so there is no license fee, but you pay for a server, a MySQL 8.0 or MariaDB 10.6 or later database, backups, and the people who maintain it. The one-time cost covers scoping, content export, migration, SSO setup and cutover, and it depends on how many sites, spaces and pages you have and how much cleanup they need. Ask any implementation partner for a fixed-scope written quote that lists each component separately. Confirm your current GitBook per-site and per-user charges with GitBook, since those are the recurring costs you would stop paying.
How long does a GitBook to BookStack migration take?
The timeline is set by the volume and state of your content, not by the tool. The main drivers are the number of books and pages, how many GitBook-specific blocks or embedded integrations need rework, how much content must be mapped into BookStack's shelves, books and chapters, and how many people must review it before cutover. Teams with a clean Markdown export usually move faster than teams with years of unmanaged pages. Ask for the timeline as a written milestone plan in the statement of work, and confirm with your own change board when the docs domain can be switched.
What does the migration need from our team?
Your team supplies decisions and access, and the migration goes faster when those are ready at the start. You will need an owner for the content structure, reviewers for each content area, someone who can provision the server and database in your environment, and an identity administrator for SSO. Plan for time from your documentation owners to check that pages read correctly after conversion. The team also needs to agree on who can edit, who can approve and which content stays internal, because BookStack's role and permission system must be configured to match.
Can we do the GitBook to BookStack move ourselves?
Yes, a capable internal team can run the move, provided it has someone comfortable with Linux, PHP and database administration. BookStack provides official installation scripts for Ubuntu 22.04, 24.04 and 26.04, and it does not publish official Docker images, pointing instead to community setups such as LinuxServer.io. Self-hosting in-house means you own patching, backups, upgrades and content conversion. Alternatively, DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms in your own infrastructure under a fixed-scope written agreement, with ongoing support available as a retainer.
Does BookStack keep our Git-based documentation workflow?
No, BookStack does not offer GitBook's bi-directional Git Sync, so a Git-driven review and publishing workflow is lost in a straight move. BookStack's editing model is built around its WYSIWYG editor, an optional Markdown editor and built-in diagrams.net diagrams, with content stored in the application database. If your engineers rely on pull requests to change documentation, you need to decide whether they accept editing in the BookStack interface, or whether a different tool such as Wiki.js, with Git storage, better fits. Before ending your GitBook contract, export everything through Git Sync so you hold a complete Markdown copy in GitHub or GitLab.
Can BookStack publish public documentation sites?
BookStack is designed primarily for internal knowledge, and its documented sign-in, role and permission features are aimed at controlling access to shelves, books and pages. Confirm with the BookStack documentation whether public, unauthenticated publishing and custom documentation domains meet your needs before you commit. If you publish product docs to customers, you will also need to plan the public hosting, caching and CDN layer yourself, because a self-hosted BookStack instance does not provide one. Check your public traffic expectations and your GitBook published-site requirements with your team before deciding.
How do we handle SSO and MFA in BookStack?
BookStack supports OIDC, SAML2 and LDAP sign-in, so you can connect it to your existing identity provider rather than maintaining local passwords. It also includes built-in multi-factor authentication that can be enforced per role, which lets you require it for editors and administrators. Ask your identity team to confirm which protocol your provider supports, how group claims map to BookStack roles, and how account deprovisioning works when someone leaves. Compare this with your current GitBook plan, since SAML is described as Enterprise-only there, and confirm the current entitlement with GitBook.
How do we handle upgrades and backups for BookStack?
You own upgrades and backups, which GitBook currently handles for you as a hosted service. BookStack releases are published on GitHub, such as v26.09.1 on September 29, 2026, so your team must track releases, test them in a staging copy and schedule production upgrades. Backups must cover the database and the uploaded files together, and you should test restores on a schedule rather than assume they work. Agree on the upgrade cadence, the restore objective and the on-call owner in writing before cutover, and confirm the recurring hours your organization will staff for this work.
What you lose when you leave GitBook's Git workflow
The largest loss is bi-directional Git Sync. In GitBook, a team that keeps docs in GitHub or GitLab can edit either side and have changes flow both ways, so a docs change can pass through the same pull request, code owners and CI checks as the code it describes. BookStack has no native Git sync. Books, chapters and pages are edited in the web interface, and its REST API and page history help with automation and recovery, but they do not give you branches or pull request review. This matters most when engineering owns the docs, such as API references or runbooks that change with each release. List which teams merge docs through Git today and how often. A practical mitigation is to keep a Git repository of Markdown as the source of truth, use Git Sync to hold a complete copy, and treat BookStack as the reading and editing layer. Confirm with the BookStack API documentation how updates from the repository would reach it.
The second loss is the published docs site. GitBook serves public documentation on its own hosted site, so product docs can sit on a custom domain without your team running the web tier. With BookStack, you run the application, the database, TLS certificates, caching and any CDN in front of it. Check whether your public documentation needs anonymous read access, which BookStack's permission system controls, and whether search engines must index it. Many external readers raise both the load and the uptime expectations, so ask for a capacity plan and a written cutover plan for the docs domain, including redirects from old URLs. If your readers are mostly internal, this loss matters far less, and the work shrinks to access control and internal DNS.
The third loss is GitBook integrations. Any tool that receives webhooks, embeds GitBook content or syncs spaces will stop working at cutover, and BookStack will not warn you. Inventory every connected service, its owner, and whether it reads from GitBook or writes to it. For each one, decide whether to rebuild the link against BookStack's API and webhooks (confirm which events it can send), point it at the Git repository, or retire it. Keep the repository as the source of truth so future tools have a stable input. Before ending the GitBook contract, run the Git Sync export and confirm the repository contains every page, asset and navigation file, since site settings and integrations do not transfer.
How DeployOpen helps you evaluate and implement BookStack
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a GitBook move to BookStack, we start from the documentation you actually publish and the sign-in, permission and hosting rules your organization must meet.
How we scope
- We inventory GitBook spaces, internal and published docs, and which content must remain reachable outside the company.
- The written scope covers shelves, books, chapters, page import, roles, SAML, OIDC or LDAP sign-in, and hosting.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We deploy BookStack in your environment, with MySQL or MariaDB and PHP settings that match your admin standards.
- We configure identity integration and enforce multi-factor authentication where your role policy requires it.
- We test sign-in, permissions, page content and attachments against the inventory before any cutover.
How we hand over
- You receive configuration records, a permissions map, backup and restore steps, and a cutover runbook.
- We document how GitBook content was exported, mapped and checked for completeness, so your team can repeat it.
- Your administrators are trained on daily operation, user onboarding and upgrade procedures for BookStack.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- A retainer can cover BookStack version upgrades, backup verification and periodic access reviews.
- Confirm response expectations and upgrade scope in the written retainer before go-live.
