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

MAATRIX

Activepieces — open-source альтернатива Zapier и Make, и первый вопрос при самостоятельном хостинге почти всегда один: сколько RAM закладывать, чтобы флоу не падали на третий день. Готовых цифр в документации мало, а платформа устроена не так, как n8n или Make — каждый шаг флоу выполняется в изолированной песочнице, и именно это определяет реальный расход памяти. Разбираемся, из чего складывается аппетит Activepieces и какой сервер брать, чтобы не мониторить docker stats каждый вечер.

Короткий ответ: сколько RAM нужно для Activepieces

Ниже — ориентир по сценариям использования. Цифры не измеренный бенчмарк конкретной версии, а оценка по архитектуре стека (NestJS-бэкенд + Angular-фронт + PostgreSQL + Redis + песочница выполнения) и по тому, из чего собирается образ activepieces/activepieces: у вас может отличаться в обе стороны в зависимости от числа и сложности пieces в флоу.

Главное из таблицы: сам процесс Activepieces в простое — это первые 300–500 МБ, всё, что выше, — это Postgres, Redis и, самое главное, песочницы, в которых реально исполняются шаги ваших флоу.

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

Activepieces — не одно приложение, а связка из нескольких процессов, и при самостоятельном хостинге вы поднимаете их все на одной машине, если не разносите специально:

Первые четыре строки — это фундамент: 500–900 МБ, которые нужны почти всегда, даже если флоу не выполняются. Последняя строка — переменная часть, и именно она чаще всего роняет сервер: чем больше флоу выполняется параллельно и чем тяжелее pieces (скачивание файлов, парсинг PDF, вызовы внешних API с большими ответами), тем больше одновременных песочниц держит worker в памяти.

Важный нюанс: Activepieces по умолчанию распространяется как один all-in-one Docker-образ, где backend и worker — части одного процесса. Разносить их на отдельные контейнеры имеет смысл только при заметной нагрузке — до этого момента усложнение не окупается.

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

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

Практически это значит следующее:

• Параллельные запуски множатся, а не делятся. Если триггер сработал сразу для десяти событий (например, вебхук от формы), worker поднимает до десяти изолированных выполнений одновременно, если не ограничен по конкурентности. Каждое тянет свою порцию памяти.
• Тяжёлые pieces тяжелее лёгких не пропорционально, а скачком. Piece, который трансформирует JSON, укладывается в десятки мегабайт на выполнение. Piece, который скачивает файл или вызывает модель, может на время исполнения занять сотни мегабайт — и эта память не освобождается, пока шаг не завершится.
• История выполнений нагружает диск и Postgres напрямую, а RAM — косвенно: при большом числе хранимых логов запросы к базе становятся тяжелее, и Postgres начинает просить больше памяти под кеш.

Отсюда практический вывод: ограничение числа параллельных выполнений — не защита от лишней нагрузки, а обязательная настройка для любого сервера с ограниченной памятью. Без него один всплеск вебхуков способен занять всю доступную RAM за секунды, и dmesg -T | grep -i "out of memory" покажет, что ядро прибило процесс по cgroup-лимиту.

Docker Compose: рабочая конфигурация и переменные, которые снижают память

Официальный self-hosted вариант разворачивается через Docker Compose с тремя сервисами: сам Activepieces, PostgreSQL и Redis. Базовый каркас выглядит так — конкретные имена переменных окружения сверяйте с .env.example в репозитории на момент установки, проект их периодически меняет между релизами:

services:
  activepieces:
    image: activepieces/activepieces:latest
    restart: unless-stopped
    mem_limit: 2g
    ports:
      - "8080:80"
    environment:
      - AP_ENGINE_EXECUTABLE_PATH=/usr/src/app/dist/packages/engine/main.js
      - AP_POSTGRES_HOST=postgres
      - AP_POSTGRES_PORT=5432
      - AP_POSTGRES_DATABASE=activepieces
      - AP_POSTGRES_USERNAME=activepieces
      - AP_POSTGRES_PASSWORD=${AP_POSTGRES_PASSWORD}
      - AP_REDIS_HOST=redis
      - AP_REDIS_PORT=6379
      - AP_JWT_SECRET=${AP_JWT_SECRET}
      - AP_ENCRYPTION_KEY=${AP_ENCRYPTION_KEY}
      - AP_FRONTEND_URL=https://your-domain.example
    depends_on:
      - postgres
      - redis

  postgres:
    image: postgres:15-alpine
    restart: unless-stopped
    mem_limit: 512m
    environment:
      - POSTGRES_DB=activepieces
      - POSTGRES_USER=activepieces
      - POSTGRES_PASSWORD=${AP_POSTGRES_PASSWORD}
    volumes:
      - pg_data:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    mem_limit: 128m
    command: redis-server --maxmemory 96mb --maxmemory-policy allkeys-lru
    volumes:
      - redis_data:/data

volumes:
  pg_data:
  redis_data:

Что реально снижает потребление на практике:

• Ограничьте число параллельных выполнений. Самая важная настройка на любом сервере до 8 ГБ — защищает от всплеска на десять вебхуков разом. Актуальное имя переменной концерентности проверьте в разделе про воркеры в документации перед продакшеном — между релизами оно менялось.
• mem_limit на каждом сервисе Docker Compose. Без него один зависший контейнер может выесть память у соседей, и в первую очередь пострадает Postgres — а с ним весь инстанс.
• maxmemory для Redis. Очередь заданий не должна расти бесконечно: лимит с политикой вытеснения allkeys-lru защищает от накопления мусора при сбоях worker-а.
• Регулярная чистка истории выполнений. Разросшиеся таблицы логов увеличивают время запросов и память под кеш планов Postgres — настройте retention в проекте или ротацию на уровне базы.
• Отдельный worker вместо all-in-one — только при реальной нагрузке. Разнесение backend и worker на разные контейнеры даёт независимое масштабирование, но добавляет накладные расходы — смысл есть, только когда один сервер реально упирается в лимит.

Диагностика: OOM, зависшие флоу и на что смотреть

Первый шаг при падении контейнера — выяснить, кто именно его убил:

docker inspect activepieces --format '{{.State.OOMKilled}} {{.State.ExitCode}}'

Ответ true 137 — контейнер убит ядром по лимиту cgroup, это память, а не баг в коде флоу. Подтверждение — в dmesg -T | grep -i "out of memory". Лечится тремя способами по отдельности или вместе: поднять mem_limit, снизить число параллельных выполнений, упростить тяжёлые pieces в частых флоу (например, работать с большими файлами по ссылке, а не гонять их через шаги трансформации).

Для наблюдения за трендом, а не только за фактом падения, снимайте показатели раз в 10–30 секунд:

while true; do docker stats --no-stream --format '{{.Name}} {{.MemUsage}} {{.CPUPerc}}'; sleep 15; done | tee -a /var/log/activepieces-mem.log

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

Если контейнер жив, но флоу зависают — это чаще не память, а проблема в очереди: Redis недоступен, worker не забирает задания, либо внешний API держит выполнение до таймаута. Проверьте docker logs на ошибки подключения к Redis и Postgres — обе зависимости критичны для старта.

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

Честный минимум для рабочего инстанса — 2 vCPU, 4 ГБ RAM, 40 ГБ NVMe. Двух гигабайт формально хватает, чтобы Activepieces запустился, но при первом же всплеске параллельных выполнений с ограничением по конкурентности по умолчанию (или без него вовсе) вы упрётесь в лимит и получите падение контейнера с базой внутри той же машины.

Комфортный вариант для продакшена с несколькими активными интеграциями — 4 vCPU, 8 ГБ RAM, 80 ГБ NVMe. Такой запас держит Postgres с растущей историей выполнений, Redis, worker с разумной конкурентностью и оставляет место под ночные пики без постоянного мониторинга. Если в флоу добавляются AI-шаги или регулярная обработка файлов — смотрите в сторону 12–16 ГБ, разбор похожей нагрузки есть в статье про требования к RAM для n8n — архитектурно это близкий класс задач.

Локация зависит от того, куда смотрят ваши интеграции. Если большинство сервисов, с которыми работает Activepieces (платёжные шлюзы, зарубежные SaaS, API моделей), находятся за пределами России — берите Лондон или США: прямые соединения без прокси и без риска, что зависший внешний запрос будет держать память дольше из-за таймаутов на нестабильном канале. Если интеграции российские и в флоу проходят персональные данные — оправдан российский дата-центр под требования 152-ФЗ.

Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT, доступна на всех локациях без иностранной карты. Про правильный расчёт места под запас памяти в целом — в статье сколько RAM закладывать с запасом, про настройку лимитов контейнеров — в разборе лимитов CPU и памяти в Docker. Не уверены, какая конфигурация ваша — напишите, сколько флоу и какой тип pieces используете, подберём сервер под нагрузку.

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