Twenty CRM хорош в демо — смотрим, как он держится в рабочем дне

MAATRIX

Twenty CRM залетает в закладки с первого просмотра демо: интерфейс похож на таблицу, но ведёт себя как современное SPA-приложение, GraphQL-API прозрачный, а docker compose up действительно поднимает рабочий инстанс за несколько минут. После десятка лет PHP-CRM с интерфейсами родом из 2012-го это ощущается глотком воздуха. Вопрос в другом — что происходит с этим ощущением через полгода, когда CRM обросла реальными данными, интеграциями и историей обновлений. Разберём честно, где быстрый старт совпадает с рабочей эксплуатацией, а где расходится.

Что видно в демо-режиме и почему это подкупает

Twenty построен на современном стеке: React на фронтенде, NestJS на бэкенде, PostgreSQL как основное хранилище, GraphQL вместо россыпи REST-эндпоинтов. Для человека, который последние годы администрировал SuiteCRM, EspoCRM или тем более 1С-Битрикс, разница в отзывчивости интерфейса заметна сразу — таблица записей скроллится и редактируется без перезагрузки страницы, поиск отрабатывает мгновенно, а UI не выглядит как приборная панель самолёта из десятков вкладок.

Официальный quick-start honestly не врёт про простоту первого запуска: клонировали репозиторий, подняли docker-compose.yml, подождали, пока применятся миграции базы, зашли в браузер и создали воркспейс. Никакого веб-инсталлятора с полусотней полей, никакой ручной настройки виртуального хоста под конкретный PHP-фреймворк. Это реальное преимущество молодого проекта — он не тащит за собой пятнадцать лет обратной совместимости и наслоений архитектурных решений.

Проблема в том, что quick-start по определению описывает первые пятнадцать минут жизни системы. Он ничего не говорит про пятнадцатую неделю, когда в CRM уже тысячи сделок, десяток интеграций и накопившаяся история обновлений. Дальше — как раз то, что в документации быстрого старта либо не упоминается вовсе, либо проговаривается одной строкой мелким шрифтом.

Реальные требования к серверу: что скрыто за `docker compose up`

Быстрый старт создаёт впечатление лёгкого приложения — одна команда, и всё работает. На деле за этой одной командой поднимается не один контейнер, а полноценный набор сервисов: сам сервер (NestJS-приложение), отдельный воркер для фоновых задач (обработка очередей, крон-подобные джобы), PostgreSQL и Redis, который Twenty использует как брокер очередей и кеш. Это архитектура из четырёх взаимозависимых процессов, а не одно бинарное приложение с встроенной SQLite, как у некоторых более лёгких self-hosted инструментов.

Каждый из этих компонентов держит своё резидентное потребление памяти, и когда все они крутятся на одной VPS вместе с nginx и, например, почтовым сервером для уведомлений — суммарный аппетит заметно выше, чем можно предположить по демо-скриншоту с "одной командой для запуска". Точные цифры зависят от объёма данных, числа одновременных пользователей и того, что ещё живёт на той же машине — здесь любые конкретные гигабайты будут лишь ориентиром, а не гарантией. Практический вывод простой: закладывайте под Twenty отдельный ресурс с запасом, а не остаток от более тяжёлого сервиса, и не судите о требованиях по официальному минимальному примеру docker-compose, рассчитанному на демонстрацию, а не на боевую нагрузку с реальным числом пользователей.

Второй нюанс, который быстрый старт не проговаривает: PostgreSQL у Twenty не просто хранилище одной плоской схемы. Проект использует модель, где у каждого воркспейса своя динамическая схема в общей базе — это даёт гибкость кастомных полей без миграций всей БД при каждом изменении структуры сущностей, но одновременно означает, что база растёт не линейно с числом записей, а ещё и с числом кастомизаций и воркспейсов. Для одной компании с одним воркспейсом это почти не ощущается, но само по себе устройство схемы стоит держать в голове при планировании бэкапов и дисков.

Экосистема интеграций и плагинов: где чувствуется молодость проекта

Здесь начинается самое болезненное отличие от зрелых CRM. У Salesforce, HubSpot и даже у открытых, но давно живущих SuiteCRM и EspoCRM за плечами годы стороннего разработческого сообщества: готовые коннекторы к почте, телефонии, бухгалтерии, десятки модулей на маркетплейсе, отработанные интеграции через Zapier/Make с проверенными сценариями. У молодого проекта этого пласта просто физически не могло накопиться — сообществу нужны годы, а не месяцы, чтобы наросли сторонние плагины, стабильные шаблоны интеграций и проверенная документация под конкретные кейсы.

GraphQL API у Twenty сделан аккуратно и им реально приятно пользоваться, но "приятный API" и "готовая интеграция из коробки" — разные вещи. На практике это означает, что вместо установки готового модуля из маркетплейса вы чаще будете писать свой скрипт-мостик: подписка на вебхук Twenty плюс собственный обработчик, который кладёт данные туда, куда нужно. Для команды с внутренней разработкой это не проблема, а даже преимущество — API прозрачный, документация читаемая. Для команды без своих разработчиков это означает либо нанимать подрядчика под каждую интеграцию, либо смиряться с тем, что часть процессов остаётся ручной дольше, чем хотелось бы.

Отдельно стоит сказать про телефонию и email-синхронизацию — типичные больные места молодых CRM. Базовая интеграция с почтой у Twenty есть, но глубина её проработки (учёт edge-кейсов вроде дублей писем, синхронизации вложений, привязки к нескольким сделкам сразу) объективно меньше, чем у продуктов, которые дорабатывали ровно этот функционал годами по багрепортам тысяч пользователей. Перед тем как переезжать всей командой, стоит явно протестировать именно те интеграции, без которых ваш процесс продаж не работает — а не поверить списку "поддерживаемых возможностей" на сайте.

Обновления и breaking changes: цена активной разработки

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

Практическое следствие для самостоятельного хостинга: нельзя относиться к обновлению Twenty так же, как к обновлению давно стабилизировавшегося пакета в LTS-дистрибутиве, где патчи только точечно чинят баги и не меняют поведение. Здесь минорное на вид обновление может принести изменение схемы данных, требующее прогона миграций, или измененный формат ответа API, на который завязан ваш собственный интеграционный скрипт. Разница между "стабильностью версии" и "отсутствием багов" разобрана в отдельном материале про миф о стабильности enterprise-дистрибутивов — тот же принцип применим и здесь: фиксация версий и осознанное решение об апгрейде важнее самой частоты релизов.

Из этого вытекает конкретная дисциплина, которую quick-start не описывает вообще:

• не тяните latest — фиксируйте конкретный тег образа в docker-compose и переходите на новый осознанно, после чтения changelog;
• проверяйте обновление на staging-копии с копией продовой базы перед тем, как катить в бой — особенно если у вас есть кастомные интеграции через API;
• делайте бэкап базы перед каждым обновлением, даже если оно выглядит минорным — миграции схемы необратимы без восстановления из дампа. Показательный разбор того, чем заканчивается автообновление без этой привычки, есть в статье про антипаттерн автообновлений без бэкапа;
• читайте issues и release notes на GitHub перед апгрейдом — сообщество молодого проекта активно репортит регрессии, и часто проблема с конкретной версией уже описана и обсуждается за пару дней до вашего апгрейда.

Ничего из этого не является поводом отказаться от Twenty — но это ощутимо другая эксплуатационная модель по сравнению с CRM, которая обновляется раз в квартал по чётко задокументированному пути миграции.

Операционная рутина: бэкапы, мониторинг, доступ в бою

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

Бэкапы. Поскольку основное хранилище — PostgreSQL, бэкап технически сводится к регулярному pg_dump (или pg_basebackup для более серьёзных объёмов) плюс сохранение файлов, если используется локальное файловое хранилище для вложений вместо S3-совместимого стораджа. Обязательно проверяйте восстановление дампа на тестовом окружении хотя бы раз — из-за модели динамических схем воркспейсов дамп может быть больше, чем кажется на глаз по количеству записей.

Мониторинг очередей. Redis у Twenty используется не только как кеш, а как брокер очередей для воркера. Если воркер отстаёт или падает, фоновые задачи (например, отправка email-уведомлений или синхронизация) начинают копиться незаметно — в интерфейсе всё выглядит рабочим, а фоновые процессы уже не успевают. Стоит настроить хотя бы базовую проверку, что контейнер воркера жив и обрабатывает очередь, а не полагаться на визуальную работоспособность фронтенда как индикатор здоровья всей системы.

Доступ и роли. В открытой версии ролевая модель заметно проще, чем у CRM с многолетней историей корпоративного использования — тонкая настройка прав на уровне отдельных полей или условной видимости записей может быть ограничена по сравнению с тем, что предлагают зрелые Enterprise-редакции других продуктов. Если для вашей компании критична гранулярная модель доступа (например, отдел продаж не должен видеть сделки другого региона), стоит явно протестировать это до миграции, а не полагаться на маркетинговое описание. Общая механика того, за что в принципе платят в Enterprise-версиях open-source продуктов и когда доплата оправдана, разобрана в статье Enterprise против Community: за что берут деньги.

Когда Twenty подходит, а когда стоит присмотреться к альтернативе

Twenty реально хорош для команды, у которой есть свои разработчики или технически подкованный администратор, готовый следить за релизами, тестировать обновления и при необходимости написать недостающую интеграцию через API. Современный стек, читаемый код и активное сообщество — это преимущество именно для такого профиля пользователя. Если вам важен внешний вид и скорость работы интерфейса здесь и сейчас, а процессы продаж не завязаны на десяток сторонних сервисов, миграция вполне оправдана.

Если же у вас нет внутренней разработки, критична стабильность без сюрпризов между обновлениями, или нужны глубокие готовые интеграции с телефонией, бухгалтерией и другими корпоративными системами — стоит взвесить более зрелую альтернативу с другой архитектурой. Например, SuiteCRM — классический PHP-стек, менее современный интерфейс, зато десятилетняя история эксплуатации, устоявшийся набор модулей и предсказуемый цикл обновлений без резких миграций схемы. Это два разных компромисса: скорость разработки и современный UX против зрелости экосистемы и предсказуемости — не "лучше/хуже", а вопрос, что важнее конкретно вашей команде на конкретном этапе.

Отдельно стоит проговорить честно: ни один self-hosted вариант не освобождает от администрирования — вопрос только в том, каким именно администрированием вы готовы заниматься. С Twenty это чаще про слежение за релизами и написание интеграций, с более зрелыми CRM — про работу с более тяжёлым, но предсказуемым стеком и типовыми ошибками, которые давно задокументированы сообществом.

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