Как установить и настроить Activepieces на VPS

MAATRIX

Zapier и Make удобны, пока не приходит счёт за тарифный план с лимитом задач в месяц или пока не нужно передавать в сценарий данные, которые не хочется отправлять в чужое облако. Activepieces — open-source автоматизация того же класса, только код открыт, а данные и выполнение сценариев остаются на вашем сервере. Ниже — рабочая установка через Docker Compose, настройка HTTPS и первые шаги после запуска.

Что такое Activepieces и когда он подходит

Activepieces — no-code платформа для связывания сервисов между собой: триггер в одном месте запускает цепочку действий в других. Логика похожа на Zapier и Make — визуальный конструктор flow, готовые интеграции («pieces» — так здесь называются коннекторы к сервисам) и возможность вставить кастомный код на TypeScript, если готового блока нет.

Технически это связка из трёх частей:

• приложение (backend + frontend) — Node.js-сервис, который отдаёт веб-интерфейс и обрабатывает API;
• PostgreSQL — хранит flow, учётные данные подключений (зашифрованные) и историю запусков;
• Redis — очередь задач между веб-частью и воркерами, которые фактически выполняют шаги сценариев.

Есть managed-версия от разработчиков (Activepieces Cloud), но смысл self-hosted установки — контроль над данными и отсутствие лимита на количество выполнений, характерного для облачных тарифов конкурентов. Из минусов честно: обновления идут чаще, чем у зрелых проектов, а часть «pieces» стабильнее других — сложные кастомные интеграции иногда проще написать самому через встроенный код-блок, чем ждать доработки готового коннектора.

Если вы уже используете n8n и он вас устраивает — переезжать смысла нет, инструменты решают одну и ту же задачу с разным UX. Activepieces стоит смотреть, если вам важнее визуальная простота интерфейса для не-разработчиков в команде или если конкретных интеграций у него больше под ваш стек.

Требования к VPS

Activepieces — не тяжёлый сервис в состоянии покоя, но воркеры при параллельном выполнении нескольких flow заметно едят CPU, особенно если внутри сценариев есть код-блоки или обработка больших JSON-ответов.

Для старта на несколько десятков активных сценариев достаточно:

• 2 vCPU, 4 ГБ RAM — минимум для связки приложение + Postgres + Redis без постоянных таймаутов;
• 40+ ГБ SSD — под систему, образы Docker и растущую базу истории выполнений;
• Ubuntu 22.04/24.04 или Debian 12 — обе поддерживаются Docker без сюрпризов;
• статический IP или домен, направленный на сервер — без домена не получится нормально настроить HTTPS для вебхуков.

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

Установка Docker и подготовка окружения

Ставим Docker Engine и Compose plugin официальным скриптом:

apt update && apt upgrade -y
curl -fsSL https://get.docker.com | sh
systemctl enable --now docker
docker compose version

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

mkdir -p /opt/activepieces && cd /opt/activepieces
openssl rand -hex 16   # это будет AP_ENCRYPTION_KEY (32 hex-символа)
openssl rand -hex 32   # это будет AP_JWT_SECRET

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

Docker Compose: приложение, Postgres, Redis

Файл .env рядом с docker-compose.yml:

cat > .env << 'EOF'
AP_ENCRYPTION_KEY=вставьте_первый_сгенерированный_ключ
AP_JWT_SECRET=вставьте_второй_сгенерированный_ключ
AP_POSTGRES_DATABASE=activepieces
AP_POSTGRES_USERNAME=activepieces
AP_POSTGRES_PASSWORD=замените_на_свой_сложный_пароль
AP_FRONTEND_URL=https://automate.ваш-домен.ru
EOF

AP_FRONTEND_URL — обязательный параметр: по нему строятся ссылки для вебхуков и OAuth-редиректы у интеграций, поэтому указывайте сюда финальный домен с https://, а не IP сервера.

Сам docker-compose.yml:

services:
  postgres:
    image: postgres:15
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${AP_POSTGRES_DATABASE}
      POSTGRES_USER: ${AP_POSTGRES_USERNAME}
      POSTGRES_PASSWORD: ${AP_POSTGRES_PASSWORD}
    volumes:
      - pg_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${AP_POSTGRES_USERNAME}"]
      interval: 5s
      timeout: 5s
      retries: 10

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

  activepieces:
    image: activepieces/activepieces:latest
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
    ports:
      - "127.0.0.1:8080:80"
    environment:
      AP_ENCRYPTION_KEY: ${AP_ENCRYPTION_KEY}
      AP_JWT_SECRET: ${AP_JWT_SECRET}
      AP_FRONTEND_URL: ${AP_FRONTEND_URL}
      AP_POSTGRES_DATABASE: ${AP_POSTGRES_DATABASE}
      AP_POSTGRES_HOST: postgres
      AP_POSTGRES_PORT: "5432"
      AP_POSTGRES_USERNAME: ${AP_POSTGRES_USERNAME}
      AP_POSTGRES_PASSWORD: ${AP_POSTGRES_PASSWORD}
      AP_REDIS_HOST: redis
      AP_REDIS_PORT: "6379"
      AP_EXECUTION_MODE: UNSANDBOXED

volumes:
  pg_data:
  redis_data:

Порт приложения намеренно опубликован только на 127.0.0.1 — наружу его отдаст reverse proxy с TLS, напрямую по HTTP сервис торчать в интернет не должен.

Поднимаем стек:

docker compose up -d
docker compose logs -f activepieces

Первый запуск накатывает миграции базы — дождитесь в логах строки о готовности сервера, обычно это занимает от нескольких секунд до пары минут в зависимости от диска.

HTTPS через reverse proxy и firewall

Домен должен смотреть A-записью на IP сервера до этого шага. Проще всего поднять Caddy — он сам получает и продлевает сертификат Let's Encrypt без ручной возни с certbot; пошагово это разобрано в статье про Caddy с авто-SSL на Ubuntu 24.04. Если у вас на сервере уже стоит nginx или несколько сервисов за одним прокси, сравнение вариантов — в статье Traefik или Nginx Proxy Manager.

Минимальный Caddyfile для Activepieces:

automate.ваш-домен.ru {
    reverse_proxy 127.0.0.1:8080
}

systemctl reload caddy

Дальше закрываем всё лишнее файрволом — снаружи открыты только SSH и веб-порты, порт 8080 наружу не публикуется вовсе (сокет и так слушает только localhost, но дублировать защиту на уровне firewall не мешает):

ufw allow OpenSSH
ufw allow 80,443/tcp
ufw enable

Подробнее про настройку самого firewall — в статье UFW на VPS. Общий подход к запуску Docker Compose стеков в проде, с логированием и рестарт-политиками, описан в статье про Docker Compose для продакшена.

Первый вход и подключение сервисов

Откройте https://automate.ваш-домен.ru — при первом заходе Activepieces предложит создать учётную запись администратора (email + пароль). Это локальная авторизация, никаких внешних вызовов на этом шаге не требуется.

После входа рабочий процесс такой:

1. Создайте flow — выбираете триггер (вебхук, расписание по cron, событие в конкретном сервисе через готовый piece) и добавляете шаги-действия.
2. Подключите сервис — при добавлении действия для конкретного piece (например, отправка сообщения в Telegram или запись строки в Google Sheets) Activepieces попросит подключение: API-ключ вручную или OAuth-редирект, если сервис его поддерживает. Именно для OAuth-редиректа критично, чтобы AP_FRONTEND_URL в .env совпадал с реальным доменом — иначе провайдер вернёт токен не туда.
3. Проверьте flow тестовым запуском — кнопка Test Flow выполняет сценарий один раз и показывает, что пришло на каждом шаге, это удобнее, чем ловить ошибку по логам после того, как flow уже включён.
4. Включите flow — переключатель Publish/Enable активирует его на постоянную работу: вебхуки начинают принимать запросы, расписания — тикать по cron.

Для вебхук-триггеров URL выдаётся автоматически на основе AP_FRONTEND_URL — скопируйте его из карточки триггера и пропишите на стороне внешнего сервиса (например, в настройках CRM или платёжного шлюза).

Обновление, бэкапы и что проверять при проблемах

Обновление. Образ activepieces/activepieces:latest обновляется командой:

cd /opt/activepieces
docker compose pull activepieces
docker compose up -d activepieces

Перед обновлением на проде стоит сначала посмотреть changelog проекта на GitHub (activepieces/activepieces) — миграции базы применяются автоматически при старте, но иногда между релизами меняется формат переменных окружения, и лучше узнать об этом заранее, а не по упавшему контейнеру.

Бэкап. Данные, которые нельзя потерять, — это Postgres (сами flow, история, зашифрованные учётные данные подключений) и значение AP_ENCRYPTION_KEY из .env: без него сохранённая база с подключениями к сервисам бесполезна.

docker compose exec postgres pg_dump -U activepieces activepieces > /opt/backups/activepieces_$(date +%F).sql

Заверните это в cron и храните хотя бы несколько последних копий за пределами самого сервера.

Если flow не запускается по расписанию — проверьте логи воркера (docker compose logs activepieces, там же и воркер, если AP_EXECUTION_MODE не вынесен в отдельный сервис) и что контейнер Redis жив: очередь задач идёт через него, и если Redis перезапустился без сохранения volume, накопленные в очереди задачи теряются.

Если вебхук не приходит — сначала исключите reverse proxy: curl -I https://automate.ваш-домен.ru должен отдавать 200/301, а не таймаут. Дальше проверьте, что внешний сервис действительно шлёт запрос на актуальный URL — он завязан на AP_FRONTEND_URL, и если домен менялся после первой генерации flow, старые ссылки на вебхуки могут указывать на прежний адрес.

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