Две встречи в месяц: нужен ли ради них собственный Rallly

MAATRIX

«Когда вам удобно на неделе?» — и понеслось: пять человек, семь вариантов дат, три часовых пояса, половина отвечает через два дня. Rallly — open-source аналог Doodle, который решает именно эту задачу: создаёте опрос с вариантами времени, рассылаете ссылку, каждый отмечает удобные слоты, система показывает пересечение. Вопрос в другом — стоит ли ради двух встреч в месяц поднимать под это отдельный сервер, или это тот случай, когда самостоятельный хостинг создаёт больше работы, чем экономит.

Что делает Rallly и чем он лучше опроса в чате

Rallly — это не календарь и не система бронирования переговорок, а именно голосование за время между несколькими участниками. Логика простая: организатор создаёт опрос («Стендап на неделе», «Созвон с клиентом по контракту»), добавляет несколько вариантов дат и времени, отправляет ссылку. Каждый участник — без регистрации, просто по ссылке — отмечает, какие слоты ему подходят, какие «может быть», какие точно нет. Организатор видит сводную таблицу и выбирает финальное время одним кликом, после чего участникам можно разослать подтверждение.

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

От Doodle и Calendly Rallly отличается тем, что это опрос про конкретную встречу с ограниченным набором дат, а не публичная страница «вот мои свободные слоты, бронируйте», как у Cal.com или Calendly. Если вам нужно, чтобы клиенты сами записывались на приём в удобный им слот, это больше похоже на задачу, которую я уже разбирал в статье про установку и настройку Cal.com на VPS — там другой сценарий использования, хотя стек развёртывания похож.

Технически Rallly — это Next.js-приложение с PostgreSQL в качестве хранилища, распространяется под открытой лицензией, разворачивается через Docker Compose. Есть облачная версия (rallly.co) с бесплатным тарифом и платными планами для команд, и есть self-hosted вариант — тот, о котором дальше пойдёт речь.

Что нужно, чтобы поднять Rallly на своём сервере

Минимальный self-hosted стек — это контейнер самого приложения плюс PostgreSQL. Типичный docker-compose.yml выглядит примерно так (набор переменных окружения может отличаться от версии к версии — сверяйтесь с актуальной документацией проекта перед разворачиванием):

services:
  rallly:
    image: lukevella/rallly:latest
    restart: unless-stopped
    ports:
      - "3000:3000"
    environment:
      DATABASE_URL: postgres://rallly:changeme@db:5432/rallly
      SECRET_PASSWORD: "замените-на-случайную-строку-минимум-32-символа"
      NEXT_PUBLIC_BASE_URL: https://meet.example.com
      SUPPORT_EMAIL: support@example.com
      SMTP_HOST: smtp.example.com
      SMTP_PORT: 587
      SMTP_SECURE: "false"
      SMTP_USER: no-reply@example.com
      SMTP_PWD: "пароль-от-почтового-ящика"
      NOREPLY_EMAIL: no-reply@example.com
    depends_on:
      - db
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: rallly
      POSTGRES_PASSWORD: changeme
      POSTGRES_DB: rallly
    volumes:
      - rallly-db:/var/lib/postgresql/data
volumes:
  rallly-db:

Дальше — обратный прокси с TLS (Nginx или Caddy), домен, и рабочая почта для отправки приглашений и уведомлений о новых голосах — без SMTP приложение частично работает, но участники не получат письмо со ссылкой на опрос, и вам придётся рассылать её вручную. По железу Rallly крайне нетребователен: это лёгкое Next.js-приложение с редкими короткими запросами к базе, а не сервис с постоянной нагрузкой. Ресурсов уровня «пара гигабайт памяти и один виртуальный ядро» хватает с большим запасом — по порядку величины это ближе к оценке из статьи сколько RAM нужно для Cal.com, только нагрузка у Rallly ещё легче, потому что нет логики бронирования и синхронизации с внешними календарями.

Отдельная забота — бэкапы PostgreSQL (pg_dump по расписанию плюс копия конфига), обновления образа при выходе новых версий и мониторинг, чтобы узнать о падении сервиса раньше, чем участник опроса напишет «а куда делась ссылка». Именно эта часть — не сама установка, а её сопровождение — и есть настоящая цена self-hosted решения, даже если сервис используется всего пару раз в месяц.

Приватность расписания: что на самом деле утекает в облачные сервисы

Главный честный аргумент за self-hosted вариант — не деньги, а данные. Опрос о времени встречи — это, на первый взгляд, безобидная информация: пара дат, список имён и email-адресов участников. Но в совокупности такие опросы формируют довольно чувствительную картину: кто с кем встречается, как часто, в какие дни недели у команды переговоры с конкретным клиентом или партнёром. Для юридической фирмы, которая согласовывает время созвона по делу, для финансового консультанта, планирующего встречи с клиентами, или для команды, ведущей закрытые переговоры о сделке, сам факт и частота встреч — это уже метаданные, которые в идеале не должны лежать на сервере стороннего SaaS с непонятной юрисдикцией и политикой хранения логов.

Облачный Rallly и аналогичные сервисы, как правило, честно описывают в политике конфиденциальности, что хранят email участников, IP-адреса при голосовании и историю опросов какое-то время после закрытия. Для большинства команд это не проблема — данные не более чувствительны, чем содержимое рабочей переписки в любом мессенджере. Но если у вас есть юридическое требование (например, требования по обработке персональных данных клиентов) или просто внутренняя политика «ничего, связанное с расписанием топ-менеджмента, не уходит на сторону», self-hosted вариант закрывает вопрос полностью: данные не покидают ваш сервер и вашу юрисдикцию, вы сами решаете срок хранения и настраиваете логирование доступа.

Здесь стоит различать два уровня чувствительности. Опрос «когда собраться на корпоративный созвон по итогам месяца» — это низкий риск, ради него разворачивать инфраструктуру избыточно. Опрос «когда встретиться с клиентом по делу о разводе» или «когда провести due diligence с потенциальным инвестором» — совсем другая история, и здесь довод про приватность данных перевешивает любые аргументы про экономию времени на установке.

Порог окупаемости: частота встреч и размер команды

Три переменные определяют, окупается ли отдельный сервер под Rallly: как часто вы создаёте опросы, сколько человек участвует, и насколько чувствительны данные о расписании. Если свести это в простую таблицу ориентиров (это именно ориентиры для принятия решения, а не жёсткие пороги — у вас конкретная ситуация может отличаться):

Ключевой момент: частота сама по себе редко становится решающим фактором, если только у вас уже не работает половина внутренних сервисов на своей инфраструктуре — почта, чат, файловое хранилище, трекер задач. В этом случае добавить ещё один лёгкий контейнер почти ничего не стоит: прокси и TLS уже настроены, бэкапы уже автоматизированы, мониторинг уже смотрит за всеми сервисами разом. Именно поэтому self-hosted Rallly чаще всего появляется не как отдельное решение «нам нужен планировщик встреч», а как логичное дополнение к уже существующему self-hosted стеку — том самом, из-за которого читатели этого блога вообще держат свой сервер.

Если же у вас из self-hosted инфраструктуры вообще ничего нет, а нужен только планировщик встреч дважды в месяц — разворачивать под это Docker, домен, SSL и бэкапы ради экономии на бесплатном тарифе публичного сервиса — плохая сделка по времени. Час на настройку и потом периодические полчаса на обновления и присмотр за сервером обходятся дороже, чем стоит сама задача.

Когда хватит бесплатного тарифа Doodle или Calendly

Если данные о расписании не критичны, а команда небольшая, честный ответ — воспользоваться готовым бесплатным сервисом. Doodle, Rallly Cloud (бесплатный тариф самого проекта) и похожие инструменты закрывают базовый сценарий «выбрать дату для встречи» без установки чего-либо. Условия бесплатных тарифов у таких сервисов регулярно меняются — лимиты на число активных опросов, участников или брендинг — поэтому конкретные цифры называть смысла нет, проверяйте актуальные условия на сайте сервиса на момент, когда решаете задачу.

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

Отдельно стоит взвесить надёжность: у публичного сервиса SLA и резервирование по умолчанию лучше, чем у одного самостоятельно настроенного VPS без резервного узла. Если опрос о встрече с важным клиентом окажется недоступен в момент, когда участник переходит по ссылке, потому что ваш единственный сервер решил перезагрузиться на обновление ядра — это репутационные издержки, которые перевешивают экономию нескольких долларов в месяц.

Когда проще обойтись перепиской или опросом в мессенджере

Ниже определённого порога инструмент вообще не нужен — ни облачный, ни self-hosted. Если встреча планируется между двумя-тремя людьми, которые и так постоянно на связи в одном чате, голосование за дату через Rallly или Doodle — избыточный шаг. Быстрее написать «предлагаю вторник в 15:00 или среду в 11:00, что удобнее» и получить ответ в течение часа, чем создавать опрос, копировать ссылку, ждать, пока все перейдут и проголосуют.

Опросы в самом мессенджере (нативные опросы Telegram, Slack) закрывают похожий диапазон сценариев без выхода из привычного интерфейса — участникам не нужно переходить по внешней ссылке и ничего не устанавливать. Ограничение — такие опросы плохо работают, когда нужно сравнить несколько временных слотов по нескольким людям одновременно и увидеть пересечение автоматически: считать вручную, кто на что проголосовал, приходится тому же организатору, только без удобной сводной таблицы.

Практический ориентир: до 3-4 участников и одной-двух дат на выбор — переписка эффективнее любого инструмента. От 5 участников или при необходимости сравнить больше трёх вариантов дат — переписка начинает буксовать, и здесь уже оправдан любой инструмент для голосования, вопрос только в том, self-hosted он или облачный.

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