Как разместить Kanboard на собственном сервере в 2026 году: SQLite, плагины и безопасные обновления
Практическое руководство по самостоятельному размещению Kanboard: Docker, порты, постоянные данные, TLS, безопасность, резервное копирование и проблемы, которые мешают использовать систему в production. С проверками.
Неудачное развёртывание Kanboard не всегда завершается сбоем. Система может показывать страницу входа, пока SQLite не может записать данные из-за неправильного владельца подключённого каталога данных. Поэтому сначала выполните сквозную проверку: замените учётные данные по умолчанию, создайте проект и задачу, переместите её между колонками, загрузите файл и проверьте работу одного установленного плагина.
Эта проверка соответствует заявленному назначению Kanboard: минималистичная kanban-доска на базе SQLite. Она также позволяет раньше, чем проверка доступности, обнаружить отсутствующие зависимости, неправильные предположения о reverse proxy и эфемерные данные.
Отделите Kanboard от его зависимостей
Минимальная ответственная топология Kanboard включает один private listener на порту 80, маршрут ingress и документированную границу состояния. Локальное требование runtime — доступный для записи volume данных и опциональный SMTP. Явно зафиксируйте жизненный цикл, чтобы перенос Kanboard между хостами не менял поведение системы незаметно.
Проверьте топологию с чистого клиента: замените учётные данные по умолчанию, создайте проект и задачу, переместите её между колонками, загрузите файл и проверьте работу одного установленного плагина. Во время проверки наблюдайте за блокировками SQLite, объёмом вложений, фоновыми действиями и поведением плагина при одновременной работе пользователей. Результат покажет, что именно требует улучшения: память, хранилище, сеть или отдельный worker, — вместо того чтобы подталкивать к произвольному увеличению ресурсов контейнера.
Домены, proxy-заголовки и порт 80
Выпуск TLS-сертификата — только половина маршрута Kanboard. Обслуживайте доску по HTTPS и задайте URL приложения, если он нужен плагинам. Направляйте трафик внутри системы на порт 80 и передавайте внешнюю схему, чтобы сгенерированные URL и secure cookies оставались согласованными.
Выполните полный сценарий Kanboard из чистой сети, а не только откройте корневую страницу. Ошибку 502 или сбой сертификата можно локализовать с помощью автоматической настройки домена и TLS. Если трафик доходит до процесса, а SQLite не может записать данные из-за неправильного владельца подключённого каталога данных, диагностируйте это условие в месте его возникновения, а не добавляйте новые редиректы.
Сделайте запуск Kanboard воспроизводимым
Запуск в production-окружении намеренно выглядит скучно: именованное состояние, явно заданный порт и отсутствие секретов внутри image.
docker run -d \
--name kanboard \
--restart unless-stopped \
-p 127.0.0.1:80:80 \
-v kanboard-data:/var/www/app/data \
kanboard/kanboard:latest
Этот пример задаёт базовую конфигурацию, а не полный supporting stack. Перед открытием доступа проверьте локальное требование: доступный для записи volume данных и опциональный SMTP. Проверьте фактически подключённые mounts и listener, затем попробуйте заменить учётные данные по умолчанию, создать проект и задачу, переместить её между колонками, загрузить файл и проверить работу одного установленного плагина. До следующего перезапуска зафиксируйте рабочую версию image.
Наблюдайте за нагрузкой, а не только за контейнером
Для Kanboard нужно мониторить не процесс, а транзакцию: заменить учётные данные по умолчанию, создать проект и задачу, переместить её между колонками, загрузить файл и проверить работу одного установленного плагина. Сопоставляйте её latency и error rate с блокировками SQLite, объёмом вложений, фоновыми действиями и поведением плагина при одновременной работе пользователей, чтобы alert указывал на ограниченный компонент.
Репетиция обновления должна учитывать, что перед обновлением image Kanboard миграции базы данных и совместимость плагинов требуют snapshot. Восстановите данные, выполните миграцию и запустите транзакцию до замены версии в production. Если SQLite не может записать данные из-за неправильного владельца подключённого каталога данных, не удаляйте данные ради успешного запуска; последовательно сравните версию, variables, mounts и доступность зависимостей.
Проверьте развёртывание Kanboard полностью
Production-проверку Kanboard должен уметь выполнить человек, который не занимался развёртыванием. Передайте ему зафиксированную версию, нечувствительную тестовую учётную запись и следующую задачу: заменить учётные данные по умолчанию, создать проект и задачу, переместить её между колонками, загрузить файл и проверить работу одного установленного плагина. Если инструкции требуют недокументированного доступа к shell, сервис ещё не готов к эксплуатации.
Повторите проверку после замены только контейнера. Затем восстановите базу данных SQLite, загруженные файлы, плагины и конфигурацию в пустую инфраструктуру и убедитесь, что проекты, история задач, пользователи, вложения и плагины восстановились, а восстановленная доска принимает новую задачу. Во время обоих успешных запусков измеряйте блокировки SQLite, объём вложений, фоновые действия и поведение плагина при одновременной работе пользователей; неожиданные различия часто указывают на отсутствующий cache, index, worker или mount с данными.
Добавьте проверку отказоустойчивости: отправьте безвредные данные, близкие к ограничению ресурса или формата, связанному с этим условием: SQLite не может записать данные из-за неправильного владельца подключённого каталога данных. Kanboard должна выдавать понятную ошибку, сохранять существующее состояние и восстанавливаться после возврата корректного условия. Сохраните временные метки и соответствующие строки логов, предварительно удалив секреты. Эти сведения станут эталоном для следующего изменения image или конфигурации.
Volumes — только первый уровень восстановления
Составьте recovery manifest для Kanboard: база данных SQLite, загруженные файлы, плагины и конфигурация. Подключите /var/www/app/data до bootstrap, запишите безвредные тестовые данные и замените контейнер, чтобы доказать фактическую постоянность этого пути. Проверьте права владельца и свободное место сейчас: подключённый, но недоступный для записи путь практически ничем не отличается от отсутствия persistence.
Создавайте резервные копии в failure domain, отдельном от работающего сервера. Восстановите Kanboard из зафиксированного image и убедитесь, что проекты, история задач, пользователи, вложения и плагины вернулись, а восстановленная доска принимает новую задачу. Руководство по persistent volumes поможет перенести эту практику в политику snapshot и хранения резервных копий.
Защитите ценную часть Kanboard
Безопасное развёртывание Kanboard начинается с сокращения полномочий. Не оставляйте стандартные учётные данные admin/admin; сразу удалите admin/admin, ограничьте доступ к проектам и проверьте плагины, прежде чем предоставлять им доступ к production-данным.
В этой базовой конфигурации Kanboard не требует обязательного bootstrap-секрета; вместо этого защитите фактическую учётную запись администратора или upstream-аутентификацию. Ограничьте административные маршруты, используйте private DNS для зависимостей и проверьте каждый bind mount. При централизованной отправке логов отфильтруйте секреты и приватное содержимое до того, как они покинут сервер.
Где Dockup упрощает работу с Kanboard
Template Dockup должен описывать image, порт 80, mounts, интервалы проверки состояния, домен, TLS и передачу секретов. Dockup должен сохранять настройки runtime Kanboard, пока оператор проверяет локальное требование: доступный для записи volume данных и опциональный SMTP. То же развёртывание можно использовать на серверах Dockup или на подключённых ресурсах заказчика.
После публикации маршрута примените публичную настройку и попробуйте заменить учётные данные по умолчанию, создать проект и задачу, переместить её между колонками, загрузить файл и проверить работу одного установленного плагина. Создавайте резервные копии базы данных SQLite, загруженных файлов, плагинов и конфигурации и включите процедуру восстановления в операционный план; эти обязанности Kanboard сохраняются и после подготовки инфраструктуры.
Часто задаваемые вопросы
Что нужно Kanboard для развёртывания в production?
Направьте контейнер Kanboard на порту 80 через один HTTPS origin. Локальное требование runtime — доступный для записи volume данных и опциональный SMTP. Не считайте Kanboard готовой, пока не сможете заменить учётные данные по умолчанию, создать проект и задачу, переместить её между колонками, загрузить файл и проверить работу одного установленного плагина.
Какие данные Kanboard нужно включать в резервную копию?
Сохраняйте /var/www/app/data и включайте базу данных SQLite, загруженные файлы, плагины и конфигурацию в один recovery manifest. Восстановление Kanboard можно считать успешным только после того, как вернулись проекты, история задач, пользователи, вложения и плагины, а восстановленная доска приняла новую задачу.
Нужен ли Kanboard HTTPS за reverse proxy?
Используйте HTTPS для публичного origin Kanboard, а порт 80 оставьте во внутреннем маршруте. Корректно примените настройку Kanboard: обслуживайте доску по HTTPS и задайте URL приложения, если он нужен плагинам. Для Kanboard HTTPS защищает учётные данные и пользовательское содержимое при передаче и обеспечивает согласованное поведение клиента, зависящее от origin.
Как тестировать обновление Kanboard?
Восстановите текущее состояние Kanboard в изолированном развёртывании, примените кандидатную версию и повторите приёмочную транзакцию. Уделите особое внимание тому, что перед обновлением image Kanboard миграции базы данных и совместимость плагинов требуют snapshot. Сохраняйте предыдущий image Kanboard, пока не будут понятны границы миграции данных и rollback.