Activepieces на сервере: частые ошибки и решения

MAATRIX

Activepieces — open-source альтернатива Zapier для автоматизации между сервисами, и на первый взгляд разворачивается она просто: один docker compose up и всё работает. Но стоит вывести инстанс в продакшен — за доменом, с реальными интеграциями и потоком вебхуков — как всплывают проблемы, которых не было на локальном докере. Ниже — конкретные ошибки, с которыми сталкиваются на VPS, и как их закрывать без танцев с бубном.

Контейнер стартует и сразу падает

Самая частая ситуация после docker compose up -d: контейнер activepieces в статусе Restarting, а в логах — обрыв на старте. Смотрим причину сразу, не гадая:

docker compose logs -f activepieces --tail=100

Три типичных сценария:

Не хватает памяти. Activepieces собирает пайплайны в Node.js-процессе, и на сборке build-шагов или при параллельных запусках воркер легко упирается в лимит. На VPS с 1 ГБ RAM контейнер валится с JavaScript heap out of memory или просто получает OOM-kill от ядра — это видно через dmesg | grep -i oom или journalctl -k | tail -50. Проверить лимит контейнера:

docker stats activepieces --no-stream

Для активного использования с несколькими флоу и внешними интеграциями закладывайте минимум 2 ГБ RAM на сам Activepieces, отдельно от базы данных.

Не поднялась база. Activepieces требует PostgreSQL и Redis, и если он стартует раньше, чем Postgres готов принимать соединения, приложение падает с ошибкой подключения. depends_on в Docker Compose без condition: service_healthy не гарантирует, что база реально готова — она просто гарантирует порядок запуска контейнеров, не готовность сервиса внутри:

services:
  postgres:
    image: postgres:16
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${AP_POSTGRES_USERNAME}"]
      interval: 5s
      timeout: 5s
      retries: 10
  activepieces:
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy

Неверный AP_ENCRYPTION_KEY. Ключ шифрования секретов должен быть валидной hex-строкой фиксированной длины. Если вы сгенерировали его наспех через echo "mykey" | base64 — Activepieces откажется стартовать с ошибкой валидации. Генерируйте правильно:

openssl rand -hex 16

База данных: миграции и подключение

Вторая по частоте боль — Activepieces не может достучаться до Postgres или падает на миграциях при апдейте.

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

docker compose exec postgres psql -U activepieces -d activepieces -c "\dt" | head -20

Если таблиц нет вообще — миграции не отработали. Обычно причина в том, что переменные AP_POSTGRES_DATABASE, AP_POSTGRES_USERNAME, AP_POSTGRES_PASSWORD в .env не совпадают с тем, что задано при инициализации контейнера Postgres (POSTGRES_DB, POSTGRES_USER, POSTGRES_PASSWORD). Они должны быть буквально идентичны — Activepieces не создаёт базу сам, если её нет:

docker compose exec postgres psql -U postgres -c "\l" | grep activepieces

При обновлении версии образа миграции применяются автоматически при старте, но если процесс был прерван (например, контейнер убили посреди миграции), база остаётся в промежуточном состоянии. Самый надёжный выход — восстановление из бэкапа, сделанного до апдейта:

docker compose exec postgres pg_dump -U activepieces activepieces > backup_$(date +%F).sql

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

Вебхуки не долетают до флоу

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

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

AP_FRONTEND_URL=https://automate.example.com

После смены этой переменной нужен полный рестарт контейнера, простого reload недостаточно — URL зашивается в конфигурацию при старте процесса.

2. Проверьте, что запрос вообще доходит до сервера. Смотрите логи reverse proxy (nginx или Traefik) — приходит ли POST-запрос на эндпоинт вебхука:

tail -f /var/log/nginx/access.log | grep webhook

Если запросов нет вообще — проблема на стороне внешнего сервиса или DNS, не в Activepieces. Если запросы есть, но с кодом 502/504 — проблема в проксировании, смотрите следующий пункт.

3. Таймаут на прокси. По умолчанию nginx закрывает соединение через 60 секунд, а некоторые флоу с внешними API-вызовами (особенно к LLM или медленным сервисам) выполняются дольше, и вебхук успевает отдать 200 только после того, как прокси уже оборвал соединение. Увеличьте таймауты:

location /api/v1/webhooks/ {
    proxy_pass http://127.0.0.1:8080;
    proxy_read_timeout 300s;
    proxy_send_timeout 300s;
}

4. Триггер выключен. Банально, но часто упускается: после импорта флоу или после ручного редактирования триггер может остаться в состоянии disabled. Проверьте статус флоу в UI — переключатель публикации должен быть активен, черновик (draft) вебхуки не принимает.

Воркер зависает или не разгребает очередь

Флоу запускаются, встают в очередь, но не выполняются — либо выполняются с большой задержкой. Это почти всегда про Redis и воркер-процесс.

Проверьте, жив ли Redis и отвечает ли он:

docker compose exec redis redis-cli ping

Если очередь растёт (смотрите вкладку Runs в UI — количество QUEUED), а не разгребается, причины обычно две:

• Воркеру не хватает AP_EXECUTION_MODE. Для нагруженных инстансов однопроцессный режим (UNSANDBOXED) не годится — переключайтесь на изолированное исполнение шагов и разносите API-сервер и воркер на отдельные реплики через docker compose up --scale, если нагрузка это позволяет.
• Утечка соединений к Postgres. Каждый запуск флоу открывает соединение к базе, и если max_connections в Postgres выставлен низко (по умолчанию 100), а флоу много и они параллельны — новые запуски встают в очередь, ожидая свободный слот. Проверка:

docker compose exec postgres psql -U activepieces -c "SELECT count(*) FROM pg_stat_activity;"

Если число близко к лимиту — поднимайте max_connections в конфиге Postgres или добавляйте PgBouncer перед базой как пул соединений.

Не подключаются внешние интеграции (OAuth и API-ключи)

При настройке connection к внешнему сервису (Google, Slack, GitHub и т.д.) через OAuth Activepieces должен вернуть пользователя обратно на AP_FRONTEND_URL после авторизации. Если домен настроен неверно или в приложении на стороне провайдера (Google Cloud Console, Slack App) указан устаревший redirect URI — авторизация зависает на белом экране или падает с ошибкой redirect_uri_mismatch.

Redirect URI для большинства коннекторов Activepieces строится как:

https://automate.example.com/redirect

Сверьте его точь-в-точь (включая протокол https и отсутствие trailing slash) с тем, что указано в настройках OAuth-приложения у провайдера. Каждый провайдер (Google, Microsoft, GitHub) хранит свой список разрешённых redirect URI — при переезде на новый домен их нужно обновить вручную в каждом из них, Activepieces сам это не сделает.

Для интеграций по API-ключу (не OAuth) типичная ошибка — ключ с ограниченными правами (scope). Например, ключ Notion без доступа к нужной базе данных вернёт 403 при попытке синхронизации — это не баг Activepieces, а вопрос прав самого ключа на стороне сервиса.

SSL, домен и обратный прокси

Если Activepieces открывается по IP, но не по домену с HTTPS — почти всегда дело в конфигурации reverse proxy, а не в самом приложении. Готовая рабочая связка через Traefik с автообновлением сертификатов Let's Encrypt описана в статье про Traefik как reverse proxy для докера — та же логика применима и к Activepieces, просто меняете имя сервиса в лейблах.

Если вместо Traefik используете Caddy — он проще в настройке автоSSL и подходит для одного-двух сервисов на сервере, подробности в статье про Caddy с авто-SSL.

Общая структура docker-compose с nginx в качестве прокси:

services:
  activepieces:
    image: activepieces/activepieces:latest
    restart: unless-stopped
    environment:
      AP_FRONTEND_URL: https://automate.example.com
      AP_POSTGRES_HOST: postgres
      AP_REDIS_HOST: redis
      AP_ENCRYPTION_KEY: ${AP_ENCRYPTION_KEY}
      AP_JWT_SECRET: ${AP_JWT_SECRET}
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
    expose:
      - "8080"

Порт наружу не публикуйте напрямую (ports) — используйте expose и проксируйте через nginx/Traefik/Caddy с SSL-терминацией. Прямой доступ по HTTP к порту 8080 без прокси — верный способ отдать логин-форму в открытом виде.

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

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