Как установить и настроить Taiga на VPS

MAATRIX

Если Jira душит лимитами и ценой за пользователя, а Trello-подобные доски не тянут полноценный скрам с бэклогом и спринтами, вопрос закономерный: можно ли получить нормальный Agile-инструмент без ежемесячной подписки за каждого участника команды. Taiga — open-source платформа для управления проектами, которая умеет и скрам, и канбан, и бэклог с эпиками, и её вполне реально поднять на своём VPS за час. Ниже — рабочий путь: от подготовки сервера до бэкапов и первых пользователей.

Что такое Taiga и когда она оправдана

Taiga — открытая платформа проектного менеджмента, изначально сделанная под нужды Agile-команд: скрам-доски с спринтами и story points, канбан с настраиваемыми колонками, бэклог с эпиками и user stories, встроенный трекер багов (issues), вики для документации по проекту и базовая аналитика (burndown-чарты, отчёты по спринтам). По функциональности это ближе к урезанной Jira, чем к простой канбан-доске вроде Trello или Wekan — если вашей команде хватает списков карточек, Taiga будет избыточной, но если нужен полноценный скрам-процесс с ролями, story points и статусами задач — это её родная территория.

Архитектурно Taiga — это несколько сервисов: бэкенд на Django (taiga-back), фронтенд на Angular (taiga-front), очередь событий на RabbitMQ для realtime-обновлений (taiga-events), и опционально сервис экспорта/импорта проектов (taiga-async). Хранилище — PostgreSQL. Официально проект поддерживает разворачивание через Docker Compose — это и есть самый предсказуемый путь для собственного сервера, дальше в статье используется именно он.

Честно про минусы: сообщество вокруг self-hosted версии не такое большое, как вокруг Jira или GitLab, обновления иногда требуют внимательного чтения changelog (миграции базы между мажорными версиями бывают некрасивыми), а мобильного приложения у Taiga нет — только адаптивный веб-интерфейс. Для команды до 30-40 человек, которая хочет процесс уровня скрама без счёта за лицензии, это рабочий компромисс.

Требования к серверу

Taiga — это несколько контейнеров одновременно (backend, frontend, events, RabbitMQ, PostgreSQL, при желании ещё Redis для кэша), поэтому минимальный VPS для неё заметно тяжелее, чем для одиночного канбана.

На 2 GB RAM Taiga запускается и работает, но с небольшим запасом на пики — PostgreSQL, Django-бэкенд, Angular-статика через Nginx и RabbitMQ вместе легко съедают 1.2-1.5 GB в простое. Если на том же сервере планируете держать что-то ещё (CI-раннер, второй сервис), закладывайте память отдельно.

Перед установкой сервер должен быть готов: обновлена система, настроен SSH по ключу, привязан домен. Если делаете с нуля — пригодятся настройка домена и DNS и установка Docker на Ubuntu 24.04. Проверяем, что Docker на месте:

docker --version
docker compose version

Подготовка окружения и клонирование конфигурации

Официальный способ развернуть Taiga через Docker — репозиторий taiga-docker, в котором лежит готовый docker-compose.yml и файл переменных окружения. Клонируем его в рабочую директорию:

sudo mkdir -p /opt/taiga
cd /opt/taiga
sudo git clone https://github.com/kaleidos-ventures/taiga-docker.git .

Основной файл настроек — .env. Открываем его и правим ключевые параметры:

sudo nano .env

Минимальный набор того, что нужно поменять под себя:

TAIGA_SCHEME=https
TAIGA_DOMAIN=taiga.example.com
SUBPATH=

POSTGRES_USER=taiga
POSTGRES_PASSWORD=сгенерируйте_свой_пароль
POSTGRES_DB=taiga

SECRET_KEY=сгенерируйте_случайную_строку

RABBITMQ_USER=taiga
RABBITMQ_PASS=сгенерируйте_свой_пароль

ENABLE_TELEMETRY=False

Секрет и пароли генерируем командой, а не придумываем вручную:

openssl rand -hex 32

TAIGA_DOMAIN должен совпадать с доменом, на который позже настроите HTTPS. Если планируете отправку email-уведомлений (приглашения участников, оповещения о задачах), в том же .env есть блок EMAIL_* — заполняете SMTP-данные своего почтового сервиса. Без этого блока Taiga работает, но письма-приглашения новым участникам не уйдут — придётся передавать ссылку регистрации вручную.

Запуск контейнеров

Перед первым запуском убедитесь, что в docker-compose.yml порт, на который Taiga будет отвечать локально, не конфликтует с другими сервисами на сервере (по умолчанию Nginx-контейнер Taiga слушает 80). Если на сервере уже стоит системный Nginx или Caddy для других сайтов, порт нужно перенести на localhost и отдельный номер — иначе будет конфликт биндинга.

Открываем docker-compose.yml и в секции taiga-gateway меняем проброс портов на локальный:

  taiga-gateway:
    image: nginx:1.19-alpine
    ports:
      - "127.0.0.1:9000:80"

Дальше поднимаем стек:

cd /opt/taiga
sudo docker compose up -d

Первый запуск занимает несколько минут — бэкенд накатывает миграции базы данных, фронтенд собирает статику. Следим за логами:

sudo docker compose logs -f taiga-back

Дождитесь строки о готовности приложения (обычно упоминание запущенного Gunicorn/Django) без повторяющихся traceback. Если контейнер taiga-back уходит в перезапуск по кругу — почти всегда причина в недоступности PostgreSQL на момент старта или в неверных данных подключения в .env. Проверить состояние базы:

sudo docker compose logs taiga-db
sudo docker compose exec taiga-db pg_isready -U taiga

HTTPS через обратный прокси

Открывать Taiga напрямую по HTTP нельзя — через форму логина идут пароли, через API — токены сессий. Проще всего поставить перед внутренним taiga-gateway внешний Caddy, который сам получит и продлит сертификат Let's Encrypt. Если обратного прокси ещё нет, пошаговая установка есть в статье Caddy с авто-SSL на Ubuntu 24.04.

Конфиг для Taiga в Caddyfile:

taiga.example.com {
    reverse_proxy 127.0.0.1:9000
    encode gzip
}

Перезапускаем:

sudo systemctl reload caddy

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

server {
    listen 443 ssl;
    server_name taiga.example.com;

    ssl_certificate /etc/letsencrypt/live/taiga.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/taiga.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:9000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

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

Первый администратор и настройка проекта

По умолчанию taiga-docker создаёт тестового администратора с логином admin и паролем 123123 — это годится только для проверки, что всё поднялось. Первым делом после логина через https://taiga.example.com меняем пароль администратора в настройках профиля.

Дальше стоит пройтись по базовым шагам:

• Отключить открытую регистрацию (если Taiga только для вашей команды): в .env параметр PUBLIC_REGISTER_ENABLED=False, после изменения — docker compose up -d для применения.
• Создать первый проект — из шаблона Scrum (спринты, story points, бэклог) или Kanban (просто колонки без итераций), в зависимости от процесса команды.
• Пригласить участников — через Настройки проекта → Участники → Пригласить. Если SMTP настроен, письма уйдут автоматически, если нет — Taiga выдаст ссылку-приглашение для ручной отправки.
• Настроить роли — по умолчанию есть Product Owner, Scrum Master/Chief Product Owner, разработчики, тестировщики; роли и права можно править под структуру своей команды.

Для команд, переезжающих с Jira или Trello, у Taiga есть встроенный импортёр — Настройки проекта → Импорт, поддерживает данные из Trello и GitHub Issues напрямую, для Jira потребуется предварительная конвертация экспорта в поддерживаемый формат через сторонние скрипты сообщества (готового официального импортёра из Jira нет).

Бэкапы базы данных и файлов

Taiga хранит всю рабочую информацию — проекты, задачи, комментарии, историю — в PostgreSQL, а прикреплённые файлы (вложения к задачам, аватары) на диске в volume taiga-media. Бэкапить нужно оба.

Дамп базы:

sudo mkdir -p /opt/taiga/backups
sudo docker compose exec -T taiga-db pg_dump -U taiga taiga | gzip > /opt/taiga/backups/taiga-db-$(date +%Y%m%d).sql.gz

Архив media-файлов:

sudo docker run --rm -v taiga_taiga-media-data:/data -v /opt/taiga/backups:/backup \
  alpine tar czf /backup/taiga-media-$(date +%Y%m%d).tar.gz -C /data .

Название volume может отличаться в зависимости от имени проекта Docker Compose — проверить точное имя можно командой docker volume ls | grep taiga.

Автоматизация через cron, скрипт /opt/taiga/backup.sh:

#!/bin/bash
DATE=$(date +%Y%m%d-%H%M)
cd /opt/taiga
docker compose exec -T taiga-db pg_dump -U taiga taiga | gzip > backups/taiga-db-$DATE.sql.gz
docker run --rm -v taiga_taiga-media-data:/data -v /opt/taiga/backups:/backup \
  alpine tar czf /backup/taiga-media-$DATE.tar.gz -C /data .
find backups/ -mtime +14 -delete

sudo chmod +x /opt/taiga/backup.sh
sudo crontab -e
# добавить строку:
0 3 * * * /opt/taiga/backup.sh

Дампы стоит копировать за пределы сервера — на объектное хранилище или другую машину, чтобы бэкап на том же диске не пропал вместе с сервером при аппаратном отказе. Восстановление базы из архива:

gunzip -c /opt/taiga/backups/taiga-db-20260815.sql.gz | sudo docker compose exec -T taiga-db psql -U taiga taiga

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