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

MAATRIX

Если вам нужно следить за изменениями на сайтах, дёргать API по расписанию и автоматически реагировать на события — без подписки на облачный сервис и без ограничений по числу правил — Huginn закрывает эту задачу почти полностью бесплатно. Это open-source агентная система: вы собираете сценарий из связанных между собой «агентов» (Agents), каждый из которых умеет читать RSS, парсить HTML, слать HTTP-запросы, писать в Telegram или email. Ниже — рабочая установка на чистый VPS через Docker Compose, с PostgreSQL и HTTPS, плюс разбор типичных грабель, на которые натыкаются при первом знакомстве с проектом.

Что такое Huginn и чем он отличается от n8n

Huginn — проект на Ruby on Rails, появившийся ещё в 2013 году как «твой личный IFTTT, который живёт у тебя на сервере». Идея простая: вместо визуального конструктора потоков данных (как в n8n или Node-RED) здесь используется граф агентов — каждый агент подписан на события других агентов и порождает свои события.

Ключевое отличие от n8n или Make — Huginn изначально заточен под мониторинг и веб-скрейпинг, а не под интеграцию бизнес-приложений через сотни готовых коннекторов. У него нет визуального drag-and-drop редактора нод в привычном виде: агенты настраиваются через формы с JSON-конфигом, а связи между ними — это подписки на выходные события. Порог входа выше, чем у n8n, зато для задач вида «раз в 10 минут проверь страницу на изменение цены и напиши в Telegram» это почти идеальный инструмент — легковесный и не требующий отдельного воркер-пула на каждый сценарий.

Если вы уже сравнивали инструменты автоматизации, полезно почитать сравнение n8n и Make — логика выбора между «своим сервером» и SaaS там та же, что и для Huginn.

Требования к серверу

Huginn — не самое лёгкое приложение: Ruby on Rails плюс PostgreSQL плюс фоновые джобы через Delayed::Job или Resque съедают память заметнее, чем условный Node-RED. Для одного-двух десятков активных сценариев (агентов) с проверкой раз в несколько минут этого достаточно:

На 1 ГБ RAM Huginn стартует, но под нагрузкой (несколько десятков агентов с расписанием раз в минуту плюс сборка ассетов при обновлении) сервер уходит в swap и тормозит. Если ставите на бюджетный тариф, заранее настройте swap-файл — это дешевле, чем разбираться с OOM killer в 2 часа ночи.

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

Если Docker ещё не стоит, поставьте его с нуля — есть отдельный разбор для Ubuntu 24.04. Дальше — минимальная подготовка:

sudo apt update && sudo apt upgrade -y
sudo mkdir -p /opt/huginn
cd /opt/huginn

Сгенерируйте два секрета, которые понадобятся ниже — APP_SECRET_TOKEN для Rails-сессий и пароль для базы:

openssl rand -hex 64   # APP_SECRET_TOKEN
openssl rand -hex 24   # пароль PostgreSQL

Сохраните оба значения — они пойдут в .env.

Docker Compose: Huginn + PostgreSQL

Официальный образ huginn/huginn — это all-in-one контейнер: внутри него живут веб-процесс (unicorn), планировщик и воркер фоновых джоб. Для продакшена такое решение годится, если вы не гонитесь за горизонтальным масштабированием — для одного VPS это даже удобнее, чем разносить всё на три контейнера.

Создайте .env:

cat > /opt/huginn/.env <<'EOF'
POSTGRES_USER=huginn
POSTGRES_PASSWORD=замените_на_свой_пароль
POSTGRES_DB=huginn_production
APP_SECRET_TOKEN=замените_на_свой_токен
DOMAIN=huginn.example.com
INVITATION_CODE=замените_на_свою_фразу
EOF

INVITATION_CODE — это код приглашения, без которого никто не сможет зарегистрироваться на вашем инстансе. Обязательно смените дефолтное значение — публичные Huginn-инстансы с забытым try-huginn в качестве кода регулярно попадают в чужие скан-листы.

Теперь docker-compose.yml:

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

  huginn:
    image: huginn/huginn:latest
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    ports:
      - "127.0.0.1:3000:3000"
    environment:
      DATABASE_ADAPTER: postgresql
      DATABASE_NAME: ${POSTGRES_DB}
      DATABASE_USERNAME: ${POSTGRES_USER}
      DATABASE_PASSWORD: ${POSTGRES_PASSWORD}
      DATABASE_HOST: postgres
      DATABASE_PORT: 5432
      APP_SECRET_TOKEN: ${APP_SECRET_TOKEN}
      DOMAIN: ${DOMAIN}
      FORCE_SSL: "false"
      INVITATION_CODE: ${INVITATION_CODE}
      SMTP_DOMAIN: ${DOMAIN}
      TIMEZONE: Europe/Moscow
    volumes:
      - huginn_data:/var/lib/huginn

volumes:
  huginn_pg_data:
  huginn_data:

Обратите внимание: порт 3000 привязан к 127.0.0.1, наружу приложение не торчит. HTTPS и внешний доступ отдаём реверс-прокси — так безопаснее и проще с сертификатами.

FORCE_SSL: "false" — потому что SSL терминирует прокси перед контейнером, а не сам Rails-процесс внутри. Если поставить true без прокси-терминации, получите редирект-луп.

Поднимаем:

cd /opt/huginn
docker compose up -d
docker compose logs -f huginn

Первый старт занимает пару минут — контейнер сам прогоняет миграции базы (rails db:migrate) при запуске. Дождитесь строки вида Listening on http://0.0.0.0:3000 в логах, прежде чем идти дальше.

HTTPS через Caddy

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

huginn.example.com {
    reverse_proxy 127.0.0.1:3000
    encode gzip
}

После sudo systemctl reload caddy (или перезапуска контейнера Caddy) сайт должен открыться по HTTPS с валидным сертификатом. Если предпочитаете Nginx с certbot — логика та же: проксируем на 127.0.0.1:3000, добавляем заголовки X-Forwarded-Proto и X-Forwarded-For, иначе Huginn будет путаться со схемой в ссылках писем и вебхуков.

Не забудьте открыть только нужные порты в фаерволе — UFW на VPS с правилами на 80/443/22 достаточно, порт 3000 наружу светить не нужно вообще, раз прокси и так работает через localhost.

Первый вход и создание агентов

Откройте https://huginn.example.com/users/sign_up, укажите email, пароль и код из INVITATION_CODE. После входа вы увидите пустой Dashboard — начинать удобнее не с нуля, а с готовых сценариев.

В Huginn есть механизм Scenarios — готовые связки агентов, которые можно импортировать по ссылке в формате JSON. На вкладке Scenarios → Import from URL вставьте адрес нужного сценария (в вики проекта на GitHub есть подборка примеров: мониторинг цен, отслеживание погоды, парсинг курсов валют). Импорт создаёт сразу набор связанных агентов — быстрее, чем собирать вручную.

Если собираете свой сценарий с нуля, базовый паттерн такой:

1. Website Agent — периодически скачивает страницу и через CSS/XPath-селектор вытаскивает нужные данные (цену, заголовок, наличие товара).
2. Trigger Agent — сравнивает новое значение со старым и порождает событие только при выполнении условия (например, цена упала).
3. Post Agent или Email Agent — отправляет результат: HTTP POST на вебхук Telegram-бота, письмо, или запись в другую систему.

Пример конфига Website Agent для проверки цены на странице (упрощённо, реальные селекторы зависят от разметки конкретного сайта):

{
  "url": "https://example-shop.ru/product/123",
  "type": "html",
  "mode": "on_change",
  "extract": {
    "price": {
      "css": ".product-price",
      "value": "normalize-space(.)"
    }
  }
}

Поле schedule агента задаёт частоту опроса — от every_1m до every_12h. Для внешних сайтов не ставьте частоту выше разумной: слишком агрессивный поллинг может привести к бану по IP, особенно если сайт защищён Cloudflare или похожим WAF.

Уведомления в Telegram

Самый частый финальный шаг цепочки — отправка уведомления. Через Post Agent это делается прямым HTTP-запросом к Bot API Telegram, без дополнительных плагинов:

{
  "post_url": "https://api.telegram.org/bot<TOKEN>/sendMessage",
  "content_type": "json",
  "method": "post",
  "payload": {
    "chat_id": "<CHAT_ID>",
    "text": "{{ message }}"
  },
  "headers": {},
  "emit_events": "false"
}

<TOKEN> получаете у @BotFather, <CHAT_ID> — id чата или канала, куда бот должен слать сообщения. Переменную {{ message }} формирует Trigger Agent или Formatting Agent на предыдущем шаге цепочки — так вы собираете текст уведомления из вытащенных данных.

Резервное копирование и обновление

Вся полезная нагрузка Huginn — это база PostgreSQL (сами агенты, их конфиги, логи событий) и volume huginn_data (загруженные файлы, если агенты их создают). Бэкап минимум:

docker compose exec postgres pg_dump -U huginn huginn_production | gzip > /opt/huginn/backups/huginn-$(date +%F).sql.gz

Поставьте это в cron с ротацией на пару недель, а лучше — сразу настройте резервное копирование Docker volume целиком, чтобы не терять и сам volume контейнера.

Обновление образа:

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

Перед крупным обновлением обязательно снимите свежий бэкап базы — миграции Rails необратимы без отката из дампа, а проект хоть и активно поддерживается сообществом, но не выпускает формальных релизов с чёткими changelog каждую неделю — читайте issues на GitHub, если что-то ломается после апдейта.

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