Сколько RAM нужно для Formbricks

MAATRIX

Formbricks выглядит как замена Typeform, но за счёт функциональности — ветвления логики, интеграций, множества опросов и проектов в одном инстансе — легко недооценить, сколько памяти реально нужно на боевом сервере. Разберём, из чего складывается потребление RAM в self-hosted Formbricks, почему логика ветвления почти не при чём, и как посчитать конфигурацию под свой объём ответов, а не гадать по общей рекомендации из документации.

Из чего складывается потребление RAM в Formbricks

Formbricks — это Next.js-приложение (React на сервере и в браузере в одном процессе), которое одновременно отдаёт админку, API для сбора ответов и логику встраиваемых виджетов опросов на сторонние сайты. Обязательная внешняя зависимость — PostgreSQL, куда через Prisma ORM пишутся опросы, ответы, контакты и настройки проектов. В части self-hosted конфигураций дополнительно рекомендуют Redis — уточняйте по актуальной документации на момент установки, нужен ли он в вашей версии для ограничения частоты запросов (rate limiting) к публичному API.

Память расходуется по нескольким разным сценариям:

• Простой без активности — сам процесс Next.js в режиме ожидания (обслуживает админку и редкие запросы виджета) занимает относительно немного, обычно первые сотни мегабайт за счёт того, что Node.js держит в памяти скомпилированные серверные бандлы приложения.
• Приём ответов на опросы — каждое отправленное с виджета событие (открытие опроса, ответ на вопрос, завершение) — это отдельный запрос к API, который валидируется и пишется в PostgreSQL. Нагрузка растёт не от количества опросов в базе, а от числа одновременных отправок в моменте — например, когда форма встроена на сайт с высоким трафиком и отвечающих одновременно сотни.
• Рендер и логика ветвления в браузере, а не на сервере — важный нюанс: условные переходы между вопросами (skip logic) Formbricks вычисляет на стороне клиента, в JS-виджете, который загружается в браузер посетителя. Сервер лишь отдаёт JSON-описание опроса со всеми ветками сразу и принимает финальные ответы. Поэтому сложность логики ветвления почти не влияет на память вашего сервера — она влияет на размер JSON-конфига опроса и на нагрузку браузера посетителя, а не бэкенда.
• Интеграции и вебхуки — при подключении Zapier, Make, Slack, Google Sheets или собственных вебхуков каждое завершение опроса дополнительно триггерит исходящий HTTP-запрос из процесса Formbricks. Много активных интеграций на высоком потоке ответов — дополнительная, хоть и не самая крупная, статья расхода.
• PostgreSQL — отдельный процесс со своим бюджетом памяти, который зависит от накопленного объёма ответов и от того, сколько проектов/организаций крутится в одном инстансе.

Если считать честно, база — это Formbricks-процесс и PostgreSQL на одной машине, а всплески нагрузки от массового приёма ответов и активных интеграций — переменная величина сверху.

Сколько RAM нужно по масштабу использования

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

Для теста и небольшого личного проекта вполне хватает одного VPS на 2 GB RAM с Formbricks и PostgreSQL в одном Docker Compose. Как только опросы начинают собирать заметный поток ответов из реального трафика на сайте — закладывайте от 4 GB и мониторинг памяти с первого дня, чтобы не упереться в OOM в момент, когда форма внезапно попала в рассылку или на популярную страницу.

PostgreSQL под Formbricks: что реально растит базу

PostgreSQL для Formbricks хранит не только структуру опросов, но и полную историю ответов — каждый ответ на каждый вопрос, метаданные о контакте (если включена идентификация респондентов), события открытия и завершения. На проекте с несколькими активными формами и постоянным потоком ответов таблица ответов растёт быстрее, чем кажется на старте, особенно если опросы содержат вопросы с открытым текстом или файловыми вложениями (ссылки на файлы, сами файлы обычно хранятся в S3-совместимом хранилище, а не в базе).

Дефолтные настройки postgresql.conf из коробки рассчитаны на минимальное железо и требуют правки под реальную нагрузку. Базовые ориентиры:

# при выделенных под PostgreSQL 2 GB RAM
shared_buffers = 512MB        # обычно 25% от RAM, отданной под Postgres
effective_cache_size = 1536MB # 50-75% от RAM — подсказка планировщику
work_mem = 16MB
maintenance_work_mem = 128MB
max_connections = 30           # Prisma держит небольшой пул соединений, 30 обычно достаточно

Prisma по умолчанию открывает пул соединений на процесс Node.js — если запускаете несколько инстансов Formbricks за балансировщиком, суммарное число соединений к PostgreSQL стоит явно ограничить через connection_limit в строке подключения, иначе легко упереться в max_connections раньше, чем в память. Общий разбор параметров и типичных проблем — в статье про установку и настройку PostgreSQL на VPS, а если база внезапно начала съедать память при пиковой нагрузке — смотрите PostgreSQL out of memory: причины и решение.

Docker Compose: типовой конфиг и лимиты памяти

Официально рекомендуемый способ развернуть Formbricks self-hosted — Docker Compose из сервиса приложения и PostgreSQL (плюс Redis в конфигурациях, где он требуется под rate limiting). Без явных лимитов памяти контейнеры по умолчанию могут выесть всю RAM хоста именно в момент пиковой отправки ответов — самый неудобный момент, чтобы это обнаружить.

Ориентировочный пример с лимитами под сервер на 4 GB (сверяйте актуальные переменные окружения с документацией на момент установки — набор обязательных секретов у проекта время от времени меняется):

services:
  formbricks:
    image: formbricks/formbricks:latest
    mem_limit: 1.5g
    mem_reservation: 512m
    environment:
      - DATABASE_URL=postgresql://formbricks:formbricks_pass@postgres:5432/formbricks?connection_limit=20
      - NEXTAUTH_SECRET=change_me
      - ENCRYPTION_KEY=change_me
      - WEBAPP_URL=https://forms.example.com
    depends_on:
      - postgres
    ports:
      - "3000:3000"
    restart: unless-stopped

  postgres:
    image: postgres:16-alpine
    mem_limit: 2g
    shm_size: 256mb
    environment:
      - POSTGRES_USER=formbricks
      - POSTGRES_PASSWORD=formbricks_pass
      - POSTGRES_DB=formbricks
    volumes:
      - ./pgdata:/var/lib/postgresql/data
    restart: unless-stopped

mem_limit — жёсткий потолок: контейнер, упёршийся в него, получит SIGKILL от ядра, а не мягко замедлится. Общие принципы выставления таких лимитов разобраны в статье про ресурсы и лимиты CPU и памяти в Docker — там же про запас в 20-30% сверх реального потребления вместо лимита впритык.

Проверить фактическое потребление в момент реального приёма ответов, а не в состоянии покоя:

docker stats --no-stream formbricks_formbricks_1 formbricks_postgres_1
free -h
dmesg -T | grep -i "killed process"
docker inspect formbricks_formbricks_1 --format='{{.State.OOMKilled}}'

Если последняя команда вернула true — сервис упирался в лимит именно во время всплеска ответов, и правильная реакция — поднять mem_limit, а не считать это разовым сбоем.

Интеграции и вебхуки: скрытая нагрузка сверху базового потребления

Каждая настроенная интеграция — Zapier, Make (Integromat), Slack, Google Sheets или произвольный вебхук — означает, что при завершении опроса процесс Formbricks делает исходящий HTTP-запрос к внешнему сервису и ждёт ответа. Пока таких интеграций одна-две и трафик умеренный, это заметно не сказывается на памяти. Но если у вас десятки активных форм с несколькими интеграциями каждая, а внешний сервис отвечает медленно, в моменте может накапливаться несколько десятков одновременно ожидающих запросов — каждый держит в памяти открытое соединение, пока не получит ответ или не истечёт таймаут.

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

Когда переходить с одного VPS на разнесённую схему

Пока опросы собирают умеренный поток ответов, Formbricks и PostgreSQL прекрасно живут на одной машине. Сигналы, что пора разносить сервисы или масштабировать вертикально:

• PostgreSQL стабильно занимает больше половины доступной RAM хоста даже после тюнинга shared_buffers.
• docker stats показывает, что в момент пикового приёма ответов упираются в лимит сразу оба контейнера, а не только один.
• Число активных проектов и опросов выросло настолько, что docker inspect регулярно показывает OOMKilled: true у контейнера приложения.
• Бэкапы базы (а бэкапить историю ответов респондентов нужно обязательно — это основной актив вашего инстанса) заметно нагружают сервер во время снимка и конкурируют с приёмом ответов в реальном времени.

Для инстанса с несколькими командами, множеством проектов и стабильно высоким потоком ответов разумная схема — Formbricks-приложение отдельно, PostgreSQL отдельно, с возможностью нарастить диск и память под базу независимо от приложения. Если рассматриваете альтернативную схему изоляции сервисов вместо чистого Docker Compose — сравнение подходов есть в статье Docker или LXC — что выбрать для сервера.

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