Activepieces в Docker Compose: готовый файл

MAATRIX

Если вы устали платить за Zapier или Make по числу задач в месяц и хотите держать интеграции между сервисами на своём сервере — Activepieces закрывает эту потребность без арендной платы за каждый триггер. Ниже — рабочий docker-compose.yml, разбор всех переменных окружения и то, что обычно всплывает после первого запуска: HTTPS, бэкапы, память и обновления.

Что такое Activepieces и зачем свой сервер вместо облака

Activepieces — open-source платформа для автоматизации между сервисами: визуальный конструктор потоков (flow builder), сотни готовых «кусочков» (pieces) для популярных API — от Google Sheets и Slack до Stripe и OpenAI, плюс возможность написать свой piece на TypeScript, если готового нет. По духу это прямой аналог Zapier и Make, но с открытым кодом и без лимита на количество задач — ограничение только в ресурсах вашего сервера.

Смысл переезда на свой сервер обычно один: у облачного Activepieces Cloud, как и у Zapier, есть бесплатный тир с ограничениями и платные планы, привязанные к числу выполнений в месяц. При активном использовании (десятки workflow, сотни срабатываний в день) self-hosted вариант на VPS за пару тысяч рублей в месяц окупается в первый же месяц — плюс данные (API-ключи сервисов, содержимое вебхуков) не покидают вашу инфраструктуру.

Из практических нюансов: Activepieces моложе n8n и заметно моложе Zapier, поэтому библиотека интеграций у него меньше. Если у вас уже есть сложные workflow на n8n — не обязательно переезжать, у него своя статья про подъём на сервере и сравнение с Make. Activepieces имеет смысл выбирать, если важен более простой и современный UI для no-code-сценариев, а не глубокая кастомизация нод.

Архитектура: что запускается и зачем

Self-hosted Activepieces состоит из трёх компонентов:

Официальный образ activepieces/activepieces можно запускать в двух режимах: всё-в-одном контейнере (веб + воркер вместе) — подходит для одного сервера с умеренной нагрузкой, или с вынесенным воркером отдельным контейнером — если нужно масштабировать обработку задач независимо от веб-интерфейса. Ниже — вариант «всё в одном», он покрывает 90% случаев на одном VPS.

Готовый docker-compose.yml

Создайте директорию проекта и файл .env рядом с docker-compose.yml:

mkdir -p /opt/activepieces && cd /opt/activepieces

.env:

AP_FRONTEND_URL=https://automation.example.com
AP_POSTGRES_PASSWORD=сгенерируйте_длинный_пароль
AP_JWT_SECRET=сгенерируйте_секрет_openssl_rand_-hex_32
AP_API_KEY=сгенерируйте_еще_один_секрет
AP_ENCRYPTION_KEY=сгенерируйте_32_символа_hex

Секреты сгенерируйте так, чтобы не гадать длину и алфавит:

openssl rand -hex 32   # для AP_JWT_SECRET и AP_API_KEY
openssl rand -hex 16   # для AP_ENCRYPTION_KEY (Activepieces ждёт 32 hex-символа = 16 байт)

docker-compose.yml:

services:
  postgres:
    image: postgres:15-alpine
    container_name: ap-postgres
    restart: unless-stopped
    environment:
      POSTGRES_USER: activepieces
      POSTGRES_PASSWORD: ${AP_POSTGRES_PASSWORD}
      POSTGRES_DB: activepieces
    volumes:
      - ap_postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U activepieces"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - ap-net

  redis:
    image: redis:7-alpine
    container_name: ap-redis
    restart: unless-stopped
    volumes:
      - ap_redis_data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - ap-net

  activepieces:
    image: activepieces/activepieces:latest
    container_name: activepieces
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:80"
    environment:
      AP_ENVIRONMENT: prod
      AP_FRONTEND_URL: ${AP_FRONTEND_URL}
      AP_EXECUTION_MODE: UNSANDBOXED
      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_API_KEY: ${AP_API_KEY}
      AP_ENCRYPTION_KEY: ${AP_ENCRYPTION_KEY}
      AP_TRIGGER_DEFAULT_POLL_INTERVAL: "5"
      AP_WEBHOOK_TIMEOUT_SECONDS: "30"
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
    volumes:
      - ap_cache:/root/.cache
    networks:
      - ap-net

networks:
  ap-net:
    driver: bridge

volumes:
  ap_postgres_data:
  ap_redis_data:
  ap_cache:

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

Запуск:

docker compose up -d
docker compose logs -f activepieces

Первый старт занимает 30–60 секунд — контейнер накатывает миграции базы. После этого интерфейс доступен на 127.0.0.1:8080 — специально не наружу, HTTPS выносим на reverse-proxy.

Переменные окружения: что реально важно

Разберём ключевые параметры, чтобы не копировать вслепую:

• AP_FRONTEND_URL — публичный адрес, под которым Activepieces будет доступен. Используется для генерации ссылок вебхуков — если указать неверно, вебхуки от внешних сервисов не будут доходить до нужного endpoint.
• AP_ENCRYPTION_KEY — ключ, которым шифруются секреты подключений (API-токены сервисов, пароли) в базе. Потеряете его — не расшифруете сохранённые подключения при восстановлении из бэкапа. Храните отдельно от volume с базой.
• AP_JWT_SECRET — подпись сессионных токенов авторизации. Смена значения разлогинит всех пользователей.
• AP_EXECUTION_MODE — UNSANDBOXED проще в поднятии на одном VPS (код piece выполняется в том же процессе), SANDBOXED изолирует выполнение через отдельные процессы — надёжнее при недоверенных пользователях, но требует больше ресурсов. Для одного администратора и своих workflow UNSANDBOXED — разумный компромисс.
• AP_TRIGGER_DEFAULT_POLL_INTERVAL — как часто (в минутах) Activepieces опрашивает сервисы без вебхуков на предмет изменений. Меньше значение — быстрее реакция, но больше нагрузка и риск упереться в rate limit стороннего API.

Все три секрета (AP_JWT_SECRET, AP_API_KEY, AP_ENCRYPTION_KEY) должны быть длинными случайными строками — не используйте одинаковые значения между dev и prod окружениями, а тем более примеры из документации.

HTTPS через reverse-proxy: Caddy или Traefik

Activepieces сам HTTPS не отдаёт, слушает по HTTP на порту 80 внутри контейнера. Пробрасывать 443 напрямую в контейнер не нужно — ставьте перед ним Caddy или Traefik.

Вариант с Caddy (проще для одного сервиса на сервере) — Caddyfile:

automation.example.com {
    reverse_proxy 127.0.0.1:8080
    encode gzip
}

Пошаговая установка Caddy с автоматическим SSL описана в отдельной статье — сертификат Let's Encrypt Caddy получит и обновит сам, вручную ничего настраивать не придётся.

Если на сервере уже крутится несколько сервисов через Traefik с общей сетью Docker, добавьте лейблы прямо в docker-compose.yml вместо публикации порта наружу:

  activepieces:
    # ...
    ports: []  # порт наружу не публикуем, отдаёт Traefik
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.activepieces.rule=Host(`automation.example.com`)"
      - "traefik.http.routers.activepieces.entrypoints=websecure"
      - "traefik.http.routers.activepieces.tls.certresolver=letsencrypt"
      - "traefik.http.services.activepieces.loadbalancer.server.port=80"
    networks:
      - ap-net
      - traefik-public

Не забудьте объявить traefik-public как внешнюю сеть (external: true) и подключить к ней контейнер Traefik — сама настройка с нуля разобрана в пошаговой инструкции по установке, если у вас его ещё нет.

Отдельно проверьте вебхуки: если источник (например, Stripe или Telegram) шлёт события на https://automation.example.com/api/v1/webhooks/..., а не на голый IP — SSL-сертификат и правильный AP_FRONTEND_URL обязательны, иначе события будут отклоняться из-за несовпадения origin.

Бэкапы и обновление версии

Всё состояние Activepieces живёт в PostgreSQL плюс ключ шифрования — Redis можно потерять без последствий (только очередь и кэш, пересоздастся). Бэкап сводится к двум вещам:

# дамп базы
docker exec ap-postgres pg_dump -U activepieces activepieces > activepieces_$(date +%F).sql

# .env с секретами — обязательно, без AP_ENCRYPTION_KEY дамп бесполезен
cp .env activepieces_env_$(date +%F).backup

Автоматизируйте это через cron на самом сервере (да, можно бэкапить Activepieces классическим cron, не обязательно через сам Activepieces):

0 3 * * * cd /opt/activepieces && docker exec ap-postgres pg_dump -U activepieces activepieces | gzip > /backups/ap_$(date +\%F).sql.gz

Восстановление — обратная операция: поднимаете чистый Postgres с теми же учётными данными, заливаете дамп через psql, кладёте тот же .env с оригинальным AP_ENCRYPTION_KEY.

Обновление до новой версии:

docker compose pull activepieces
docker compose up -d activepieces
docker compose logs -f activepieces

Перед обновлением на проде сделайте свежий дамп базы — миграции автоматические и обычно безопасные, но откатить версию образа назад после накатанной миграции не всегда тривиально. Для прода лучше зафиксировать конкретный тег вместо latest, чтобы обновление не прилетало незаметно при docker compose pull.

Сколько ресурсов нужно и как масштабировать

Ориентировочно (это ориентир, а не измеренный бенчмарк — на вашей нагрузке цифры будут отличаться):

• 1–2 vCPU, 2 ГБ RAM — комфортный старт для десятка активных flow с умеренной частотой срабатывания (веб + Postgres + Redis на одном сервере).
• 4 ГБ RAM и выше — если piece'ы тянут за собой обработку файлов, изображений или вызовы LLM с длинным контекстом (память требует не сам Activepieces, а исполняемый код piece).
• Диск — платформа лёгкая, но логи выполнения в Postgres со временем растут; настройте очистку старых run-логов в настройках проекта, иначе база будет расти без ограничений.

Если один сервер начинает не успевать (очередь Redis растёт, задачи выполняются с задержкой), масштабирование двухшаговое: сначала вынести воркер в отдельный контейнер от веб-интерфейса (оба используют тот же образ, но с разным режимом запуска — см. переменные разделения ролей в актуальной документации образа), затем поднять несколько контейнеров-воркеров на общий Postgres и Redis. Для одного проекта до этого обычно не доходит: узкое место чаще не CPU/RAM, а rate limit внешних API, к которым вы обращаетесь из flow.

Если вы уже держите на сервере n8n или Node-RED и присматриваетесь к Activepieces как к альтернативе — не обязательно выбирать что-то одно: профили Docker Compose позволяют держать несколько окружений автоматизации в одном проекте и включать нужное без конфликтов портов.

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