BookStack

Last reviewed Aug 26, 2026 · 858 words

BookStack is the documentation platform I recommend when the people who will write in it are not developers. Its entire model is shelves, books, chapters and pages, in that order, and a new user understands it in the 30 seconds it takes to say the sentence. That rigidity is the feature: nobody has to decide on a page hierarchy, nobody has to learn wiki markup, and search plus a permissions system that works at every level does the rest. The cost is that if you want backlinks, databases, nested folders ten deep or a graph view, you are in the wrong tool and should read the wikis category instead.

The structure is the product

A shelf groups books; a book holds chapters and pages; a chapter holds pages. That is the whole hierarchy and it cannot go deeper. In practice a household or small company maps onto it without friction: a "Homelab" book with chapters for network, storage and services; an "Operations" book with a runbook per page. Each page has a WYSIWYG editor and a Markdown editor with live preview, page revisions with diff, comments, tags, and a draw.io integration for diagrams. Pages can be moved between books and books between shelves, so a wrong early guess costs a drag. The structure is also why BookStack is the strongest Confluence replacement for teams who used Confluence as a filing cabinet rather than a collaboration canvas.

The Docker setup that survives a restart

BookStack is a PHP application backed by MySQL or MariaDB; the 512 MB minimum covers both containers for a small team. Two well-maintained images exist, from LinuxServer and from solidnerd. The LinuxServer one:

services:
  bookstack:
    image: lscr.io/linuxserver/bookstack:latest
    environment:
      - PUID=1000
      - PGID=1000
      - APP_URL=https://docs.example.com
      - APP_KEY=base64:REPLACE_WITH_GENERATED_KEY
      - DB_HOST=bookstack-db
      - DB_USER=bookstack
      - DB_PASS=change-me
      - DB_DATABASE=bookstackapp
    volumes:
      - ./bookstack:/config
    ports:
      - "6875:80"
    depends_on:
      - bookstack-db
  bookstack-db:
    image: lscr.io/linuxserver/mariadb:latest
    environment:
      - MYSQL_ROOT_PASSWORD=change-me-too
      - MYSQL_DATABASE=bookstackapp
      - MYSQL_USER=bookstack
      - MYSQL_PASSWORD=change-me
    volumes:
      - ./db:/config

Two settings break more installs than everything else combined. APP_URL must be the exact public address, scheme included; a mismatch produces mixed-content errors, broken image links and a login loop behind a reverse proxy. APP_KEY encrypts sessions and some stored values and must be generated once and never changed; the LinuxServer image logs a generated key on first start if you leave it unset, and you should copy it into the compose file immediately. First login is [email protected] with password password; change both before the container has been up an hour.

Permissions and SSO are better than the price suggests

Roles carry system-wide permissions, and then every shelf, book, chapter and page can override view, create, edit and delete per role. That is enough to give a client read access to one book, contractors edit rights to one chapter, and everyone else the default. For login, BookStack supports LDAP, SAML 2.0 and OpenID Connect out of the box, configured through environment variables, so putting it behind Authentik or Authelia is a 10-line change that gives you MFA without BookStack knowing anything about it. Set AUTH_METHOD=oidc, fill in the issuer and client details, and add AUTH_AUTO_INITIATE=true if you want the login page to skip straight to the provider.

Backups are three things, not one

The database holds pages and revisions. Uploaded images live in public/uploads, and attachments in storage/uploads, both under the config volume in the LinuxServer layout. The .env file holds the APP_KEY. A backup that misses any of the three restores to something broken: no key means encrypted values become unreadable, no uploads means every page's images 404. Dump the database with mysqldump, tar the config volume, and put both where restic or your existing backup job already sends the rest of your data. Test a restore into a throwaway container once; it takes 10 minutes and answers the only question that matters.

Where it stops fitting

BookStack has fewer integrations than Wiki.js or Outline, and no real-time collaborative editing: two people editing one page get a warning, not a shared cursor. There is a REST API and there are webhooks, which cover automation and export, but the plugin surface is thin by design. If your team lives in Slack threads and wants a Notion-shaped canvas, this is the wrong shape. If it wants a place where the on-call runbook is always in the same book, it is the right one.

What I'd do

Deploy the LinuxServer image with MariaDB, set APP_URL and a generated APP_KEY before first boot, put it behind Caddy for TLS, and wire OIDC to Authentik on day two. Create three books, not thirty, and let structure grow from use. Nightly database dump and config tar into your backup job. For a family, a small business, or an engineering team that needs runbooks more than brainstorming, BookStack is the wiki most likely to still be in use a year later, and that is the metric that counts.