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

MAATRIX

Budibase собирает внутренние приложения и формы поверх ваших же данных — CRM для отдела продаж, панель для склада, форма приёмки заявок — без месяцев разработки на фронтенде и бэкенде. Но self-hosted Budibase — это не один контейнер, а связка из нескольких сервисов, и именно поэтому вопрос «сколько RAM нужно» здесь не такой прямой, как для одиночного Node-приложения. Разберём, из чего состоит стек, что говорит официальная документация и какую конфигурацию брать под свою нагрузку.

Из чего состоит self-hosted стек Budibase

Когда вы разворачиваете Budibase через официальный docker-compose.yaml, поднимается не одно приложение, а целый набор контейнеров, каждый со своим потреблением памяти:

Это принципиально другая архитектура, чем у лёгких single-container инструментов вроде NocoDB или Baserow, где один процесс отдаёт и API, и статику. У Budibase каждый компонент — отдельный контейнер с собственным рантаймом (Node.js для app-service и worker-service, Erlang/OTP для CouchDB), и память нужно считать по стеку целиком, а не по одному процессу.

Практическое следствие: если вы прикидываете сервер «на глаз» по опыту с более простыми low-code инструментами вроде NocoDB, закладывайте RAM с запасом — Budibase из коробки поднимает больше процессов одновременно.

Что говорит документация Budibase

Официальная документация Budibase для self-hosted через Docker Compose ориентируется на классические «облачные» минимумы: около 2 vCPU и 4 ГБ RAM как стартовая точка для одиночного инстанса, и рекомендация закладывать больше для рабочей нагрузки с несколькими приложениями и активными пользователями. Эти цифры — ориентир на момент публикации, а не жёсткий контракт: разработчики периодически меняют состав стека (например, включают или отключают Minio по умолчанию в разных версиях), поэтому перед деплоем стоит свериться с актуальным docker-compose.yaml в репозитории проекта — какие сервисы реально поднимаются в вашей версии.

Важный нюанс: официальные минимумы обычно считаются для *старта системы*, а не для комфортной работы под нагрузкой. На границе минимума CouchDB и Node-процессы поднимаются и работают, но при первом же более-менее активном использовании (несколько открытых приложений, параллельные автоматизации) сервер начинает уходить в swap — и это то, ради чего стоит закладывать запас, а не резать конфигурацию впритык.

Сколько нужно для теста и небольшой команды

Для знакомства с платформой, локальной разработки одного приложения или демонстрации клиенту жёстко экономить не стоит — Budibase просто не поднимется стабильно на 1–2 ГБ из-за числа одновременных контейнеров.

На 4 ГБ система работает, но без большого запаса: CouchDB под Erlang/OTP держит собственный оверхед рантайма независимо от объёма данных, а app-service и worker-service — это два отдельных Node-процесса, каждый со своим базовым потреблением. Если параллельно с Budibase на том же сервере крутится что-то ещё (например, обратный прокси для нескольких сайтов), 4 ГБ быстро становятся тесными.

Продакшн: несколько приложений и активные пользователи

Как только Budibase переходит в разряд «рабочего инструмента» — несколько опубликованных приложений, десяток и больше активных пользователей, автоматизации, которые дёргают внешние API по расписанию, — потребление растёт по нескольким направлениям одновременно:

• CouchDB — чем больше данных во внутренних таблицах приложений и чем активнее одновременные записи, тем больше памяти уходит на индексы представлений (views) и кэш B-tree структур.
• worker-service — каждая запущенная автоматизация (особенно с циклами, HTTP-запросами наружу или обработкой вложений) добавляет нагрузку на очередь задач в Redis и сам воркер.
• app-service — рендеринг конструктора приложений и обработка одновременных сессий редактирования сами по себе не тяжёлые, но масштабируются с числом одновременно работающих в UI пользователей.
• Minio, если используется — растёт с объёмом загруженных файлов и вложений, хотя сам процесс лёгкий.

Для такого профиля разумный ориентир — 8–16 ГБ RAM и 4 vCPU, в зависимости от числа приложений и интенсивности автоматизаций. Если приложений много и они активно используются одновременно несколькими отделами, полезно вынести CouchDB на отдельный volume с быстрым NVMe — она чувствительна к задержкам диска при частой записи представлений.

services:
  couchdb:
    image: budibase/couchdb:v3.5.0
    restart: unless-stopped
    mem_limit: 2g
    volumes:
      - couchdb-data:/opt/couchdb/data

  redis:
    image: redis
    restart: unless-stopped
    mem_limit: 512m
    volumes:
      - redis-data:/data

  app-service:
    image: budibase/apps
    restart: unless-stopped
    mem_limit: 2g
    environment:
      - COUCH_DB_URL=http://couchdb:5984
      - REDIS_URL=redis:6379

  worker-service:
    image: budibase/worker
    restart: unless-stopped
    mem_limit: 1g
    environment:
      - COUCH_DB_URL=http://couchdb:5984
      - REDIS_URL=redis:6379

  proxy:
    image: budibase/proxy
    restart: unless-stopped
    mem_limit: 256m
    ports:
      - "80:10000"
    depends_on:
      - app-service
      - worker-service

volumes:
  couchdb-data:
  redis-data:

Явные mem_limit на каждый контейнер — не формальность: без них один прожорливый контейнер (обычно это CouchDB под тяжёлой нагрузкой на запись) может забрать память соседей и уронить весь стек по OOM разом, вместо того чтобы упасть контролируемо один. Общий подход к лимитам разобран в статье про лимиты CPU и памяти в Docker.

Как посчитать RAM под свою нагрузку

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

1. Возьмите базовый минимум стека. На старте, без активного использования, шесть контейнеров держат некоторый фундамент рантаймов — именно поэтому меньше 4 ГБ для Budibase практически не имеет смысла даже для одного пользователя.
2. Добавьте объём данных в CouchDB. Чем сложнее представления (views) для фильтрации и сортировки во внутренних таблицах приложений, тем больше памяти CouchDB держит под индексы.
3. Учтите число одновременных автоматизаций. Каждая активная автоматизация с HTTP-запросами наружу, обработкой файлов или циклами — нагрузка на worker-service и Redis-очередь. Десяток простых автоматизаций почти не заметны; несколько тяжёлых, дёргающих внешние API с задержкой, — заметный расход.
4. Учтите вложения и файлы. Minio (или внешнее S3-хранилище) снимает нагрузку с диска, но сам требует памяти пропорционально числу одновременных загрузок, а не общему объёму хранимых файлов.
5. Заложите запас 20–30% сверху расчёта — под массовый импорт, публикацию нескольких приложений одновременно или пиковую активность в начале рабочего дня, когда вся команда заходит синхронно.

Если Budibase — часть более широкой инфраструктуры внутренних инструментов рядом с базой данных, к которой он подключается напрямую (а не только через встроенный CouchDB), та же логика прикидки под несколько параллельных сервисов на одном сервере пригодится при расчёте ресурсов под остальную инфраструктуру команды.

Оптимизация памяти и swap

Несколько практических приёмов, которые реально снижают риск упереться в память:

• Настройте swap как страховку, а не как основной ресурс. Своп не заменяет нехватку RAM для CouchDB под нагрузкой (Erlang VM плохо переносит активный своппинг — растут задержки записи), но спасает от жёсткого OOM-килла при кратковременном всплеске. Как правильно выставить размер — в статье «Правильный размер swap для VPS».
• Отключите Minio, если используете внешнее S3-хранилище — это один процесс меньше и одна точка потребления памяти меньше.
• Мониторьте по каждому контейнеру отдельно, а не по хосту целиком. docker stats показывает, какой контейнер растёт при конкретном действии — публикации приложения, запуске автоматизации, массовом импорте данных.
• Не экономьте на CouchDB в пользу app-service. Узкое место чаще именно CouchDB под нагрузкой на запись — если приходится урезать mem_limit, делайте это в последнюю очередь именно для базы.
• Регулярно чистите старые представления (views) CouchDB — неиспользуемые индексы продолжают занимать память, даже если приложение давно не используется активно.

Какой сервер взять в MAATRIX под Budibase

Честный рабочий минимум — 2 vCPU, 4 ГБ RAM, 40 ГБ NVMe для теста, знакомства с платформой или одного небольшого приложения на команду из пары человек. Это тот случай, где экономить ниже уже не имеет смысла: стек из шести контейнеров просто не стабилизируется на меньшем объёме памяти.

Для рабочего использования — несколько приложений, десяток и больше активных пользователей, автоматизации по расписанию — берите 4 vCPU, 8 ГБ RAM, 60–80 ГБ NVMe. Диск важен не только по объёму: CouchDB чувствительна к скорости записи при активной работе с представлениями, поэтому NVMe здесь не роскошь, а требование к отзывчивости интерфейса.

Локация — по расположению команды и данных. Budibase хранит данные внутренних приложений (часто это чувствительная информация — контакты клиентов, внутренние процессы) прямо в собственной CouchDB, поэтому для российской команды с персональными данными сотрудников или клиентов логичнее российская площадка под требования 152-ФЗ. Для международной команды подойдёт локация в Лондоне или США.

Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT; для разворачивания через Docker Compose иностранная карта не нужна. Пошаговая база для чистого сервера — в статье «Docker Compose для продакшена на Ubuntu 24.04».

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