BookStack vs Grav

What BookStack is

BookStack is an MIT-licensed, self-hosted documentation application built around shelves, books, optional chapters and pages. It provides role and content-level permissions, multiple enterprise authentication options and a permission-aware REST API, but the operator remains responsible for the PHP and database stack, upgrades, filesystem permissions, security configuration and complete database-plus-file backups.

What Grav is

Grav is an MIT-licensed, self-hosted flat-file CMS that stores content in plain files rather than a database and renders sites through PHP, Markdown, YAML and Twig. A graphical administration panel is optional and depends on additional plugins; operators still own server configuration, filesystem permissions, core and plugin updates, security settings, backups and compatibility testing.

What BookStack is built to do

Book hierarchy

Organizes page content within optional chapters, books and reusable bookshelves.

Roles and permissions

Combines system roles with content-level overrides and inherited controls.

Federated authentication

Documents OIDC, SAML 2.0 and LDAP configuration for self-hosted instances.

REST API

Provides token-authenticated JSON endpoints governed by the API user's permissions.

What Grav is built to do

Flat-file content

Stores content in plain files and does not require a content database.

Markdown and Twig

Uses Markdown for authoring and Twig templates for presentation.

Plugin and theme ecosystem

Adds functions and designs through separately maintained packages.

Optional Admin panel

Provides browser-based content and maintenance tools when its required plugins are installed.

Choose BookStack if

• Internal handbooks, runbooks and technical knowledge bases with a clear hierarchy
• Organizations needing self-hosting, role controls and supported identity integrations
• Teams that can automate upgrades, database and file backups, and restore drills

Skip BookStack if

• You need a vendor-operated SaaS with no infrastructure responsibility
• Your information model cannot fit shelves, books, chapters and pages
• You cannot preserve the database, uploads, configuration and original APP_KEY together

Choose Grav if

• Content sites whose structure and update rate suit files rather than relational records
• Developer-led workflows using Markdown, YAML, Twig and version control
• Projects that value a lightweight core and selectively chosen plugins

Skip Grav if

• The product requires transactional or heavily relational application data
• You need a fully managed CMS with vendor-operated infrastructure and recovery
• Critical features depend on plugins whose maintenance and compatibility cannot be verified

BookStack: pros & cons

• Predictable structure: Shelves, books, chapters and pages give teams a constrained documentation hierarchy.
• Granular access: Roles can be combined and overridden at shelf, book, chapter or page level.
• Authentication choices: Official administration docs cover OpenID Connect, SAML 2.0 and LDAP.
• Automation surface: The REST API covers content and administrative resources while enforcing the API user's roles and permissions.
• Self-hosting burden: PHP, MySQL or MariaDB, web-server configuration, updates and monitoring are operator responsibilities.
• Manual recovery design: There is no built-in full backup and restore; both database records and instance files must be protected.
• Key dependency: Restores need the original APP_KEY for encrypted features such as multi-factor credentials.
• Hierarchy trade-off: The book metaphor is approachable but may constrain teams needing free-form graphs or complex publishing workflows.

Grav: pros & cons

• No content database: Pages and configuration live in files, simplifying version-controlled content workflows.
• Small core footprint: Official requirements center on a compatible web server, PHP and required extensions.
• Flexible development model: Themes use Twig while plugins extend behavior beyond the core.
• Optional administration: Teams may edit files directly or install the separate Admin panel and its dependencies.
• Self-hosting responsibility: PHP, web-server rules, permissions, TLS, updates, logging and recovery remain operational work.
• Plugin dependency risk: Admin and many site capabilities depend on plugins whose support and version compatibility must be checked.
• Flat-file fit limits: Transactional, highly relational or write-heavy applications may need a database-backed platform.
• Admin is not core: The graphical panel requires the login, forms and email plugins in addition to the Admin plugin.