Taiga на сервере: частые ошибки и решения

MAATRIX

Taiga — одна из немногих open-source систем управления проектами, которая по функциональности реально закрывает Jira: скрам-доски, канбан, бэклог, спринты, эпики, вики и трекер багов в одном месте. Разворачивают её обычно через официальный docker-compose-стек taiga-docker, и на бумаге всё выглядит просто — git clone, docker compose up. На практике стек состоит из семи-восьми контейнеров (backend, frontend, events, protected, gateway, db, rabbitmq, async), и любая мелочь — не тот TAIGA_URL в .env, забытый порт в фаерволе, устаревший образ — валит всю сборку или ломает часть функциональности незаметно. Разбираем конкретные ошибки, с которыми реально сталкиваются на своих серверах, и как их чинить.

Контейнер taiga-gateway не стартует или отдаёт 502

Gateway (nginx внутри стека Taiga) — это точка входа, через которую проходят все запросы к backend, frontend, events и protected. Если он падает или отвечает 502 Bad Gateway, обычно проблема не в самом gateway, а в одном из сервисов, которые он проксирует.

Порядок диагностики:

docker compose ps
docker compose logs taiga-gateway --tail=100
docker compose logs taiga-back --tail=100

Частые причины 502:

• taiga-back ещё не прошёл миграции. При первом запуске backend выполняет python manage.py migrate внутри entrypoint — это может занять минуту-две на слабом диске. Gateway стартует быстрее и первое время честно отдаёт 502, пока backend не поднимется. Подождите 1-2 минуты и проверьте docker compose logs taiga-back | grep -i migrat.
• Неверный TAIGA_URL в .env. Если домен в .env не совпадает с тем, что реально резолвится в браузере, gateway отдаёт CORS-ошибки или редиректит не туда. Проверьте, что TAIGA_URL=https://ваш-домен без завершающего слэша и без http://, если работаете через SSL-терминацию снаружи.
• Контейнер taiga-back упал по OOM. Django + Celery-подобные async-воркеры на сервере с 1-2 ГБ RAM могут не подняться вовсе. Смотрите dmesg | grep -i oom — если видите там taiga, дело в памяти, а не в конфиге.

Если стек развёрнут за Nginx или Traefik как внешним reverse-proxy (частая схема, когда на одном сервере крутится несколько сервисов), убедитесь, что внешний прокси проксирует весь путь, включая /api/, /events/ и корень фронтенда, а не только /. Разбитая маршрутизация между внешним прокси и внутренним gateway Taiga — самая частая причина «сайт открывается, но логин не работает».

Realtime-уведомления и вебсокеты не приходят

Taiga использует отдельный сервис taiga-events для realtime-обновлений через RabbitMQ и WebSocket — это то, что позволяет видеть изменения на доске без перезагрузки страницы. Если доска не обновляется в реальном времени (хотя всё остальное работает), почти всегда виноват один из двух узлов: RabbitMQ или проброс WebSocket через прокси.

Проверка RabbitMQ:

docker compose logs taiga-events --tail=50
docker compose exec taiga-rabbitmq rabbitmqctl status

Если RabbitMQ не отвечает или taiga-events пишет Connection refused, проверьте, что переменные RABBITMQ_USER / RABBITMQ_PASS в .env совпадают с тем, что задано в блоке taiga-rabbitmq того же .env — они должны быть идентичны, а не просто «заполнены».

Если RabbitMQ здоров, а вебсокеты всё равно не доходят до браузера — дело в проксировании. Стандартный location для WebSocket в nginx должен явно апгрейдить соединение:

location /events/ {
    proxy_pass http://127.0.0.1:8000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_read_timeout 3600s;
}

Без proxy_set_header Upgrade и увеличенного proxy_read_timeout соединение обрывается через 60 секунд (дефолтный таймаут nginx), и пользователь видит «пропадающие» уведомления — то работает, то нет. Если вы поднимаете Taiga за Caddy, там апгрейд WebSocket работает из коробки, что иногда упрощает жизнь — сравнение подходов есть в статье про Caddy или Nginx для сервера.

Письма не отправляются: приглашения и уведомления не доходят

Taiga отправляет email при регистрации, приглашении в проект, смене пароля и по подпискам на задачи. Если письма не уходят, backend обычно молча логирует ошибку, а не падает — из-за этого проблему замечают не сразу, когда новый сотрудник жалуется, что не может принять приглашение.

Блок SMTP в .env:

EMAIL_BACKEND=django.core.mail.backends.smtp.EmailBackend
EMAIL_HOST=smtp.yandex.ru
EMAIL_PORT=587
EMAIL_HOST_USER=noreply@ваш-домен.ru
EMAIL_HOST_PASSWORD=пароль_приложения
EMAIL_USE_TLS=True
DEFAULT_FROM_EMAIL=noreply@ваш-домен.ru

Частые ошибки:

• Обычный пароль вместо пароля приложения. Яндекс, Mail.ru и Gmail требуют отдельный пароль приложения для SMTP-авторизации, обычный пароль от почты не сработает.
• EMAIL_USE_TLS и EMAIL_USE_SSL выставлены одновременно. Это конфликт — используйте либо TLS на 587 порту, либо SSL на 465, но не оба флага сразу.
• Исходящий 25/587 порт заблокирован у хостинг-провайдера. Часть дешёвых VPS блокирует исходящий SMTP по умолчанию из-за спам-фильтров — если письма не уходят вообще без ошибок в логах, проверьте это первым делом у вашего провайдера, прежде чем копать конфиг.

Проверить отправку письма можно прямо из контейнера backend, не трогая интерфейс:

docker compose exec taiga-back python manage.py shell -c "
from django.core.mail import send_mail
send_mail('Test', 'Body', None, ['ваш-email@example.com'])
"

Если команда падает с ошибкой — в трейсбеке будет точная причина (auth failed, connection refused, timeout), это быстрее, чем гадать по логам приложения.

Загрузка файлов и аватаров не работает

Taiga хранит вложения и аватары в volume taiga-media, который монтируется в несколько контейнеров сразу (taiga-back, taiga-async, taiga-protected). Проблемы с загрузкой файлов почти всегда связаны с правами доступа или неверным MEDIA_URL.

docker compose exec taiga-back ls -la /taiga-back/media

Если владелец файлов внутри контейнера не совпадает с пользователем, от которого запущен процесс (обычно taiga с UID 1000), запись падает с PermissionError, который виден только в логах backend, а фронтенд просто показывает «не удалось загрузить файл» без деталей. Исправляется так:

docker compose exec -u root taiga-back chown -R taiga:taiga /taiga-back/media

Второй частый случай — файлы загружаются, но не отдаются обратно (404 на прямой ссылке). Это значит, что контейнер taiga-protected, который отвечает за отдачу приватных вложений, не проксируется gateway'ем корректно, либо MEDIA_URL в .env указывает на другой домен/протокол, чем TAIGA_URL. Оба значения должны использовать одинаковый хост и схему (https).

Импорт из Trello, Jira или Asana обрывается на середине

Встроенный импортёр Taiga (доступен через плагины taiga-back для Trello/Jira/Asana) — удобная штука для миграции, но на больших проектах (200+ задач) часто упирается в лимит времени запроса или в лимит памяти воркера.

Симптомы: прогресс-бар импорта зависает, а в логах:

docker compose logs taiga-back | grep -i import

видно WorkerLostError или SoftTimeLimitExceeded. Решения:

• Увеличьте таймаут gateway для эндпоинта импорта (proxy_read_timeout 600s вместо дефолтных 60-90 секунд) — большие проекты импортируются по несколько минут.
• Если сервер маломощный (1 vCPU / 1-2 ГБ RAM), импорт крупных досок стоит запускать в часы низкой нагрузки — процесс парсинга JSON и создания сотен связанных объектов в БД заметно грузит CPU и Postgres одновременно.
• Для действительно больших миграций (1000+ карточек) надёжнее делать импорт частями — экспортировать доски по отдельности, а не всю рабочую область разом. Это не официальная рекомендация, а практический обход ограничения по таймауту.

Если после миграции с другого сервиса вы также поднимаете свой Git — почитайте про частые ошибки Gitea на сервере, стек похож по духу и грабли общие.

Обновление Taiga ломает стек

taiga-docker обновляется через git pull в директории стека и пересборку образов. Проблема в том, что между минорными версиями иногда меняется схема .env (появляются новые обязательные переменные) или структура docker-compose.yml, и бездумный git pull && docker compose up -d --build может привести к несовместимому набору контейнеров.

Безопасный порядок обновления:

cd taiga-docker
docker compose down
git stash          # если .env закоммичен локально — иначе пропустить
git pull
diff .env .env.example    # сверить новые переменные вручную
docker compose pull
docker compose up -d --build
docker compose logs -f

Перед обновлением обязательно снимите бэкап volume с базой данных и media — откатить контейнеры легко, откатить потерянные данные проекта нет. Если Postgres хранится в volume, а не во внешней БД, процедура бэкапа volume разобрана в статье про бэкап Docker volume на сервере. Отдельно проверьте после обновления, что миграции Django прошли до конца — docker compose logs taiga-back | grep -i "no migrations to apply" должно появиться в логах, иначе часть новых полей БД просто отсутствует, и интерфейс будет падать на конкретных страницах (обычно на карточках задач с новыми полями).

Производительность: доска тормозит при росте проекта

На проекте в несколько сотен задач и десятке участников Taiga на дефолтных настройках docker-compose начинает подтормаживать — долгая отрисовка канбан-доски, задержка при перетаскивании карточек. Здесь редко виноват фронтенд — почти всегда узкое место в Postgres или в ресурсах контейнера backend.

Что стоит проверить в первую очередь:

Для проектов с постоянно растущей командой (от 15-20 активных пользователей и нескольких проектов одновременно) практический ориентир — не менее 4 ГБ RAM и 2 vCPU под весь стек Taiga отдельно от других сервисов на сервере; это ориентир по опыту эксплуатации подобных Django+RabbitMQ стеков, а не официальная цифра от разработчиков — на вашей нагрузке потребление может отличаться. Базовая настройка домена и DNS перед разворачиванием стека описана в статье настройка домена и DNS с нуля на Ubuntu 24.04.

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