BookStack или Wiki.js: что выгоднее и когда

MAATRIX

Если команда выросла из общего Google Docs и файликов в Telegram, рано или поздно встаёт вопрос базы знаний. Confluence стоит денег и всё сложнее доступен из России, Notion — облако с непредсказуемым будущим для российских карт. Остаются self-hosted варианты, и среди них два самых зрелых кандидата — BookStack и Wiki.js. Они решают одну задачу принципиально по-разному, и выбор не всегда очевиден, пока не попробуешь оба на живом сервере.

Что вообще сравниваем: два разных подхода к базе знаний

BookStack построен вокруг простой иерархии: Shelf → Book → Chapter → Page — полка, книга, глава, страница. Это осознанное архитектурное решение: структура жёстко навязана, и у пользователей физически нет способа устроить хаос из разрозненных страниц без родителя. Редактор — WYSIWYG (по сути обёртка над TinyMCE), знакомый любому, кто хоть раз работал в WordPress. Написан на PHP/Laravel, хранит контент в MySQL.

Wiki.js устроен свободнее — это плоское дерево страниц с произвольной вложенностью через путь (/docs/backend/api), без навязанной иерархии книг и глав. Родной формат редактирования — Markdown с live-превью, но есть также визуальный редактор, HTML-режим и даже AsciiDoc. Написан на Node.js, хранит контент в PostgreSQL, MySQL/MariaDB или даже SQLite для совсем небольших инсталляций.

На практике разница ощущается так: в BookStack сложно построить бардак, потому что структура задаёт рамки. В Wiki.js легко сделать красиво и гибко, но и легко скатиться в кашу из страниц без единой системы, если в команде нет дисциплины именования путей.

Требования к серверу и стек технологий

Здесь расхождение практическое, а не философское — от стека зависит, что вам придётся поддерживать на сервере.

На практике для команды до 20–30 человек и того, и другого хватит на 1 vCPU / 1–2 ГБ RAM с запасом. Разница начинает ощущаться при большом количестве одновременных редакторов и объёмном полнотекстовом поиске — Wiki.js с PostgreSQL и включённым поиском ест памяти заметно больше, чем BookStack с MySQL. Если сервер и так уже держит несколько сервисов в Docker, PHP-стек BookStack обычно проще уживается по памяти рядом с соседями.

Готовые compose-файлы для обоих есть отдельно — не буду дублировать их здесь целиком, только ключевые нюансы. Полный рабочий docker-compose.yml для BookStack с MySQL и переменными окружения разобран в статье BookStack в Docker Compose: готовый файл. Для Wiki.js пошаговая установка на голый Ubuntu 24.04 (без Docker, через systemd) — в статье Wiki.js на Ubuntu 24.04: пошаговая установка.

Установка и первый запуск: сколько времени и телодвижений

BookStack через Docker Compose разворачивается буквально одной командой:

services:
  bookstack:
    image: lscr.io/linuxserver/bookstack:latest
    environment:
      - PUID=1000
      - PGID=1000
      - APP_URL=https://wiki.example.com
      - DB_HOST=bookstack_db
      - DB_DATABASE=bookstackapp
      - DB_USERNAME=bookstack
      - DB_PASSWORD=change_me
    ports:
      - "6875:80"
    depends_on:
      - bookstack_db

  bookstack_db:
    image: lscr.io/linuxserver/mariadb:latest
    environment:
      - MYSQL_DATABASE=bookstackapp
      - MYSQL_USER=bookstack
      - MYSQL_PASSWORD=change_me
      - MYSQL_ROOT_PASSWORD=change_me_too
    volumes:
      - bookstack_db_data:/config

volumes:
  bookstack_db_data:

docker compose up -d — и через 30–60 секунд можно логиниться дефолтным admin@admin.com / password (сразу сменить). Никакого визарда настройки — сразу рабочий интерфейс.

Wiki.js в Docker поднимается похожим образом, но требует отдельной инициализации через веб-визард при первом заходе: там задаётся язык интерфейса, тип хранилища контента (можно сразу подключить синхронизацию с Git-репозиторием — полезная фича, которой у BookStack нет из коробки), первый администратор. Занимает 3–5 минут против «сразу открыл и работаешь» у BookStack. Мелочь, но на счету, если разворачиваете вики за 10 минут до демо.

Оба варианта одинаково легко поставить за reverse proxy с автоматическим SSL — общий подход разобран в статье Caddy или Nginx: что выбрать для сервера, она применима к обоим сервисам без изменений.

Редактирование и совместная работа: WYSIWYG vs Markdown

Это, пожалуй, главный водораздел при выборе.

BookStack даёт классический визуальный редактор с панелью форматирования — заголовки, таблицы, код, изображения перетаскиванием, вставка из буфера с сохранением форматирования. Порог входа нулевой: нетехнический сотрудник (менеджер, HR, саппорт) сядет и начнёт писать без объяснений. Есть также markdown-режим редактирования, но он вторичен и переключается вручную.

Wiki.js — про Markdown как основной язык. Это отличный выбор, если базу знаний ведут в основном разработчики или технически подкованные люди: можно писать в любимом текстовом редакторе локально и синкать через Git-интеграцию, вставлять блоки кода с подсветкой синтаксиса на лету, работать с diff-историей как с кодом. Но нетехнического сотрудника markdown-синтаксис (жирный, обратные кавычки для кода) первое время будет тормозить — хотя визуальный WYSIWYG-режим в Wiki.js тоже есть и вполне рабочий.

Совместное редактирование в реальном времени (как в Google Docs, когда два человека видят курсоры друг друга) не реализовано полноценно ни там, ни там — оба используют модель «редактирует один, остальные видят изменения после сохранения», с блокировкой страницы во время редактирования у BookStack и версионированием у обоих.

Права доступа, поиск и организация контента

BookStack предлагает ролевую модель уровня enterprise из коробки: роли можно назначать на уровне полки, книги, главы или конкретной страницы, с точностью до операций «просмотр / создание / редактирование / удаление». Для компании, где часть документации закрыта для определённых отделов (например, HR-политики видны не всем), это готовое решение без доработок.

Wiki.js тоже поддерживает права по группам и путям, но система менее гранулярна: права назначаются на уровне групп страниц по правилам путей (/hr/* доступен группе HR), что работает, но требует более аккуратного планирования структуры путей заранее — иначе рефакторинг прав превращается в переименование десятков страниц.

Поиск: BookStack использует встроенный полнотекстовый поиск MySQL — быстрый на средних объёмах, но без продвинутых фич вроде поиска по синонимам. Wiki.js поддерживает несколько поисковых движков на выбор — встроенный, а также интеграцию с Elasticsearch или Algolia для крупных баз (тысячи страниц), что даёт заметно более качественную релевантность на масштабе, но требует поднимать и обслуживать дополнительный сервис.

Что выбрать под конкретный сценарий

Сведу в одну таблицу — она полезнее абстрактных рассуждений:

Если ни один вариант не закрывает задачу целиком — например, нужна вики с сильным упором на markdown, но проще в администрировании, чем Wiki.js — стоит присмотреться к третьему игроку, Outline: установка на Ubuntu разобрана в статье Outline Wiki на Ubuntu 24.04: пошаговая установка, но это тема отдельного сравнения.

Независимо от выбора, регулярный бэкап базы данных обязателен — оба сервиса хранят весь контент в реляционной СУБД, и без дампа вы теряете вики целиком при любой аварии диска. Как настроить автоматический бэкап MySQL по расписанию — в статье Как установить и настроить бэкап MySQL на VPS (для Wiki.js на PostgreSQL логика та же, только через pg_dump).

Частые вопросы