Activepieces на Ubuntu 24.04: пошаговая установка

MAATRIX

Если вы уже считаете, во сколько обходится Zapier или Make при росте числа задач, знакомая история: тарифы растут быстрее, чем количество реально нужных автоматизаций, а часть данных вы вообще не хотите отправлять в чужое облако. Activepieces — open-source альтернатива с похожим визуальным конструктором, но развёрнутая на своём сервере: без лимитов на количество «тасков» и с полным контролем над тем, куда уходят данные. Ниже — пошаговая установка на чистый Ubuntu 24.04, от подготовки сервера до первого рабочего flow.

Что такое Activepieces и когда его стоит хостить самому

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

Из практических отличий, которые имеют значение при выборе:

• Модель оплаты. В облачных сервисах вы платите за количество выполнений (тасков/операций). На своём сервере ограничение — только вычислительные ресурсы VPS, а не тарифная сетка.
• Данные. Все переменные окружения, токены API подключённых сервисов и логи выполнения остаются на вашем сервере, а не в стороннем облаке.
• Коннекторы (pieces). У Activepieces их заметно меньше, чем у Zapier, но база покрывает основные категории: CRM, мессенджеры, таблицы, email, вебхуки, HTTP-запросы произвольно к любому API — этого достаточно для большинства бизнес-сценариев.
• AI-блоки. Есть встроенные пайсы для работы с языковыми моделями (в том числе через собственный API-ключ), что удобно, если автоматизация включает обработку текста или классификацию.

Self-hosting имеет смысл, если у вас больше 5–10 активных workflow, часть данных чувствительна (платежи, персональные данные клиентов), или вы просто устали считать таски. Если задач мало и разово — облачный тариф может оказаться дешевле, чем аренда сервера под простаивающий инстанс.

Если вы уже сравнивали self-hosted инструменты автоматизации, обратите внимание на сравнение n8n и Make — логика выбора между облаком и своим сервером там во многом та же.

Требования к серверу и подготовка Ubuntu 24.04

Activepieces — это несколько контейнеров (сам сервис, PostgreSQL, Redis), и для комфортной работы с 5–15 workflow достаточно скромной конфигурации:

Это ориентир, а не измеренный бенчмарк: реальная нагрузка сильно зависит от количества параллельных выполнений и от того, используете ли вы «тяжёлые» шаги вроде обработки файлов или вызовов LLM. Если запусков много и параллельно — закладывайте больше RAM с запасом, PostgreSQL и очередь Redis под нагрузкой требовательны к памяти.

Начинаем с обновления системы и создания отдельного пользователя без root-прав — разворачивать сервисы под root на продакшене не стоит:

apt update && apt upgrade -y
adduser deploy
usermod -aG sudo deploy
su - deploy

Если на сервере всего 2 ГБ RAM, имеет смысл сразу настроить swap — сборка образов и одновременная работа Postgres/Redis/Node может кратковременно выедать всю память. Как это сделать по шагам, разобрано в статье про настройку swap на Ubuntu 24.04.

Устанавливаем Docker и Docker Compose

Activepieces официально распространяется как набор Docker-образов, поэтому Docker — обязательное условие. Ставим через официальный скрипт:

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker $USER
newgrp docker

Проверяем версии:

docker --version
docker compose version

Современные версии Docker уже включают плагин compose (команда docker compose, без дефиса), отдельно ставить docker-compose не нужно. Если хотите разобрать этот шаг подробнее — с nftables-фаерволом, лимитами и правильной структурой каталогов — есть отдельная статья про установку Docker на Ubuntu 24.04 с нуля.

Создаём рабочую директорию проекта:

mkdir -p ~/activepieces && cd ~/activepieces

Разворачиваем Activepieces через Docker Compose

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

openssl rand -hex 16   # AP_ENCRYPTION_KEY — 32 hex-символа
openssl rand -hex 32   # AP_JWT_SECRET
openssl rand -base64 24 | tr -d '/=+'   # пароль для Postgres

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

cat > .env <<'EOF'
AP_ENCRYPTION_KEY=вставьте_сгенерированный_hex
AP_JWT_SECRET=вставьте_сгенерированный_hex
AP_POSTGRES_PASSWORD=вставьте_сгенерированный_пароль
AP_FRONTEND_URL=https://automation.ваш-домен.ru
EOF
chmod 600 .env

Теперь docker-compose.yml. Структура типовая для self-hosted версии: приложение + PostgreSQL для хранения flow и логов + Redis для очереди задач.

services:
  activepieces:
    image: activepieces/activepieces:latest
    container_name: activepieces
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:80"
    env_file:
      - .env
    environment:
      AP_FRONTEND_URL: "${AP_FRONTEND_URL}"
      AP_ENCRYPTION_KEY: "${AP_ENCRYPTION_KEY}"
      AP_JWT_SECRET: "${AP_JWT_SECRET}"
      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"
    depends_on:
      - postgres
      - redis

  postgres:
    image: postgres:15-alpine
    container_name: activepieces-postgres
    restart: unless-stopped
    environment:
      POSTGRES_DB: activepieces
      POSTGRES_USER: activepieces
      POSTGRES_PASSWORD: "${AP_POSTGRES_PASSWORD}"
    volumes:
      - ap_pg_data:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine
    container_name: activepieces-redis
    restart: unless-stopped
    volumes:
      - ap_redis_data:/data

volumes:
  ap_pg_data:
  ap_redis_data:

Важный нюанс: порт приложения проброшен только на 127.0.0.1, наружу сервис не торчит — доступ снаружи организуем через reverse proxy с HTTPS в следующем шаге, напрямую по HTTP отдавать панель с паролями от подключённых сервисов небезопасно.

Названия переменных окружения у Activepieces время от времени меняются между релизами — прежде чем разворачивать на продакшене, сверьтесь с .env.example в официальном репозитории проекта на GitHub, чтобы не потерять новые обязательные параметры.

Запускаем:

docker compose up -d
docker compose logs -f activepieces

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

curl -I http://127.0.0.1:8080

Ожидаем HTTP/1.1 200 OK или редирект на страницу входа.

Настраиваем HTTPS и домен через Caddy

Открывать панель автоматизации по голому HTTP, да ещё с прод-токенами внутри — плохая идея. Проще всего закрыть это Caddy: он сам получает и обновляет сертификат Let's Encrypt, конфиг занимает несколько строк.

Ставим Caddy (если ещё не стоит — подробный разбор есть в статье про установку Caddy с авто-SSL на Ubuntu 24.04):

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update && sudo apt install -y caddy

Конфиг /etc/caddy/Caddyfile:

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

Перед этим убедитесь, что A-запись домена уже указывает на IP сервера — иначе Caddy не сможет пройти проверку домена для выпуска сертификата. Применяем конфиг:

sudo systemctl reload caddy

Через несколько секунд сертификат выпустится автоматически, и https://automation.ваш-домен.ru откроет интерфейс входа Activepieces уже по HTTPS. Не забудьте, что значение AP_FRONTEND_URL в .env должно совпадать с этим адресом — иначе вебхуки и ссылки внутри писем от сервиса будут указывать не туда.

Первый запуск: администратор, подключения и бэкапы

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

Дальше стоит сделать три вещи до того, как вы начнёте строить продовые flow:

1. Подключить первые сервисы. В разделе Connections добавляются API-ключи и OAuth-подключения к внешним приложениям — они шифруются тем самым AP_ENCRYPTION_KEY, который вы сгенерировали на старте.
2. Проверить вебхук-триггеры. Если flow должен запускаться по входящему вебхуку (например, от Telegram-бота или формы), убедитесь, что AP_FRONTEND_URL резолвится снаружи и Caddy действительно проксирует запросы — протестировать удобно через curl -X POST https://automation.ваш-домен.ru/api/v1/webhooks/... с телом тестового запроса.
3. Настроить регулярный бэкап тома с базой. Вся ценность self-hosted автоматизации — в накопленных flow и подключениях, а они целиком живут в volume ap_pg_data. Простейший вариант — снапшот тома в cron:

docker run --rm \
  -v activepieces_ap_pg_data:/data \
  -v ~/backups:/backup \
  alpine tar czf /backup/activepieces-$(date +%F).tar.gz -C /data .

Если бэкапы уже организованы через Postgres в других проектах на сервере, логичнее сделать pg_dump по расписанию, а не архивировать весь volume — так проще восстановить конкретную базу, не трогая остальные контейнеры. Общий подход к этому разобран в статье про установку и настройку PostgreSQL на VPS, если Activepieces у вас соседствует с другими сервисами на базе Postgres.

Обновление до новой версии — обычно docker compose pull && docker compose up -d, но перед апдейтом на проде стоит сначала сделать снапшот тома: миграции базы между мажорными версиями иногда необратимы в обратную сторону.

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