Что нужно для селф-хостинга n8n: конфиги, компоненты и грабли

TL;DR:

• n8n Community Edition — бесплатная. Платные self-hosted-планы (Business и Enterprise) нужны, если требуются SSO, Git-версионирование или выделенная поддержка.
• RAM — главный bottleneck. 2 ГБ — минимум по гайдам, но 4-8 ГБ — порог, с которого начинается production.
• PostgreSQL для прода. SQLite подходит для тестов, но блокируется при параллельных вебхуках и теряет данные. Если начали на SQLite, миграция все еще возможна.
• Пропишите N8N_WEBHOOK_URL с вашим доменом. Без этого вебхуки ломаются при каждом рестарте контейнера.
• Сохраните N8N_ENCRYPTION_KEY отдельно от сервера. Потеряете ключ — потеряете все учётные данные во всех воркфлоу.

Для селф-хостинга n8n на is*hosting начните с VPS с предустановленной n8n. Medium VPS (3 vCPU, 4 ГБ, 40 ГБ NVMe, от $21.24/мес.) — минимальная кинфига для single-instance n8n с умеренным трафиком. PostgreSQL работает на той же машине в Docker, но запаса на тяжёлые payload'ы или вызовы AI-моделей нет.

Во что обходится селф-хостинг n8n

Community Edition — бесплатная по Sustainable Use License (то, что n8n называет «fair-code»). Безлимитные выполнения, безлимитные воркфлоу, безлимитные пользователи, все 400+ интеграций и AI-ноды включены. Лицензия разрешает использование внутри бизнеса, но запрещает встраивать n8n в продукт, который вы продаёте другим.

Это версия, на которой работает большинство селф-хостеров. И это то, о чём этот гайд.

Если команде нужны SSO, LDAP, Git-версионирование или multi-environment — у n8n есть self-hosted Business-план (€800/мес. с лицензионным ключом) и Enterprise-тариф с кастомным ценообразованием и SLA. Но для инди-разработчиков, стартапов и технических команд — Community Edition покрывает всё необходимое.

Компромисс одинаков в любом случае: всё, чем в SaaS-версии занимается n8n — база данных, SSL, масштабирование, бэкапы — теперь ваше. Вы подписались быть собственным SRE. И n8n до сих пор не поддерживает полный программный провижн: первичную учётную запись и API-ключ нужно создавать вручную через UI — и это ощущается как 2019 год в самом неприятном смысле.

Для большинства команд, которые серьёзно занимаются автоматизацией, — оно того стоит. Но выбирайте сервер для n8n с правильными характеристиками и настройками, а не по наитию.

Требования n8n к серверу: минимум vs рекомендуемое

Что нужно n8n от сервера зависит от одного вопроса: что делают ваши воркфлоу?

Вебхук для маршрутизации лидов, который срабатывает дважды в день, и AI-пайплайн, перемалывающий тысячи документов в час, — оба работают на n8n. Но им нужно совершенно разное железо.

В документации n8n указано: 1 vCPU и 2 ГБ RAM минимум. Этого хватит, чтобы процесс запустился, но не чтобы он стабильно работал.

Требования n8n к оперативной памяти

n8n работает на Node.js и держит весь датасет воркфлоу в памяти как JS-объекты. Одно выполнение, обрабатывающее массив из 5 000 вложенных объектов, может занять 200-500 МБ. Параллельные выполнения умножают это. Сам процесс n8n в idle потребляет 300-500 МБ, PostgreSQL добавляет ещё 200-500 МБ, Redis — 50-100 МБ сверху.

Если попроще, то:

• 1 vCPU / 2 ГБ RAM — хватит, чтобы запустить n8n, открыть UI и прогнать пару простых воркфлоу. При любой параллельной нагрузке ждите OOM kill. Это песочница, не сервер.
• 4 ГБ RAM — single-instance production с умеренным трафиком. Но тяжёлые JSON-payload'ы или вызовы AI-моделей уже не влезут. Пока еще сложно признать это зоной комфорта.
• 8 ГБ RAM — нормальный single-instance production. n8n + PostgreSQL + Redis помещаются на одной машине. Можно начать тестировать Queue Mode с 1-2 воркерами.
• 16+ ГБ RAM — полноценный Queue Mode: основной процесс + 2-4 воркера + PostgreSQL + Redis + Nginx на одной машине. Нужен для high-concurrency, массовых операций и вебхук-интенсивных сценариев при стабильной нагрузке.

NVMe — обязательное требование для production

Write-ahead logging и векторные запросы PostgreSQL создают нагрузку на ввод-вывод, с которой обычные SSD не справляются. В обсуждениях на Reddit и форумах сообщества медленные AI-агенты стабильно связывают именно с хранилищем, а не CPU. Если инстанс тормозит, а htop показывает нормальную загрузку процессора, то проверьте диск.

Какая конфигурация?

Наш DevOps-инженер протестировал n8n на всей линейке VPS для n8n — от простых автоматизаций «вебхук → CRM» до production AI-пайплайнов с большими контекстными окнами.

Его вывод: требования полностью зависят от того, что происходит в воркфлоу. Обработчик тикетов поддержки, принимающий один запрос в минуту, и ETL-задача, собирающая 10 000 записей, — оба «n8n», но ресурсно живут на разных планетах.

Что он выяснил:

• Start VPS (2 vCPU, 2 ГБ, 30 ГБ NVMe, от $10.19/мес.) — разработка, тесты, один пользователь с простыми воркфлоу. 10-20 лёгких автоматизаций на SQLite.
• Medium VPS (3 vCPU, 4 ГБ, 40 ГБ NVMe, от $21.24/мес.) — минимальный single-instance production. PostgreSQL рядом с n8n в Docker, regular mode, 50-100 воркфлоу, умеренный трафик. Подходит для внутренних автоматизаций небольшой команды или агентства с несколькими клиентами на одном инстансе.
• Premium VPS (4 vCPU, 8 ГБ, 50 ГБ NVMe, от $31.99/мес.) — рекомендуемый тариф для production. Хватает памяти на n8n + PostgreSQL + Redis с запасом, можно начинать тестировать Queue Mode. Тянет команду из 20-30 человек или SaaS-стартап, который использует n8n как интеграционный бэкенд.
• Elite VPS (6 vCPU, 16 ГБ, 80 ГБ NVMe, от $47.99/мес.) — полный Queue Mode, вебхук-интенсивные интеграции, 1 000+ выполнений в день. Для тех, у кого n8n как критическая инфраструктура.
• Exclusive VPS (8 vCPU, 32 ГБ, 100 ГБ NVMe, от $71.99/мес.) — enterprise, multi-worker Queue Mode, тяжёлые AI-пайплайны. На этом уровне может иметь смысл вынести PostgreSQL на отдельную машину.

Все тарифы: n8n предустановлена, KVM-изоляция, NVMe-хранилище, 40+ локаций.

Shared-серверы подвержены CPU-троттлингу провайдера, а это джиттер в time-sensitive воркфлоу. Нужны выделенные ресурсы и VPS на KVM для этого подходит.

Если нагрузка перерастёт даже Exclusive — или нужна полная аппаратная изоляция для комплаенса — следующий шаг выделенный сервер. Production-установка нашего инженера для высоконагруженных пайплайнов работает именно на выделенном хостинге.

Выбор базы данных

n8n из коробки работает на SQLite. Для первого знакомства и тестирования воркфлоу — нормально, и это на одну вещь меньше для настройки в первый день. Но…

Почему SQLite ломается в production

SQLite использует блокировку на уровне файла, то есть проходит лишь одна запись за раз. Когда несколько вебхуков срабатывают одновременно, получаете ошибки database is locked.

Ещё хуже, когда теряются входящие записи. Вебхук отработал, n8n его получила, но выполнение не попало в историю. И, вероятно, вы даже не узнаете о потере данных.

Почему команды выбирают PostgreSQL

Если вы уже знаете, что идёте в production с реальным трафиком, — начинайте сразу с PostgreSQL. Сэкономите время на поздней миграции n8n.

PostgreSQL даёт блокировку на уровне строк, пул соединений и point-in-time recovery без остановки n8n.

Если начали на SQLite — мигрировать можно, но SQLite и PostgreSQL по-разному обрабатывают некоторые типы данных, и старые логи выполнений могут выбрасывать ошибки при импорте. Практический совет из r/AiAutomations: обрежьте историю выполнений перед миграцией и стартуйте на PostgreSQL с чистого листа. Месяцы старых логов вам не нужны, а без них переезд проходит гладко.

Наш инженер пропустил этап SQLite вообще.

Queue Mode для высокой нагрузки

Redis работает как message broker между редактором n8n и отдельными worker-процессами. Воркеры забирают и выполняют задачи независимо, поэтому тяжёлый воркфлоу не блокирует редактор и не отбирает ресурсы у других выполнений. Один юзер, ведущий 6 клиентов на одном VPS, сообщил, что Queue Mode удвоил эффективную ёмкость и снизил задержку в 4 раза.

Вот только теперь вам приходится управлять Redis, PostgreSQL и несколькими рабочими процессами, настраивая между ними правила DNS и брандмауэра.

Если вы обрабатываете более 50 запросов в минуту или запускаете ресурсоемкие рабочие процессы, которые перегружают основной процесс, то пришло время для Queue Mode. Для конфигурации из 20 рабочих процессов с умеренной нагрузкой это излишне. Не подключайте, пока реально не понадобится.

SSL, reverse proxy и проблема с вебхуками

Лайфхак: деплой n8n на VPS с помощью AI-ассистентов — проверенный метод и самый простой способ обойти типичные грабли.

Что нужно: Ubuntu 22.04+ (или любой Linux с Docker), Docker и Docker Compose, доменное имя, направленное на IP сервера.

WEBHOOK_URL

Без явно заданного N8N_WEBHOOK_URL n8n генерирует адреса вида http://localhost:5678/webhook/... — недоступные извне. Каждый внешний сервис, ожидающий callback, в итоге стучится в неверный адрес.

Один владелец агентства потерял 3 дня клиентских лидов, прежде чем обнаружил проблему — потому что со стороны n8n всё выглядело нормально.

Фикс:

N8N_WEBHOOK_URL=https://your-domain.com

Пропишите в .env или docker-compose.yml. Привяжите к публичному домену.

Reverse proxy: Nginx + Certbot

Reverse proxy терминирует SSL и закрывает прямой доступ к n8n. Стандартным решением является Nginx с Certbot. Caddy легче, но даёт меньше контроля над проксированием WebSocket.

Установка Nginx и Certbot:

sudo apt update
sudo apt install -y nginx certbot python3-certbot-nginx

Конфиг сайта в /etc/nginx/sites-available/n8n:

server {
    listen 80;
    server_name n8n.example.com;

    location / {
        proxy_pass http://localhost:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600s;
        proxy_buffering off;  # обязательно для SSE/streaming
        proxy_send_timeout 3600s;
        client_max_body_size 50M;
    }
}

Заголовки Upgrade и Connection обязательны — без них real-time UI редактора n8n ломается с ошибками WebSocket. Таймауты (3600s) не дают Nginx удалять длительные выполнения. client_max_body_size — для больших JSON-payload'ов и загрузки файлов.

Активируйте сайт и проверьте конфигурацию:

sudo ln -s /etc/nginx/sites-available/n8n /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Выпустите SSL-сертификат через Certbot:

sudo certbot --nginx -d n8n.example.com

Certbot автоматически модифицирует конфиг Nginx для SSL. Сертификаты обновляются по systemd-таймеру — убедитесь, что он активен:

sudo systemctl status certbot.timer

Деталь из документации n8n: при работе за reverse proxy пропишите N8N_PROXY_HOPS=1 в переменных окружения. Без этого n8n не может прочитать реальный IP клиента из forwarded-заголовков, и генерация URL вебхуков может по-прежнему ломаться.

Откройте только порты 80 и 443. SSH ограничьте по IP:

sudo ufw allow ssh
sudo ufw allow 80
sudo ufw allow 443
sudo ufw enable

Что ломается через месяц

Это те вещи, которые догоняют позже, когда вы уже переключились на другие задачи, а инстанс n8n работает в фоне.

Ключ шифрования, который вы забыли сохранить

N8N_ENCRYPTION_KEY шифрует все сохранённые учётные данные — API-ключи, OAuth-токены, пароли к базам. Потеряете этот ключ при миграции или пересборке контейнера — все крелы станут нечитаемыми навсегда.

Храните ключ во внешнем хранилище (Vaultwarden, Bitwarden, любой менеджер паролей) — что-то, что не привязано к серверу n8n.

Раздувание истории выполнений

n8n по умолчанию хранит каждое выполнение. За несколько месяцев это десятки гигабайт. Когда диск заполняется, PostgreSQL перестаёт писать, n8n перестаёт отвечать.

Фикс:

EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168  # часов — 7 дней

72 часов хватает большинству команд. 168 — более безопасный дефолт.

Обновления версий, ломающие воркфлоу

n8n развивается быстро, и это отлично, пока очередной релиз не ломает ваши воркфлоу из-за изменившейся схемы вывода ноды или требований к credentials между версиями. Это происходит достаточно регулярно, чтобы сообщество относилось к этому как к ожидаемому поведению.

Зафиксируйте версию:

image: n8nio/n8n:2.4.5  # не :latest

Обновляйтесь осознанно. Тестируйте на staging. Читайте changelog.

HTTP-таймаут для AI-вызовов

Эта проблема проявляется, когда вы начинаете интегрировать LLM. Дефолтный HTTP-таймаут n8n — 300 секунд. Вызовы Claude и GPT с большими контекстными окнами регулярно его превышают. Запрос отрабатывает напрямую через API, но внутри n8n падает с невнятной ошибкой таймаута.

Фикс:

# В HTTP Request нодах установите таймаут 600000 мс (10 мин)
# Для LLM-вызовов используйте нативные ноды вендора (Anthropic, OpenAI)
# вместо сырого HTTP Request — они корректно обрабатывают стриминг.
# Также увеличьте лимит payload для больших ответов:
N8N_PAYLOAD_SIZE_MAX=64  # МБ

Дефолты безопасности, которые небезопасны

n8n выполняет произвольный код — Python, JavaScript, shell-команды. Это одновременно фича и поверхность атаки.

• Побеги из песочницы

CVE-2026-1470 и CVE-2026-0863: уязвимости в движке вычисления выражений и Python-нодах, позволяющие аутентифицированному RCE на хосте. Обе CVE исправлены в n8n 1.123.17+, 2.4.5+ и 2.5.1+.

Обновитесь до n8n 2.0+, где Task Runners по умолчанию изолируют выполнение кода в отдельный процесс. На старых версиях (1.x) переключитесь на External mode — так код исполняется в Docker-сайдкаре, а не в основном процессе n8n.

• Сетевая изоляция

Не открывайте порт 5678 в публичный интернет. Поставьте n8n за VPN или identity-aware прокси (Cloudflare Tunnels). Любая HTTP Request или Code нода по умолчанию может обращаться к внутренним адресам сети, включая cloud metadata endpoints (169.254.169.254).

• Управление секретами

Если ваш .env окажется в Git-репозитории или shared volume — все credentials скомпрометированы. Используйте Vaultwarden, Doppler или Docker secrets.

Установите N8N_BLOCK_ENV_ACCESS_IN_NODE=true, чтобы Code-ноды не могли читать переменные окружения, включая ваш ключ шифрования и credentials базы данных.

Production-стек n8n

Полная конфигурация self-hosted n8n включает как минимум четыре компонента:

• n8n — Docker-контейнер с persistent volumes.
• PostgreSQL — отдельный контейнер, отдельный volume.
• Nginx/Caddy — reverse proxy, SSL-терминация.
• Certbot — управление Let's Encrypt сертификатами.

Для Queue Mode добавьте Redis и один или несколько worker-контейнеров.

Настройте dead man's switch. Внешний сервис (UptimeRobot, Healthchecks.io) пингует вебхук n8n по расписанию. Если ответы прекратились, вы получаете алерт. Звучит параноидально, но так вы словите тип сбоя, который пропускают Docker restart policies. Например, контейнер формально запущен, но завис в нерабочем состоянии.

Настройте один error-воркфлоу на каждый проект или клиента, отправляющий ошибки в Slack/Telegram. Несовпадения Stripe-подписей, просроченные Google-авторизации, LLM-таймауты.

Для мониторинга самого сервера наш инженер использует Beszel — лёгкий self-hosted дашборд для отслеживания CPU, RAM, диска и сети по машинам. Проще, чем Grafana + Prometheus, если не нужны per-workflow метрики.

Заключение

При выборе Community Edition единственной постоянной статьёй расходов для селф-хостинга n8n будет VPS.

Арифметика n8n Cloud vs селф-хостинг: n8n Cloud Pro стоит €60/месяц за 10 000 выполнений. Self-hosted Community Edition на Premium VPS — $31.99/мес. за безлимитные выполнения.

Следующий шаг — взять VPS с предустановленной n8n и поднять остальной стек.