Kanboard пережил половину модных досок — разбираемся, за счёт чего

MAATRIX

За те годы, что существует Kanboard, вокруг него сменилось несколько поколений модных канбан-досок: одни стартапы закрылись, другие поменяли бизнес-модель и урезали бесплатный тариф, третьи выпустили редизайн, после которого команда неделю привыкала к новому месту кнопки «добавить карточку». Kanboard всё это время выглядит примерно одинаково — и именно поэтому команды, которые один раз его настроили, годами не думают о миграции. Разберём, за счёт чего простой и внешне немодный инструмент оказывается более живучим, чем яркие конкуренты, и кому такая скучность подходит, а кому нет.

Что такое Kanboard и почему он не «умер» вслед за конкурентами

Kanboard — open-source канбан-доска на чистом PHP, без привязки к тяжёлому фреймворку вроде Symfony или Laravel. Автор написал собственную минималистичную прослойку для работы с БД (PicoDb) и построил на ней приложение, которое запускается практически на любом хостинге с PHP — от shared-хостинга до VPS с парой сотен мегабайт памяти. Проект существует с середины 2010-х, лицензия MIT, исходники открыты на GitHub.

За это время вокруг накопился внушительный список конкурентов — часть уже не поддерживается активно или сменила модель на «облако по умолчанию, self-hosted для избранных». Kanboard всё это время не пытался стать платформой для управления проектами, не обзавёлся собственным чатом, вики или тайм-трекером — он остался канбан-доской с автоматизациями, подзадачами и API. Это осознанное ограничение скоупа: чем меньше у продукта поверхность для поломки при обновлении, тем реже что-то ломается.

Честная картина: это не самый активно развивающийся проект в нише. Разработка держится на одном мейнтейнере плюс сообщество контрибьюторов, релизы выходят не по расписанию, иногда с паузами в несколько месяцев. Для команды, которая хочет «модный продукт с еженедельными фичами», это минус. Для команды, которая хочет «поставил и забыл на три года», — то, что нужно.

Минимальные требования к серверу: что реально нужно

Главное отличие Kanboard от большинства конкурентов на JS-стеке — он не держит постоянный процесс Node.js и не тянет за собой отдельную СУБД в обязательном порядке. Это классическое PHP-приложение: веб-сервер (Apache или nginx с PHP-FPM) обрабатывает запрос, отдаёт HTML и завершается — между запросами процесс не висит в памяти и не копит состояние.

Минимальный набор для запуска:

• PHP 8.1+ с расширениями pdo, mbstring, gd, zip, curl, xml (часть из них ставится по умолчанию в большинстве дистрибутивов);
• SQLite для небольших команд — файл базы, без отдельного процесса СУБД;
• MySQL/MariaDB или PostgreSQL — для команд покрупнее или когда нужен параллельный доступ на запись без блокировок SQLite;
• веб-сервер с поддержкой PHP-FPM (nginx) или mod_php (Apache).

Цифры ориентировочные: зависят от числа запросов в минуту, включена ли автоматическая проверка почты (Kanboard умеет создавать задачи из входящих писем) и сколько плагинов стоит поверх ядра. Но порядок величины устойчив — на VPS с 1 ГБ RAM и одним vCPU Kanboard с MySQL комфортно тянет команду в 15-20 человек без танцев с тюнингом. Для сравнения: Wekan на связке Meteor + MongoDB на той же нагрузке обычно просит вдвое-втрое больше памяти — он держит постоянный Node-процесс и полнотекстовый движок MongoDB даже в простое. Kanboard можно спокойно посадить на самый дешёвый VPS в линейке или разделить сервер с парой других лёгких сервисов — он не станет тем процессом, который среди ночи съедает всю память и роняет соседей.

Стабильность API: почему автоматизации не ломаются между версиями

Kanboard предоставляет API на JSON-RPC 2.0 — это не самый модный формат по сравнению с REST или GraphQL, но у него есть практическое преимущество: контракт метода зафиксирован строже, чем у гибкого REST, где легко незаметно поменять форму ответа. Методы вроде createTask, getBoard, moveTaskPosition существуют в API много лет практически без изменений сигнатуры — новые параметры добавляются с значениями по умолчанию, а не заменяют старые.

Практический пример вызова через curl:

curl -u "jsonrpc:ВАШ_API_ТОКЕН" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "createTask",
    "id": 1,
    "params": {
      "title": "Проверить бэкап базы",
      "project_id": 1,
      "column_id": 2
    }
  }' \
  https://ваш-домен/jsonrpc.php

Токен для API берётся в настройках проекта или в профиле пользователя (глобальный токен — для административных скриптов). Для команд, которые завязывают на доску внешние скрипты — автосоздание задачи при падении мониторинга или при заявке с формы на сайте — это ключевой фактор выбора: скрипт, написанный три года назад, продолжает работать после обновления без переписывания. У инструментов с более активной разработкой API нередко меняется между мажорными версиями, и интеграции приходится чинить при каждом крупном апдейте.

Второй механизм автоматизации без внешних скриптов — встроенные «автоматические действия» (automatic actions): правила вида «если задача попала в столбец X — назначь исполнителя Y» или «если наступил дедлайн — переместить в колонку "Просрочено"», настраиваемые через интерфейс без единой строчки кода. Для простых сценариев это закрывает то, ради чего в других системах пришлось бы городить webhooks и внешний обработчик.

Интерфейс без редизайнов: плюс и минус одновременно

Открыв Kanboard пять лет назад и сегодня, вы увидите практически ту же раскладку: список досок слева, канбан-колонки по центру, карточка с деталями по клику. Разработчики не переписывают фронтенд под новый JS-фреймворк каждые пару лет — интерфейс серверный, с минимальным количеством JavaScript для интерактивности (drag-and-drop карточек, всплывающие формы), без тяжёлой SPA-архитектуры.

Что это даёт на практике:

• Обучение сотрудников не устаревает. Инструкция «как создать задачу» со скриншотами, записанная год назад, всё ещё актуальна — экономия времени при высокой текучке или частом онбординге.
• Кастомизация не съедается обновлениями. Если кто-то подправил CSS под фирменные цвета или добавил плагин через официальный механизм — обновление ядра с высокой вероятностью не сломает эти правки, структура шаблонов и хуков меняется редко.
• Низкая когнитивная нагрузка. Доска не пытается быть одновременно канбаном, вики, чатом и таймтрекером с десятком панелей — на экране ровно то, что нужно для работы с задачами.

Обратная сторона: интерфейс объективно выглядит менее современно, чем у SaaS-конкурентов с командой дизайнеров и бюджетом на UX-исследования. Нет плавных анимаций, тёмная тема выглядит скромно, мобильного приложения нет вообще — только адаптивная веб-версия, которая на телефоне работает, но не создана специально под тач-интерфейс. Если для команды важен «вау-эффект» при показе инструмента клиентам или инвесторам — Kanboard не тот случай.

Установка через Docker Compose

Официальный образ kanboard/kanboard собирает PHP, веб-сервер и SQLite в одном контейнере — самый быстрый путь для небольшой команды. Для команды покрупнее логичнее вынести базу в отдельный контейнер с MySQL:

services:
  db:
    image: mysql:8.0
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: change_me_root
      MYSQL_DATABASE: kanboard
      MYSQL_USER: kanboard
      MYSQL_PASSWORD: change_me_strong_password
    volumes:
      - ./data/db:/var/lib/mysql

  kanboard:
    image: kanboard/kanboard:latest
    restart: unless-stopped
    depends_on:
      - db
    environment:
      DATABASE_URL: "mysql://kanboard:change_me_strong_password@db/kanboard"
    ports:
      - "127.0.0.1:8080:80"
    volumes:
      - ./data:/var/www/app/data
      - ./plugins:/var/www/app/plugins

Для одной-двух команд без MySQL просто уберите блок db и environment — Kanboard сам создаст SQLite-файл в ./data. Порт вынесен на 127.0.0.1 — снаружи нужен реверс-прокси с HTTPS: Caddy с авто-SSL на Ubuntu 24.04 или сначала установка Docker с нуля, если его ещё нет.

После первого запуска зайдите на https://ваш-домен/ — по умолчанию создаётся учётка admin/admin, пароль нужно сменить сразу. Штатного механизма бэкапов на расписании в Kanboard нет — это обычный cron на хосте:

# бэкап SQLite-варианта, раз в сутки
0 3 * * * tar -czf /backups/kanboard-$(date +\%F).tar.gz -C /path/to/kanboard/data .

Где Kanboard проигрывает и для кого он не подходит

Честный список ограничений, которые стоит учитывать до, а не после переезда:

• Нет нативных мобильных приложений. Только адаптивная веб-версия — если команда работает преимущественно с телефона, это будет раздражать.
• Дизайн не кастомизируется без кода. Смена темы или фирменных цветов требует правки CSS или плагина, а не настройки через UI.
• Меньше готовых интеграций «из коробки». Slack, email, LDAP, OAuth2, webhooks — есть, но список короче, чем у активно продаваемых SaaS-продуктов.
• Темп разработки ниже, чем у финансируемых стартапов. Патч на критичную уязвимость может выйти не за сутки, а за неделю-другую — нормально для community-проекта, но стоит закладывать в риски, если через доску идут чувствительные данные.
• Нет встроенной диаграммы Ганта или портфельного планирования. Для одного проекта канбаном хватает с запасом, для программы из десятка проектов с ресурсным планированием — нет. Присмотритесь к Plane или Taiga.

Если вашей команде нужна не столько доска задач, сколько полноценная замена коммерческой системе с трекингом времени, биллингом и отчётами для клиентов — Kanboard такую роль на себя брать не должен, это не его ниша. Он хорошо решает узкую задачу «показать, кто чем занят, и не потерять задачу», и ровно за это его держат годами.

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