Для селф-хостинга n8n на is*hosting начните с VPS с предустановленной n8n. Medium VPS (3 vCPU, 4 ГБ, 40 ГБ NVMe, от $21.24/мес.) — минимальная кинфига для single-instance n8n с умеренным трафиком. PostgreSQL работает на той же машине в Docker, но запаса на тяжёлые payload'ы или вызовы AI-моделей нет.
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 от сервера зависит от одного вопроса: что делают ваши воркфлоу?
Вебхук для маршрутизации лидов, который срабатывает дважды в день, и AI-пайплайн, перемалывающий тысячи документов в час, — оба работают на n8n. Но им нужно совершенно разное железо.
В документации n8n указано: 1 vCPU и 2 ГБ RAM минимум. Этого хватит, чтобы процесс запустился, но не чтобы он стабильно работал.
n8n работает на Node.js и держит весь датасет воркфлоу в памяти как JS-объекты. Одно выполнение, обрабатывающее массив из 5 000 вложенных объектов, может занять 200-500 МБ. Параллельные выполнения умножают это. Сам процесс n8n в idle потребляет 300-500 МБ, PostgreSQL добавляет ещё 200-500 МБ, Redis — 50-100 МБ сверху.
Если попроще, то:
Write-ahead logging и векторные запросы PostgreSQL создают нагрузку на ввод-вывод, с которой обычные SSD не справляются. В обсуждениях на Reddit и форумах сообщества медленные AI-агенты стабильно связывают именно с хранилищем, а не CPU. Если инстанс тормозит, а htop показывает нормальную загрузку процессора, то проверьте диск.
Наш DevOps-инженер протестировал n8n на всей линейке VPS для n8n — от простых автоматизаций «вебхук → CRM» до production AI-пайплайнов с большими контекстными окнами.
Его вывод: требования полностью зависят от того, что происходит в воркфлоу. Обработчик тикетов поддержки, принимающий один запрос в минуту, и ETL-задача, собирающая 10 000 записей, — оба «n8n», но ресурсно живут на разных планетах.
Что он выяснил:
Все тарифы: n8n предустановлена, KVM-изоляция, NVMe-хранилище, 40+ локаций.
Shared-серверы подвержены CPU-троттлингу провайдера, а это джиттер в time-sensitive воркфлоу. Нужны выделенные ресурсы и VPS на KVM для этого подходит.
Если нагрузка перерастёт даже Exclusive — или нужна полная аппаратная изоляция для комплаенса — следующий шаг выделенный сервер. Production-установка нашего инженера для высоконагруженных пайплайнов работает именно на выделенном хостинге.
n8n из коробки работает на SQLite. Для первого знакомства и тестирования воркфлоу — нормально, и это на одну вещь меньше для настройки в первый день. Но…
SQLite использует блокировку на уровне файла, то есть проходит лишь одна запись за раз. Когда несколько вебхуков срабатывают одновременно, получаете ошибки database is locked.
Ещё хуже, когда теряются входящие записи. Вебхук отработал, n8n его получила, но выполнение не попало в историю. И, вероятно, вы даже не узнаете о потере данных.
Если вы уже знаете, что идёте в production с реальным трафиком, — начинайте сразу с PostgreSQL. Сэкономите время на поздней миграции n8n.
PostgreSQL даёт блокировку на уровне строк, пул соединений и point-in-time recovery без остановки n8n.
Если начали на SQLite — мигрировать можно, но SQLite и PostgreSQL по-разному обрабатывают некоторые типы данных, и старые логи выполнений могут выбрасывать ошибки при импорте. Практический совет из r/AiAutomations: обрежьте историю выполнений перед миграцией и стартуйте на PostgreSQL с чистого листа. Месяцы старых логов вам не нужны, а без них переезд проходит гладко.
Наш инженер пропустил этап SQLite вообще.
Redis работает как message broker между редактором n8n и отдельными worker-процессами. Воркеры забирают и выполняют задачи независимо, поэтому тяжёлый воркфлоу не блокирует редактор и не отбирает ресурсы у других выполнений. Один юзер, ведущий 6 клиентов на одном VPS, сообщил, что Queue Mode удвоил эффективную ёмкость и снизил задержку в 4 раза.
Вот только теперь вам приходится управлять Redis, PostgreSQL и несколькими рабочими процессами, настраивая между ними правила DNS и брандмауэра.
Если вы обрабатываете более 50 запросов в минуту или запускаете ресурсоемкие рабочие процессы, которые перегружают основной процесс, то пришло время для Queue Mode. Для конфигурации из 20 рабочих процессов с умеренной нагрузкой это излишне. Не подключайте, пока реально не понадобится.
n8n предустановлена на KVM-изолированном VPS с NVMe. 6 тарифов от $10.19/мес., 40+ локаций, root-доступ.
Лайфхак: деплой n8n на VPS с помощью AI-ассистентов — проверенный метод и самый простой способ обойти типичные грабли.
Что нужно: Ubuntu 22.04+ (или любой Linux с Docker), Docker и Docker Compose, доменное имя, направленное на IP сервера.
Без явно заданного N8N_WEBHOOK_URL n8n генерирует адреса вида http://localhost:5678/webhook/... — недоступные извне. Каждый внешний сервис, ожидающий callback, в итоге стучится в неверный адрес.
Один владелец агентства потерял 3 дня клиентских лидов, прежде чем обнаружил проблему — потому что со стороны n8n всё выглядело нормально.
Фикс:
N8N_WEBHOOK_URL=https://your-domain.comПропишите в .env или docker-compose.yml. Привяжите к публичному домену.
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.comCertbot автоматически модифицирует конфиг 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.
Эта проблема проявляется, когда вы начинаете интегрировать 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 базы данных.
KVM-изоляция, NVMe-хранилище, 40+ локаций. Разверните n8n с PostgreSQL, Redis и Nginx на одной машине.
Полная конфигурация self-hosted n8n включает как минимум четыре компонента:
Для 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 и поднять остальной стек.