Три причины уйти с Discourse на Misago и одна причина остаться

MAATRIX

Discourse — фактический стандарт self-hosted форума, и мы уже разбирали его установку, требования к RAM и типовые грабли в отдельных статьях. Но у стандарта есть цена: Ruby on Rails, Sidekiq и увесистый rebuild при каждом апдейте, который на скромном VPS периодически падает по памяти. Misago — форум на Python и Django, решающий ту же задачу заметно тише: без геймификации, без форсированной пересборки ассетов при каждом обновлении и на стеке, с которым чаще уже знаком администратор, привыкший к Python. Разберём три причины, по которым имеет смысл присмотреться к Misago, и одну причину, по которой переезд может оказаться преждевременным.

Discourse и Misago: разные технологии для одной задачи

Discourse — Ruby on Rails приложение с PostgreSQL и Redis внутри, распространяемое в первую очередь как Docker-образ, который управляется скриптом launcher. Мы разбирали его архитектуру и требования к серверу подробно в статье сколько RAM нужно для Discourse — коротко: минимум 2 ГБ по официальной документации, комфортно — от 4 ГБ, и большая часть аппетита приходится на процесс ./launcher rebuild app, который пересобирает контейнер целиком.

Misago — независимый проект на Python и Django, который развивает по большей части один core-разработчик (Rafał Pitoń) при участии сообщества. Backend — Django с REST API, часть интерфейса до сих пор на React (начиная с релиза 0.39 часть страниц, например категории, переведена на серверный рендеринг через Django-шаблоны — проект постепенно снижает зависимость от React). Официальный способ развёртывания — репозиторий misago_docker с обёрткой appctl поверх docker-compose: отдельные контейнеры для приложения, PostgreSQL, Redis, Celery (фоновые задачи) и nginx-прокси с автоматическим Let's Encrypt. Никакого Elasticsearch — поиск строится на PostgreSQL. Код распространяется под GPLv2 — копилефт-лицензия: если вы форкаете Misago и раздаёте изменённую версию как публичный сервис, обязаны публиковать исходники доработок, как и в случае с другим GPL/AGPL self-hosted софтом.

Ниже — по каждому пункту подробнее, с честными оговорками там, где маркетинг обычно их опускает.

Причина первая: Python и Django вместо Ruby on Rails

Если вы или ваша команда уже пишете на Python — автоматизацию, скрипты деплоя, внутренние сервисы, — читать и патчить код Misago технически проще, чем разбираться в объёмном Rails+Ember приложении Discourse. Сама документация Discourse прямо предупреждает, что это не «Django-приложение», которое легко встроить во что-то своё — Discourse спроектирован как самодостаточный продукт с собственной моделью пользователей, сессий и прав, не рассчитанный на глубокую кастомизацию силами обычного администратора.

У Misago для точечных изменений не нужно пересобирать весь фронтенд-пайплайн. Есть несколько уровней кастомизации без форка ядра:

• settings_override.py — переопределение конфигурации Django поверх стандартного settings.py, без правки основного кода.
• urls_override.py — добавление собственных маршрутов.
• Каталог misago/theme/ — статика и шаблоны темы, применяются командой ./appctl collectstatic без полной пересборки контейнера.
• scripts.html — точка для вставки собственного HTML/JS до инициализации фронтенд-приложения Misago, полезно для аналитики или мелких виджетов без пересборки сборки Vite.
• Плагины через Django-приложения — начиная с релиза 0.39 система плагинов Misago переработана и стала заметно удобнее прежней, что сам проект отмечает как одну из ключевых причин релиза.

Ничего из этого не требует держать в голове Ember CLI или разбираться, где в дереве Rails-приложения Discourse искать нужный view — если Python и Django вам уже знакомы, порог входа объективно ниже.

Причина вторая: обновления без форсированной тяжёлой пересборки

У Discourse обновление — это git pull и ./launcher rebuild app: полная пересборка контейнера, компиляция ассетов через Ember CLI, миграции базы и прекомпиляция Rails-приложения. Мы уже писали, что на этом этапе кратковременно требуется 1,5–2 ГБ RAM сверх того, что уже держат Postgres и Redis, и на сервере с 1 ГБ без свопа rebuild падает по OOM почти гарантированно — подробнее в статье про частые ошибки Discourse на сервере. На время rebuild (обычно 10–20 минут) форум недоступен, если не настроен отдельный staging-контур.

У Misago рутинное обновление — это ./appctl upgrade: подтягивает новую версию и накатывает миграции. Полная пересборка образов — отдельная команда ./appctl rebuild (пересобирает и перезапускает контейнеры Misago и Celery) или ./appctl rebuildall (все контейнеры разом), которую запускают осознанно — когда меняли конфигурацию, а не при каждом обычном апдейте версии.

Важная честная оговорка: официальный минимум для Docker-развёртывания Misago по документации misago_docker — тоже 2 ГБ RAM, то есть по стартовой цифре разница с Discourse не такая, как иногда преподносят в маркетинге self-hosted альтернатив. Реальная разница не в минимальном пороге, а в форме потребления ресурсов: у Discourse минимум 2 ГБ гарантирует только базовый запуск, а сам процесс апдейта регулярно упирается в этот же потолок повторно. У Misago схожего встроенного «пикового» сценария в задокументированном процессе рутинного апдейта нет — тяжёлая пересборка образов не привязана к каждому релизу.

Стек фоновых задач у обоих присутствует — не путайте «легче интерфейс» с «нет фоновых воркеров»: у Discourse это Sidekiq, у Misago — Celery, оба нужны рабочему форуму для писем, уведомлений и индексации, и оба потребляют память сверх базового веб-процесса.

Причина третья: интерфейс без геймификации и лишнего шума

Discourse из коробки включает систему доверия пользователей (trust levels от 0 до 4) и бейджи за достижения — это часть автоматической модерации: чем выше уровень доверия, тем больше прав получает пользователь без ручного вмешательства администратора, а бейджи мотивируют к активности видимым прогрессом. Для публичного сообщества, которое должно расти само, это полезная автоматика.

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

Это компромисс, а не однозначный выигрыш: trust levels Discourse — не только про мотивацию, но и про автоматическую антиспам-защиту (новым и малоактивным аккаунтам автоматически урезаны права на ссылки, изображения, количество сообщений в час). У Misago для защиты от спама и накрутки придётся либо настраивать модерацию вручную, либо ставить сторонние средства (капча, антиспам-плагины) — готовой многоуровневой системы доверия из коробки не будет.

Причина остаться: у Discourse экосистема плагинов, которой у Misago пока нет

Это единственный весомый аргумент против переезда, и его стоит признать прямо. У Discourse — годы истории публичного каталога плагинов и тем на meta.discourse.org и в GitHub-организации Discourse: встроенный чат, календарь событий, назначение тем ответственным, пометка «решено», SQL-эксплорер данных, интеграции с Akismet против спама, десятки тем и компонентов оформления, готовые SSO-коннекторы под разные провайдеры. Если вам нужна конкретная функция — велика вероятность, что кто-то её уже реализовал в виде официального или community-плагина, который просто ставится и настраивается.

У Misago система плагинов относительно молода: как отмечено выше, её заметно переработали и усилили только в релизе 0.39. Это значит, что каталог готовых сторонних расширений объективно меньше и моложе, чем у Discourse, — под специфическую интеграцию (нестандартный SSO-провайдер, платёжный шлюз, мост в мессенджер) с высокой вероятностью придётся писать код самому, а не искать готовое решение. Если ваш форум уже держится на конкретных плагинах Discourse (чат, назначения, эксплорер данных) и без них рабочий процесс развалится — это ровно тот случай, когда переезд на Misago нужно отложить: время на самостоятельную разработку недостающей функциональности с высокой вероятностью съест всю экономию на ресурсах и простоте стека.

Установка Misago: docker-compose и appctl за один вечер

Официальный путь — репозиторий misago_docker, который сам описывает себя как способ поднять форум с HTTPS и бэкапами «за 15 минут при минимальных усилиях». На практике с настройкой DNS, ожиданием Let's Encrypt и первой проверкой закладывайте вечер, а не 15 минут.

git clone https://github.com/rafalp/misago_docker.git --depth=1
cd misago_docker
./appctl setup

Мастер настройки ./appctl setup спросит домен (должен уже указывать на сервер), часовой пояс и данные администратора, после чего сам установит зависимости, соберёт контейнеры, поднимет базу и настроит ежедневный cron для обслуживания и бэкапов. После завершения форум открывается по указанному домену.

Основные команды appctl, с которыми предстоит работать регулярно:

Бэкапы: ручной запускается командой и кладёт архив manual-ГГГГММДДЧЧММСС.tar.gz (дамп базы плюс каталог с медиафайлами) в backups/; автоматический бэкап с префиксом auto- выполняется по cron ежедневно и хранится 10 дней, дальше старые копии удаляются сами.

Обязательно настройте почту — без рабочего SMTP пользователи не получат письма активации, уведомления, не смогут подтвердить смену пароля или восстановить забытый — это делается через мастер настройки или позже в админ-панели, ровно та же логика, что и у Discourse.

Из практических рекомендаций официальной документации: отключить вход под root на сервере, поставить fail2ban против перебора паролей, и для производительности Redis отключить Transparent Huge Pages в ядре:

echo never > /sys/kernel/mm/transparent_hugepage/enabled

Эту команду стоит добавить в /etc/rc.local или соответствующий systemd-юнит, чтобы настройка не слетала после перезагрузки сервера.

Миграция с Discourse на Misago: честно о том, чего нет

Здесь стоит быть предельно откровенным: готового официального импортёра из Discourse в Misago (и в обратную сторону) в публичных репозиториях проекта нет. Discourse, для сравнения, поддерживает импорт из ряда движков (phpBB, vBulletin, SMF и другие) через community-скрипты — но обратного пути специально под Misago никто не поддерживает.

Практически перенос обсуждений выглядит так: выгружаете данные из Discourse (через встроенный экспорт базы или Data Explorer API) и пишете собственный скрипт, который раскладывает пользователей, категории, темы и посты в модели Django через REST API или напрямую в базу Misago. Для форума на несколько сотен тем это реалистичная задача на выходные для человека, знакомого с Django ORM. Для форума с историей в тысячи тем, сложной структурой категорий и трастовыми уровнями, которые не на что переносить (у Misago их просто нет как сущности), — это уже полноценная задача по разработке с ручной проверкой результата, а не «прогнать скрипт и готово».

Общая логика бэкапа и переноса базы между серверами, если вы уже прикидываете перенос инфраструктуры, а не только контента, разобрана в статье про миграцию базы данных между серверами — сам процесс переноса Postgres-дампа применим что для Discourse, что для Misago, разница только в том, что схема данных у них разная и один в другой не встаёт напрямую.

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

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