Is self-hosted Wiki.js cheaper than GitBook for your documentation?
Self-hosting Wiki.js removes GitBook's per-site and per-user subscription, but it does not remove cost. You take on a server, a PostgreSQL or MySQL database, a CDN if you publish docs publicly, the migration itself and ongoing maintenance. Whether the total comes out lower depends on three things: how many people edit and read the content, how many separate sites you run, and how much Linux, database and Node.js work your team can absorb in-house. No GitBook price figures are supplied for this page, so take the subscription side of the comparison from your own renewal quote, not from published list prices, and ask the vendor to show the per-site and per-user lines separately so you can model growth.
Model the self-hosted side as one-time and recurring costs. One-time items are the migration from GitBook, configuration of single sign-on, and hardening. Recurring items are hosting, database backups, CDN traffic for public sites, patching, and the staff time to upgrade Wiki.js. Wiki.js 2.x requires a dedicated domain or subdomain, and Linux systems need at least 1 GB of RAM according to the Wiki.js requirements documentation, so a small single-site deployment is inexpensive to host, while several sites or heavy public traffic raise hosting and CDN spend. Who pays for each item matters: your cloud bill, your staff time, or an implementation partner's fixed-scope fee if you choose to outsource setup.
Wiki.js 2.x is licensed AGPL-3.0, and the stable line is 2.x. The 3.0 code in the main requarks/wiki repository is a beta that the project marks as not for production use, so budget for the 2.x line and confirm its current release before you commit. The AGPL-3.0 license has obligations if you modify the software and make it available to users over a network, so have your legal team review that position alongside the cost case. Before you decide, ask your GitBook account team for the renewal price with and without SAML, since SAML is an Enterprise-only feature, and compare that against the free SAML 2.0 module in Wiki.js.
Which cost components sit on each side
This table maps each cost component to what GitBook charges for and what a self-hosted Wiki.js deployment requires, and marks whether it is one-time or recurring. Use it to build a like-for-like model before requesting a quote, since GitBook pricing is set per site and per user and must be confirmed directly with GitBook. The main takeaway is that the self-hosted side moves cost from a vendor invoice to infrastructure, labor and internal skills that you control.
| Cost component | GitBook side | Self-hosted Wiki.js side |
|---|---|---|
| License or subscription | Recurring per-site fee plus per-user fee; confirm current terms with GitBook | No license fee; Wiki.js is AGPL-3.0, so confirm obligations with counsel if you modify and host it for others |
| Application hosting | Included in the hosted service | Recurring: one or more servers or containers, at least 1 GB of RAM on Linux per the requirements documentation |
| Database | Included in the hosted service | Recurring: PostgreSQL 9.5 or later recommended, or MySQL 8.0 or later; backups and patching are yours |
| CDN for public docs | Included in the hosted publishing service | Recurring if public: edge caching and TLS termination you provision and pay for |
| Identity integration | SAML is an Enterprise-only feature; confirm your plan | Built-in SAML 2.0, OIDC and LDAP modules; one-time configuration against your identity provider |
| Git sync and storage | Git Sync available on every plan, bi-directional with GitHub or GitLab | One-time setup of the Git storage module; repository hosting cost depends on your existing Git platform |
| Implementation and configuration | Largely self-service | One-time: installation, theming, permissions, storage and authentication setup, by staff or a partner under a fixed-scope written agreement |
| Content migration | Export via Git Sync or site export | One-time: converting GitBook-specific blocks, mapping navigation and redirects, and verifying the result |
| Upgrades and patching | Handled by GitBook | Recurring: tracking Wiki.js 2.x releases, testing, and applying security updates within your change process |
| Support | Included in plan terms; confirm response commitments in writing | Recurring: internal on-call or a support retainer; community support is not a contractual SLA |
| Internal skills | Minimal administration effort | Recurring: Node.js, database and reverse proxy administration, plus knowledge of Wiki.js 2.x versus the 3.0 beta |
What moves the GitBook versus Wiki.js comparison
The total cost of either option depends less on the list price than on who uses the wiki, how many sites it serves and what the team can run. The cards below name the inputs that shift the numbers most, so you can ask the right questions before comparing quotes or budgets.
Editors and readers
GitBook charges per user, so the count of editors and the count of readers who need an account both affect the bill. Wiki.js and BookStack have no per-seat license, so user growth mainly adds identity provider load and support work. Ask GitBook which users count as billable and whether read-only viewers are charged. Then count how many people will need edit rights, separate from those who only read.
Sites and public versus private docs
GitBook prices per site, so each separate documentation site adds a fee. A self-hosted Wiki.js instance can hold many pages across spaces, but it requires a dedicated domain or subdomain. Public docs also need a CDN or caching layer in front of the server to handle traffic spikes. List every site, whether it is public or private, and the expected traffic for each.
SAML and SSO tier requirements
Confirm with GitBook whether SAML is included in your plan or only in its Enterprise tier, since that can move the license cost sharply. Wiki.js supports SAML 2.0, OpenID Connect and LDAP through its authentication modules, and BookStack supports OIDC, SAML2 and LDAP. The cost on the self-hosted side is the identity provider you already run, such as Keycloak or Active Directory, plus the time to integrate it.
Content volume and attachments
Large page counts, long histories and heavy attachments increase storage, backup size and database load on the self-hosted side. Storage modules such as AWS S3 or other object stores can move attachments off the application server, which changes both the storage bill and the backup plan. Measure total content and attachment size in GitBook and in its Git export before estimating infrastructure.
Availability requirements
A wiki that staff use for incident runbooks may need higher uptime than an internal reference site. On a self-hosted stack, availability means redundant application nodes, a managed or replicated database, tested backups and a monitored restore path, each with its own cost. GitBook carries the hosting availability within its service terms, which you should read against your own recovery objectives. Define the outage you can tolerate before pricing the self-hosted design.
Team skills in Linux, databases and Git
Running Wiki.js with PostgreSQL or BookStack with MySQL or MariaDB requires staff who can patch the operating system, tune the database, rotate credentials and apply upgrades. Wiki.js Git storage also depends on a well-managed repository workflow. If the team lacks these skills, the labor cost of hiring, training or contracting support can exceed the license savings, so record who will own each layer before you decide.
How the Wiki.js server and database costs are built
The infrastructure side of a self-hosted Wiki.js deployment is mostly one-time setup followed by recurring hosting, and the platform team decides most of the cost before the first page is written. Wiki.js needs a dedicated domain or subdomain because it cannot be mapped to a subfolder of an existing site, so the team must allocate a hostname, a TLS certificate and a DNS record. On Linux it needs at least 1 GB of RAM, and it runs on Linux, Docker or Kubernetes, so the hosting cost depends on whether your organization already operates container or cluster platforms that can absorb another service.
The database choice shapes the platform team's effort more than the license does. The 2.x line recommends PostgreSQL 9.5 or later, and it also supports MySQL 8.0 or later, MariaDB, MS SQL and SQLite. If your organization already runs PostgreSQL with backup, patching and monitoring in place, adding Wiki.js is mostly a new database and role. If your database team standardizes on MySQL or MariaDB, the same work applies to that engine. Choose the engine your operators already support, because the operational cost of a database nobody on the team runs is usually higher than the database itself. If you use PostgreSQL for search, the search module needs the pg_trgm extension, so confirm with your DBA that the extension can be installed in your environment before you commit to that configuration.
Size the web tier and the database from your own load testing, not from a generic figure. The facts supplied for Wiki.js set a minimum memory floor and list supported platforms, but they do not give capacity for your page count, concurrent editors or public traffic. Ask your team to run a test against a staging copy with realistic content and user numbers, measure response times and memory use, and then decide the instance size and whether the database needs a replica for backups. Those results, plus the cost of the hosting and database services in your own cloud or data center, are the inputs that a quote for this component should reflect.
How to build the comparison with your own numbers
This sequence turns a vague sense that GitBook costs too much into a three-year comparison built from your invoice, your seat count, your infrastructure rates and your own effort estimates. The output is a model you can defend in a renewal or budget discussion.
Pull the current GitBook invoice and plan tier
Start with the most recent invoice and the contract or order form that sets the plan tier and renewal date. Record the per-site charge, the per-user charge, any Enterprise-only items such as SAML, and any add-ons or overages. Ask your GitBook account contact to confirm in writing what the renewal price will be, since the invoice shows only what you paid last period. The step is done when you have one line per charge with its source document named beside it.
List every site and seat in use
Count each GitBook site, including internal documentation, public product docs and any sites that are archived but still billed. Then list every user who holds a seat, separating editors, viewers and admins, and flag inactive accounts. Compare the counts against what the plan includes and what you are billed for. The step is done when a spreadsheet shows site count, seat count and billable count, and the gap between them is explained.
Price the infrastructure at your own rates
Price the server, database, backups, storage and any CDN for public documentation using your cloud provider's or data center's current rates, not a generic figure. Include a staging instance if you plan one, and note whether public docs need a CDN in front of the origin. Wiki.js and BookStack have no license fee, so this line is where your recurring hosting cost sits, alongside PostgreSQL or MySQL. The step is done when each infrastructure component has a monthly and annual figure traced to a rate card or quote.
Estimate migration and integration effort in hours
Estimate the work in your own hours: exporting GitBook content, cleaning platform-specific blocks, mapping navigation and redirects, connecting authentication, setting up backups and cutting over the docs domain. Your engineers or your implementation partner should estimate each task separately and state the assumptions, such as the number of pages and whether public docs need redirects. The step is done when each task has an hours estimate, a named owner and a note on what could change the estimate.
Add support, upgrades and staff time
Estimate recurring operations work: applying Wiki.js or BookStack upgrades, patching the operating system and database, monitoring, restoring test backups and handling user requests. Decide whether this is covered by internal staff, a support contract or a retainer, and record the hours per month that each option implies. Ask any implementation partner to quote ongoing support as a separate line item from the one-time implementation. The step is done when recurring operations hours are recorded in a form you can divide by your team's rates.
Request a written quote for implementation scope
Send the scope you have defined to one or more implementation partners and ask for a written, fixed-scope quote that lists deliverables, assumptions, exclusions and timelines. Ask each provider to separate one-time work from recurring support, and to state what they need from your team. Compare the quotes against your internal estimate line by line rather than comparing totals alone. The step is done when you hold written quotes that match the scope in your model.
Run a three-year view by cost type
Build a three-year model with two sections: one-time costs such as migration, integration and initial setup, and recurring costs such as GitBook fees, hosting, support and staff time. Show the GitBook renewal line alongside the self-hosted lines for each year, and run a sensitivity check that raises the seat count and the infrastructure rate. The step is done when the totals for each year are reproducible from the sources recorded in earlier steps, and the break-even point is either shown or clearly absent.
Questions buyers ask before comparing GitBook and Wiki.js costs
What drives the cost of self-hosting Wiki.js compared with GitBook?
The Wiki.js license fee is zero, so the cost sits in components you pay for or staff: a server with at least 1 GB of RAM on Linux, a PostgreSQL or MySQL database, storage and backups, a CDN if you publish public docs, TLS and domain setup, upgrades, and the people who run them. GitBook's cost is its per-site fee plus a per-user fee, so it grows with seats and sites. Self-hosting shifts the cost from a recurring subscription to recurring operations effort. Ask GitBook for its current written price for your seat count and site count, and price your own servers, database and staff hours in your environment before comparing totals.
How long does a GitBook to Wiki.js migration take?
Duration depends on the number of spaces, the volume of pages and attachments, how much GitBook-specific markup needs cleaning, how navigation and redirects are mapped, and how many people must review content before the docs domain is cut over. Export is the first step: GitBook Git Sync can place content in a GitHub or GitLab repository of Markdown, and Wiki.js can then connect to that repository through its Git storage module. No researched fact gives a migration duration, so ask any partner for a fixed-scope plan with a written timeline that lists these inputs for your content.
Can an internal team run Wiki.js without outside help?
Yes, if your team has people who can operate a Node.js application, a PostgreSQL or MySQL database, a reverse proxy and a backup routine. Wiki.js needs its own dedicated domain or subdomain because it cannot be mapped to a subfolder, and it supports Docker and Kubernetes, which can simplify deployment. Authentication, storage and search settings also need ownership. Assess your team's skills honestly, decide who handles patching and incident response, and treat outside help as an option for setup, hardening, upgrades or ongoing support rather than a requirement.
Does SAML cost extra on GitBook and on Wiki.js?
On GitBook, SAML is an Enterprise-only feature, so you should ask GitBook in writing which plan and fee apply to your organization. On Wiki.js, the authentication modules include SAML 2.0, alongside Azure AD, Keycloak OpenID Connect, LDAP and Active Directory, Okta, and TOTP two-factor authentication. The software itself carries no license fee, but you still pay for the identity provider configuration, certificate handling and testing that SAML requires. Confirm the identity provider you already run and the effort needed to connect it.
Should we use the Wiki.js 3.0 beta for a production docs site?
No, not for production. The main requarks/wiki repository holds Wiki.js 3.0, and its README marks it as beta and not for production use. The stable 2.x line now lives in the requarks/wiki-v2 repository, where v2.5.316 was published on October 2, 2026. Plan your deployment on the 2.x line, check the release notes for the version you install, and revisit the 3.0 status before any future upgrade decision.
What should we ask a partner for in a fixed-scope quote?
Ask for written scope, deliverables and timelines before work starts, which is how most DeployOpen engagements are agreed. Request a list of the GitBook spaces and sites in scope, the export method, the target hosting environment, the database and CDN choices, the authentication integration, the cutover plan for the docs domain, backup and restore testing, and documentation for handover. Also ask whether ongoing support, upgrades and testing are covered by a separate retainer. DeployOpen does not publish a price list, so the quote follows from that written scope.
What recurring costs remain after a Wiki.js deployment?
Recurring costs include server and database capacity, backups and their storage, CDN usage for public documentation, domain and certificate renewals, patching and upgrades of Wiki.js, the database and the operating system, monitoring, and staff time for access reviews. Wiki.js releases are published on the requarks/wiki-v2 GitHub releases page, so someone must track them. Budget these as operating expenses in your own environment, and ask any partner whether upgrades and continuous support are included or sold as a retainer.
What a GitBook to Wiki.js migration asks of your team
The migration runs in five steps: export the content through GitBook Git Sync, connect Wiki.js Git storage to the resulting repository, clean the GitBook-specific blocks, map navigation and redirects, and cut over the docs domain. Most of the labor sits in the middle two steps, because Wiki.js reads plain Markdown in a repository and does not understand GitBook's custom blocks, hints or embedded components. Before you plan the work, confirm with the GitBook export guide exactly what Git Sync carries across, since site settings, integrations and some page-level configuration are not part of the Markdown repository.
Effort depends on four things you can count before the project starts: the number of pages, how many pages use custom blocks or embedded content, how many inbound links and public URLs must keep working, and whether the docs are public, private or both. Each custom block type usually needs a conversion rule that someone on your team approves. Redirects are the step most often underestimated, because every published GitBook URL that search engines or customers rely on needs a planned target in Wiki.js, and the docs domain cutover is only safe once those mappings are tested. Ask for a page inventory and a list of block types from the GitBook space as the first deliverable of any scoped engagement.
Your team should decide who owns the Git repository after cutover, how Wiki.js Git storage pulls and pushes changes, and who approves edits that flow in both directions. Wiki.js requires its own dedicated domain or subdomain, so the cutover plan must fix the hostname before DNS changes start. Run a test migration on a copy of the repository, compare page counts and links, and keep GitBook available until the reconciliation is signed off. Any services, scripts or people that depend on GitBook's publishing workflow should be listed now, because they will need replacements on the Wiki.js side.
How DeployOpen scopes a fixed-price Wiki.js implementation
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For a GitBook exit, we agree the scope in writing first, then build and hand over a Wiki.js instance that your team can run without us.
How we scope
- Inventory the GitBook spaces, published docs sites, users and SAML sign-in in use today
- Confirm where Wiki.js will run, its dedicated domain, database and whether public docs need a CDN
- Agree in writing which Git storage, authentication and migration steps are in and out of scope
How we build
- Install Wiki.js 2.x with PostgreSQL and the pg_trgm extension in your own cloud or data center
- Connect Git storage to your GitHub or GitLab repository and test sync in both directions
- Configure your identity provider and TOTP two-factor authentication, then test access by role
How we hand over
- Document the deployment, configuration keys, backup procedure and upgrade steps for your team
- Provide a test report covering migrated pages, navigation, redirects and sign-in results
- Walk your administrators through daily operation and record who owns each component after handover
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Plan Wiki.js version upgrades in a written schedule agreed with your change control process
- Review backups and access settings on the retainer cadence you agree in the written scope
