Сколько RAM нужно для Cal.com

MAATRIX

Cal.com — открытая альтернатива Calendly, и на бумаге это просто «сайт для записи на встречи». На практике же это Next.js-приложение с Prisma поверх PostgreSQL, отдельным воркером для напоминаний и вебхуков, и — что важнее всего для вопроса про RAM — довольно тяжёлой стадией сборки. Именно сборка, а не рантайм, чаще всего кладёт маленькие серверы по OOM. Разберём по шагам, сколько памяти реально нужно на каждом этапе и как не упереться в killed process на первом же yarn build.

Из чего состоит Cal.com и куда уходит память

Self-hosted Cal.com — это не один процесс, а связка из нескольких частей:

• Next.js-приложение — основной веб-интерфейс и API-роуты. В рантайме (после сборки, next start) это обычный Node.js-процесс, который держит немного, но растёт с числом одновременных запросов и открытых сессий.
• Стадия сборки (yarn build / yarn workspace @calcom/web build) — компиляция TypeScript, генерация Prisma-клиента, сборка Next.js во всех локалях. Это самый прожорливый по памяти момент во всём жизненном цикле приложения: сборщик держит в памяти граф модулей всего монорепозитория Cal.com, а он немаленький.
• PostgreSQL — обязательная база данных: пользователи, бронирования, типы событий, интеграции. Потребление растёт с историей бронирований и количеством подключений от Next.js.
• Фоновый воркер (cron/queue) — напоминания о встречах, повторные попытки вебхуков, синхронизация с внешними календарями (Google Calendar, Outlook). В части self-hosted сборок это отдельный процесс или запланированные HTTP-вызовы на cron-эндпоинты.
• Redis (опционально) — для рейт-лимитера и кэша сессий, если включаете EDGE_CONFIG/rate limiting; в базовой self-hosted установке без него можно обойтись, но с ним поведение под нагрузкой стабильнее.

Видеозвонки Cal.com по умолчанию проксирует через Cal Video / Daily.co — то есть тяжёлая обработка медиа происходит не у вас на сервере, и в бюджет RAM её закладывать не нужно. Это отличает Cal.com от, например, self-hosted Jitsi, где видео действительно грузит сервер.

Сборка: главный источник проблем с памятью

Если вы разворачиваете Cal.com не из готового Docker-образа, а собираете из исходников (git clone + yarn install + yarn build), будьте готовы к тому, что сборка — самая тяжёлая по памяти операция за всё время жизни сервера. Node.js по умолчанию ограничивает кучу V8 на уровне, который для монорепозитория с несколькими приложениями и общими пакетами может оказаться недостаточным — процесс сборки либо падает с JavaScript heap out of memory, либо его убивает OOM killer ядра, если памяти физически не хватило.

На серверах с 2 ГБ RAM и без свопа сборка падает регулярно — это частая жалоба в комьюнити вокруг self-hosted Cal.com. Практические способы обойти проблему:

# поднять лимит кучи V8 перед сборкой (значение в МБ)
export NODE_OPTIONS="--max-old-space-size=4096"
yarn build

Если физической памяти под такой лимит нет, добавьте своп — сборка пройдёт медленнее (диск не RAM), но не упадёт:

fallocate -l 4G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

Подробнее о том, как правильно рассчитать размер и параметры свопа под VPS, — в статье про правильный размер swap для VPS.

Второй практический путь — не собирать самостоятельно, а взять готовый образ (официальный или из проверенного community docker-compose). Тогда тяжёлая сборка происходит один раз на стороне сборщика образа, а вашему серверу остаётся только рантайм, которому нужно в разы меньше памяти.

Сколько RAM нужно: по сценарию использования

Цифры ниже — ориентир из практики разворачивания похожих Next.js + PostgreSQL стеков, а не результат измеренного бенчмарка конкретно Cal.com при заданной нагрузке: у вас показатели сдвинутся в зависимости от числа пользователей, интеграций и того, собираете вы из исходников или используете готовый образ.

Ключевой момент таблицы: при разовой сборке из исходников на 2 ГБ вам почти наверняка понадобится своп именно на время yarn build — после успешной сборки рантайм-процесс Next.js на маленькой команде спокойно укладывается в 1-1.5 ГБ, и своп можно оставить как страховку, а не как постоянно используемый ресурс.

PostgreSQL: сколько закладывать под базу

Cal.com активно использует PostgreSQL через Prisma — каждое бронирование, слот доступности, интеграция и лог вебхука пишутся в базу. На старте, с пустой или небольшой историей бронирований, PostgreSQL спокойно работает в 512 МБ - 1 ГБ. Проблема в том, что PostgreSQL по умолчанию настроен под сервер общего назначения, а не под маленький VPS, и с ростом числа одновременных подключений от Next.js (каждый API-роут может открывать своё соединение, если не настроен пул) память уходит в shared_buffers и кэш быстрее, чем кажется.

Что стоит сделать сразу:

• Настроить пул соединений (pgbouncer или встроенный connection pooling через DATABASE_URL с параметром pgbouncer=true, если используете Prisma Accelerate/Data Proxy) — без пула Next.js в serverless-стиле легко открывает десятки соединений под нагрузкой.
• Урезать shared_buffers и max_connections под реальный объём RAM сервера — базовые команды и параметры разобраны в статье про тюнинг PostgreSQL на VPS.
• Если база растёт (тысячи бронирований, долгая история), выносить PostgreSQL на отдельный сервер — так вы не конкурируете за память с Next.js-процессом в моменты пиковой записи.

Если PostgreSQL — новый для вас сервис, базовая установка и настройка описаны в статье как установить и настроить PostgreSQL на VPS.

Docker Compose с лимитами памяти

Если разворачиваете Cal.com через Docker Compose, явно ограничивайте контейнеры — иначе один процесс под нагрузкой может забрать всю память сервера и утащить за собой PostgreSQL:

version: "3.8"
services:
  calcom:
    image: calcom/cal.com:latest   # либо свой образ, собранный из исходников
    restart: unless-stopped
    environment:
      - NEXTAUTH_URL=https://cal.example.com
      - DATABASE_URL=postgresql://calcom:pass@db:5432/calcom
      - NODE_OPTIONS=--max-old-space-size=1536
    depends_on:
      - db
    ports:
      - "3000:3000"
    deploy:
      resources:
        limits:
          memory: 2g
        reservations:
          memory: 1g

  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      - POSTGRES_USER=calcom
      - POSTGRES_PASSWORD=pass
      - POSTGRES_DB=calcom
    volumes:
      - calcom_pgdata:/var/lib/postgresql/data
    deploy:
      resources:
        limits:
          memory: 1g

volumes:
  calcom_pgdata:

Обратите внимание на NODE_OPTIONS=--max-old-space-size=1536 внутри контейнера — лимит кучи V8 стоит выставлять чуть ниже memory limit контейнера, чтобы Node.js сам укладывался в бюджет, а не ждал, пока его убьёт cgroup. Если вы используете docker-compose без секции deploy (старый Compose без Swarm), аналогичные ограничения задаются через mem_limit: 2g на уровне сервиса — общий подход к лимитам CPU и памяти в Docker разобран в статье про лимиты ресурсов в Docker.

Как понять, что памяти не хватает

Три признака, что Cal.com упирается в RAM, а не в CPU или диск:

1. Сборка падает с JavaScript heap out of memory или процесс yarn build/next build просто исчезает без внятной ошибки — это OOM killer ядра, посмотрите dmesg | grep -i "killed process".
2. Интерфейс подтормаживает при одновременных бронированиях — несколько человек одновременно смотрят доступные слоты, Next.js держит больше активных запросов, и если памяти на грани, растут задержки ответа API.
3. PostgreSQL периодически теряет соединение или медленно отвечает под нагрузкой — признак того, что база и приложение делят одну и ту же ограниченную память и мешают друг другу.

Быстрая диагностика на сервере:

free -h                      # общая картина: сколько свободно, сколько в swap
docker stats                 # потребление по каждому контейнеру в реальном времени
docker logs calcom --tail 100
dmesg | grep -i "out of memory"

Если docker stats показывает, что контейнер calcom стабильно упирается в лимит памяти даже вне пиков, поднимайте лимит или разбирайтесь, какие переменные окружения включают лишние фоновые задачи (например, синхронизацию с несколькими внешними календарями сразу). Общий разбор поведения сервера при нехватке RAM и порядок действий — в статье что делать при нехватке RAM.

Что делать, если сервера не хватает

Если после тюнинга (пул соединений, лимиты, отказ от локальной пересборки в пользу готового образа) памяти всё равно мало, есть три рабочих пути:

• Вынести PostgreSQL на отдельный сервер или управляемую БД — сразу освобождает 30-50% памяти хоста под сам Next.js-процесс и снимает конкуренцию за I/O в моменты записи бронирований.
• Отключить неиспользуемые интеграции — каждая активная интеграция с внешним календарём или видеосервисом добавляет фоновые синхронизации; если вы используете только Google Calendar, не держите включёнными коннекторы, которыми не пользуетесь.
• Апгрейднуть тариф VPS перед пиком, а не после инцидента — сборка и первые дни эксплуатации почти всегда тяжелее, чем стабильный рантайм через месяц; закладывайте запас в 30-50% на старте, а не впритык по таблице выше.

Своп — рабочая страховка на время сборки, но не решение для постоянной нехватки RAM в рантайме: под записью в PostgreSQL и обработкой API-запросов своп резко просаживает время отклика, и пользователи это почувствуют при бронировании слота.

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