Redmine в 2026: тормозит, устарел, но заменить его так и не смогли

MAATRIX

Новый тимлид открывает Redmine, видит серую таблицу без единой анимации, страницу, которая перезагружается целиком по каждому клику, и спрашивает: «а почему мы до сих пор на этом?». Ему показывают проект с полутора тысячами задач, дюжиной кастомных трекеров под разные отделы и workflow, где переход тикета из статуса в статус завязан на роль конкретного сотрудника. Вопрос снимается сам собой — не потому что Redmine хорош, а потому что цена ухода от него оказывается выше цены раздражения от интерфейса. Разберём честно: что в Redmine в 2026 году объективно устарело и ломается, а что держит организации на нём годами, даже когда все всё понимают.

Что такое Redmine и почему он вообще всё ещё жив

Redmine — open source система управления проектами и трекер задач на Ruby on Rails, которую с середины 2000-х годов развивает Jean-Philippe Lang и сообщество вокруг проекта. За два десятилетия система пережила несколько поколений Rails — от древних веток фреймворка до современных — и это само по себе многое объясняет: Redmine не переписывался с нуля под модный стек, он рос вместе с экосистемой Ruby, унаследовав от неё и сильные стороны, и часть технического долга.

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

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

Честно: если открыть Redmine рядом с любым современным трекером, разница бросается в глаза за секунду. Это классическое серверное рендеринг-приложение — каждое действие (сменить статус, добавить комментарий, отфильтровать список) чаще всего означает полную перезагрузку страницы, а не точечное обновление через AJAX. Тема оформления менялась, появлялись более current-looking темы от сообщества, но сама модель взаимодействия — таблицы, полная перезагрузка, минимум динамики — не менялась структурно.

Список задач (issue list) — самое частое место работы — остаётся плотной таблицей без drag-and-drop между статусами: чтобы переместить задачу, нужно зайти в неё и сменить статус через форму, а не перетащить карточку между колонками, как в Kanban-подобных инструментах. Формальная Kanban-доска в Redmine есть только через сторонние плагины (например, redmine_agile), и это надстройка поверх изначально не канбан-ориентированной модели данных, а не нативный режим.

Мобильный UX слабый: адаптивной версткой Redmine из коробки почти не занимался, и работа с телефона — это тот же desktop-интерфейс, сжатый до маленького экрана, с горизонтальным скроллом по таблицам. Для команд, где часть работы идёт «на бегу» — сменить статус задачи с телефона, быстро посмотреть, что горит — это ощутимое неудобство по сравнению с трекерами, изначально спроектированными mobile-first.

Наконец, скорость. Не потому, что Ruby медленный сам по себе, а потому что типичная инсталляция Redmine — это старое железо, годами не обновлявшиеся плагины, растущая без чистки база задач и вложений, и Passenger/Puma-процессы, которым banально не докинули памяти при масштабировании команды. Субъективное «тормозит» в большинстве случаев — это не свойство системы, а следствие того, что её эксплуатационная гигиена отставала от роста нагрузки.

Боль с обновлением между мажорными версиями

Вот где Redmine доставляет реальные проблемы администраторам, а не только визуальный дискомфорт пользователям. Redmine жёстко привязан к версии Ruby и версии Rails, на которой собран конкретный релиз, и переход между мажорными версиями Redmine почти всегда означает одновременный переход между версиями Ruby — а это отдельная головная боль, знакомая любому, кто администрировал Ruby-проекты: нужную версию интерпретатора приходится ставить через rbenv или rvm, следить, чтобы системный Ruby не конфликтовал с версией проекта, и пересобирать нативные расширения гемов (особенно те, что зависят от версии OpenSSL или libxml2 на конкретной ОС).

Дальше — Bundler и Gemfile.lock. Обновление Redmine означает не «скачал архив новой версии и перезапустил», а полноценную процедуру: бэкап базы данных и каталога files/ с вложениями, обновление кода, bundle install --without development test, прогон rake db:migrate с обязательным указанием RAILS_ENV=production, очистку кэша (rake tmp:cache:clear), перекомпиляцию ассетов там, где это требуется, и только потом перезапуск приложения. Пропустить любой из шагов — типичная причина «после обновления всё сломалось».

Отдельная категория боли — плагины. Экосистема Redmine живёт на сторонних плагинах (redmine_agile, плагины экспорта в разные форматы, интеграции с git/SVN хостингами, кастомные workflow-надстройки), и далеко не все они синхронно обновляются под новую мажорную версию ядра. Обновили Redmine — а любимый плагин команды упал с ошибкой совместимости, потому что его автор давно не подтверждал поддержку текущей ветки. В результате многие организации годами сидят на устаревшей версии не из консерватизма, а потому что критичный для процесса плагин не гарантированно переживёт апгрейд, и тестировать это приходится вручную на стейджинге, а не по документации — она такие случаи описывает не всегда.

Экосистема плагинов и кастомизации — актив, который держит на месте

При этом та же экосистема плагинов и кастомизации — главная причина, по которой Redmine из проекта так просто не убрать. Система изначально спроектирована гибко: свои трекеры (Bug, Feature, Task — и любые кастомные типы задач под процесс конкретной компании), свои статусы, свои workflow-переходы между статусами, которые можно настраивать отдельно для каждой комбинации «трекер + роль» — то есть разработчик и менеджер могут видеть разный набор допустимых переходов для одной и той же задачи.

Кастомные поля (custom fields) — ещё один слой, за годы обрастающий бизнес-логикой: поля привязки к внутренним ID из ERP, поля для расчёта стоимости работ, поля-справочники, синхронизируемые с внешними системами. У организаций с историей в несколько лет это не «пара галочек в настройках», а часто сотни полей, распределённых по десяткам проектов, — и перенос всего этого на другую платформу означает не миграцию данных, а пересборку модели данных с нуля.

К этому добавляется REST API (доступен для большинства сущностей — задач, проектов, пользователей, вики-страниц), через который у многих компаний годами держатся интеграции с внутренними системами: автоматическое создание задач из формы поддержки, синхронизация с git-хуками, отчётность, вытягиваемая во внешние BI-инструменты. Разорвать такую интеграцию при миграции — не техническая мелочь, а отдельный проект с риском сломать процесс, который работал молча и без нареканий годами.

Наконец — вики и накопленная документация. У каждого проекта в Redmine есть встроенная вики с версионированием страниц, и в старых инсталляциях это часто фактическая база знаний компании — годы записей, ссылок между задачами и страницами, вложений. Перенести это можно, но требует отдельного инструмента экспорта и ручной проверки, что ничего не потерялось при конвертации разметки.

Установка и требования в 2026: с чем реально столкнётесь

Разворачивать Redmine сегодня разумнее не из пакета дистрибутива (версия в репозиториях Debian/Ubuntu почти всегда заметно отстаёт от актуальной ветки), а из исходников с официального сайта проекта или через готовый Docker-образ — второй путь сейчас выбирают чаще, потому что он снимает часть боли с версиями Ruby: образ уже собран под нужную связку Ruby/Rails, и не приходится вручную городить rbenv.

При установке из исходников порядок стандартный: скачать архив нужной ветки, настроить config/database.yml с параметрами подключения к БД, сгенерировать секретный токен (bundle exec rake generate_secret_token), прогнать bundle exec rake db:migrate RAILS_ENV=production, при необходимости загрузить демоданные локализации (REDMINE_LANG=ru rake redmine:load_default_data). Веб-часть в проде поднимается через Puma или Phusion Passenger за Nginx как обратным прокси с терминацией TLS — связка mod_rails/Passenger внутри Apache тоже жива, но сегодня чаще встречается в старых инсталляциях, а не в новых.

Из баз данных официально поддерживаются MySQL/MariaDB и PostgreSQL — выбор обычно диктуется тем, что уже эксплуатируется в инфраструктуре компании. SQLite тоже технически работает, но для продакшна с многопользовательской нагрузкой не подходит — блокировки на запись быстро становятся узким местом при параллельной работе нескольких людей.

По требованиям к ресурсам Redmine относительно бережлив по сравнению с более тяжёлыми современными платформами вроде Jira-класса или BPM-систем: это, по сути, Ruby-процессы приложения плюс СУБД, без обязательного отдельного поискового кластера или очереди сообщений. Полнотекстовый поиск встроен на уровне запросов к БД и на больших объёмах задач и вложений ощутимо теряет в скорости — для серьёзного поиска по вложенным файлам штатных средств может не хватать, и часть инсталляций решает это через внешние индексаторы, подключаемые отдельно.

Когда оставаться на Redmine оправдано, а когда пора уходить

Оставаться на Redmine стоит, если у вас:

• Множество проектов с разной структурой трекеров, статусов и ролевых workflow, годами настроенных под реальные процессы — переезд означает не перенос задач, а пересборку всей этой логики заново.
• Кастомные плагины и интеграции через REST API, разрыв которых обойдётся дороже, чем неудобство интерфейса.
• Команда, где часть людей администрирует Redmine годами и уверенно ориентируется в Ruby-стеке — им система не мешает работать, даже если выглядит не современно.
• Регулируемая среда или закупочные процедуры, где смена основного рабочего инструмента — отдельный долгий процесс согласования, а не решение одного человека.
• Большой объём вики-документации внутри проектов, для которой нет простого автоматического пути переноса без потерь разметки.

Пора задуматься о миграции, если:

• Команда быстро растёт, новым сотрудникам тяжело онбордиться в интерфейс из прошлого десятилетия, и это заметно замедляет наём и адаптацию.
• Вам критично нужен нативный Kanban с drag-and-drop и живые обновления без перезагрузки страницы — а не костыль через плагин поверх таблично-ориентированной модели.
• Специалист, который держал Ruby-стек и разбирался во внутренностях Redmine, ушёл или собирается уходить, а найти замену на рынке год от года сложнее.
• Вы уже сравнивали более современные трекеры вроде Plane и Taiga и понимаете, что за сопоставимые деньги на сервер получаете активно развивающийся стек без Ruby-специфичного технического долга.
• Экономика вопроса вообще не сходится с интуицией: прежде чем решать, стоит прикинуть цифры так, как это делает разбор своей Jira против облачной подписки — во многих случаях дело не в принципе self-hosted, а в конкретной команде и её размере.

Redmine здесь не единственный пример системы, которую не убирают из-за накопленного актива, а не из любви к интерфейсу — похожая логика подробно разобрана применительно к Request Tracker: другой стек, другая задача, но тот же принцип «переезд дороже неудобства».

Как выглядит путь миграции, если решение принято

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

1. Выгрузить данные через REST API (задачи, комментарии, вложения, кастомные поля) в промежуточный формат, а не пытаться работать напрямую со схемой БД Redmine — она не документирована как стабильный публичный контракт и меняется между версиями.
2. Отдельно экспортировать вики каждого проекта — штатного массового экспорта в удобный формат может не хватать, и часть контента почти всегда приходится переносить и проверять вручную.
3. Спроецировать трекеры, статусы и workflow Redmine на модель целевой системы, заранее решив, что делать с полями, для которых нет прямого аналога — где-то придётся смириться с потерей части метаданных или свести несколько кастомных полей в одно.
4. Держать старую и новую систему параллельно на переходный период: новые задачи сразу заводить в новой системе, к архиву Redmine оставить доступ только на чтение.
5. Переносить интеграции (git-хуки, внешние отчёты, формы создания задач) по одной, с проверкой каждой — это самое частое место, где при поспешном переезде что-то тихо перестаёт работать и обнаруживается через месяц.
6. Не выключать старый Redmine сразу — оставить его в режиме архива на несколько месяцев, пока не убедитесь, что вся нужная история действительно перенесена.

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