N8n требования

N8n: подробные технические и системные требования для развертывания и эксплуатации

N8n — это мощный инструмент автоматизации рабочих процессов с открытым исходным кодом, работающий по принципу low-code. Его архитектура, основанная на Node.js, определяет конкретный набор требований к аппаратному и программному обеспечению, а также к среде развертывания. Понимание этих требований критически важно для стабильной, безопасной и масштабируемой работы платформы. Данная статья детально рассматривает все аспекты, необходимые для планирования, установки и поддержки N8n в производственной среде.

1. Требования к программному обеспечению и среде выполнения

Базовым фундаментом для работы N8n является среда выполнения Node.js и система управления базами данных. Эти компоненты не являются опциональными для самостоятельного хостинга.

1.1. Node.js

N8n написан на TypeScript и требует наличия Node.js. Необходимо строго соблюдать совместимость версий.

• Рекомендуемая версия: Node.js 18.x или 20.x (LTS — долгосрочная поддержка). Использование LTS-версий гарантирует получение исправлений безопасности и стабильность.
• Минимальная версия: Требования могут меняться с обновлениями N8n. Актуальную информацию всегда следует проверять в официальной документации. Для N8n версии 1.x+ минимальной является Node.js 18.
• Важно: Избегайте использования не-LTS версий (например, 19.x, 21.x) в production, так как они не получают долгосрочных обновлений. Менеджер пакетов npm обычно поставляется вместе с Node.js.

1.2. Система управления базами данных

По умолчанию N8n использует SQLite для хранения рабочих процессов, учетных данных и данных выполнения. Однако для производственного развертывания это неприемлемо из-за проблем с производительностью, параллелизмом и надежностью. Обязательным требованием для production-среды является использование внешней СУБД.

СУБД	Поддерживаемая версия	Тип драйвера	Рекомендации по использованию
PostgreSQL	12.x и выше (рекомендуется 13+)	Нативный	Наиболее рекомендуемый вариант. Лучшая производительность, полная поддержка всех функций N8n, включая планирование и журналирование выполнения.
MySQL	8.0 и выше	Нативный	Полноценная поддержка. Требует настройки кодировки базы данных на utf8mb4.
MariaDB	10.8 и выше	Нативный	Альтернатива MySQL с аналогичными требованиями.
SQLite	3.x	Встроенный	Только для тестирования, разработки или персонального использования. Не подходит для многопользовательской или высоконагруженной среды.

2. Аппаратные требования (ресурсы сервера)

Аппаратные требования сильно варьируются в зависимости от количества и сложности рабочих процессов, частоты их выполнения, объема обрабатываемых данных и числа пользователей.

Сценарий использования	CPU (ядра)	Оперативная память (RAM)	Дисковое пространство	Пояснения
Персональное использование / Оценка	1-2 ядра	2-4 ГБ	10-20 ГБ (SSD)	Достаточно для нескольких простых рабочих процессов. Можно использовать на виртуальной машине или дешевом VPS.
Рабочая группа / Небольшая компания	4 ядра	8-16 ГБ	50-100 ГБ (SSD)	Для десятков рабочих процессов с умеренной нагрузкой. Требуется запас для пиковых нагрузок.
Производство, масштабирование	8+ ядер	16-32+ ГБ	100+ ГБ (быстрый SSD/NVMe)	Для сотен сложных workflows, обработки больших данных, высокой частоты триггеров. Требуется мониторинг и вертикальное/горизонтальное масштабирование.

Примечания по аппаратным ресурсам:

• CPU: Интенсивные операции (парсинг JSON, преобразования данных, выполнение пользовательского кода) потребляют процессорное время.
• Оперативная память: Критически важный ресурс. Каждый экземпляр N8n и каждый выполняемый workflow потребляют память. Недостаток памяти приводит к падению производительности и аварийным остановкам.
• Диск: Требуется для хранения логов, временных файлов и резервных копий workflows. SSD обязателен для production-среды из-за высокого количества операций ввода-вывода. Объем зависит от политики хранения логов.
• Сеть: Стабильное и широкополосное интернет-соединение необходимо для интеграций с внешними API и сервисами.

3. Требования к операционной системе и среде развертывания

N8n является кроссплатформенным и может быть запущен в различных средах.

• Поддерживаемые ОС: Linux (Ubuntu 20.04/22.04, Debian, CentOS/RHEL — рекомендуются), macOS (для разработки), Windows (для разработки, но не рекомендуется для production).
• Среды развертывания:
  • Docker (рекомендуется): Официальный образ `n8nio/n8n` является стандартным и предпочтительным методом развертывания. Он инкапсулирует все зависимости и упрощает обновление.
  • Самостоятельная установка (npm): Установка глобально через `npm install -g n8n`. Требует ручного управления зависимостями и сервисами. Подходит для продвинутых пользователей.
  • Облачные платформы: N8n можно развернуть на любом облачном провайдере (AWS, Google Cloud, Azure, DigitalOcean) с использованием Docker или виртуальных машин. Существуют также готовые образы на рынках облачных провайдеров.
  • Kubernetes: N8n может быть развернут в Kubernetes с использованием Helm-чартов для обеспечения высокой доступности и масштабирования.

4. Требования к безопасности

При самостоятельном хостинге ответственность за безопасность лежит на администраторе.

• Шифрование (HTTPS): Обязательно использование обратного прокси (например, nginx, Traefik, Caddy) с SSL-сертификатами (от Let’s Encrypt или внутреннего ЦС) для шифрования трафика.
• Аутентификация: Необходимо настроить один из методов аутентификации для доступа к веб-интерфейсу:
  • Встроенная аутентификация (базовый пользователь/пароль).
  • OAuth 2.0 / OpenID Connect (через Keycloak, Auth0, Google и др.).
  • Внешняя аутентификация через обратный прокси (например, с помощью заголовков).
• Защита учетных данных: N8n хранит учетные данные для подключения к сервисам в зашифрованном виде в базе данных с использованием секретного ключа (`N8N_ENCRYPTION_KEY`), который должен быть установлен в переменных окружения и надежно защищен.
• Сетевая изоляция: Рекомендуется развертывание N8n в изолированной сети (DMZ) с контролем исходящего и входящего трафика (брандмауэр). Доступ к порту веб-интерфейса (по умолчанию 5678) должен быть строго ограничен.
• Регулярные обновления: Обязательная политика регулярного обновления N8n, Node.js, СУБД и базовой ОС для устранения уязвимостей.

5. Требования к конфигурации и переменным окружения

Конфигурация N8n осуществляется почти исключительно через переменные окружения. Ключевые из них:

• N8N_PROTOCOL, N8N_HOST, N8N_PORT: Базовые настройки веб-интерфейса.
• N8N_DATABASE_TYPE: Тип СУБД (postgresdb, mysqldb, sqlite).
• DB_POSTGRESDB_HOST, DB_POSTGRESDB_DATABASE, DB_POSTGRESDB_USER, DB_POSTGRESDB_PASSWORD: Параметры подключения к PostgreSQL.
• N8N_ENCRYPTION_KEY: Обязательный ключ для шифрования данных (мин. 16 символов).
• N8N_SECURITY_*: Настройки безопасности (отключение встроенной аутентификации, настройка CORS и др.).
• EXECUTIONS_DATA_PRUNE, EXECUTIONS_DATA_MAX_AGE: Настройки политики очистки старых данных выполненных workflows для экономии места в БД.
• GENERIC_TIMEZONE: Установка часового пояса по умолчанию для планировщика.
• WEBHOOK_URL: Критически важная переменная для корректной работы вебхуков, должна указывать на публичный адрес вашего инстанса N8n.

6. Требования для масштабирования и высокой доступности

Для обеспечения отказоустойчивости и обработки больших нагрузок требуется архитектура с несколькими экземплярами.

• Множество экземпляров (горизонтальное масштабирование): Запуск нескольких контейнеров или процессов N8n за балансировщиком нагрузки (например, nginx).
• Общая база данных: Все экземпляры должны использовать одну и ту же внешнюю СУБД (PostgreSQL/MySQL).
• Общее хранилище файлов: Если workflows используют загрузку/выгрузку файлов, необходимо общее сетевое хранилище (например, S3-совместимое объектное хранилище, NFS), доступное всем экземплярам.
• Координация планировщика: При использовании встроенного планировщика (триггер «Расписание») в режиме высокой доступности требуется настройка переменной `N8N_LEADER_SELECTION` и использование Redis для координации, чтобы задача выполнялась только одним экземпляром.
• Очередь сообщений (опционально): Для обработки большого количества фоновых задач можно настроить внешнюю очередь (Redis) через переменные `QUEUE_BULL_REDIS_HOST` и другие.

7. Требования к мониторингу и обслуживанию

• Мониторинг: Необходимо отслеживать:
  • Потребление CPU, RAM, диска на сервере.
  • Количество и статус выполняющихся workflows (успешные/неудачные).
  • Загрузку и производительность базы данных.
  • Доступность веб-интерфейса и конечных точек API.

  Можно использовать Prometheus с экспортером метрик N8n, а также встроенный журнал выполнения.

• Резервное копирование: Обязательно регулярное резервное копирование:
  • Базы данных PostgreSQL/MySQL (дампи).
  • Файловых ресурсов (если используются).
  • Экспортированных workflows (через UI или API) как дополнительная мера.
• Обновление: Процедура обновления должна быть оттестирована на staging-среде. При использовании Docker она сводится к обновлению образа и перезапуску контейнера с учетом возможных миграций схемы базы данных.

Ответы на часто задаваемые вопросы (FAQ)

Можно ли запустить N8n на Windows для production?

Технически возможно, но категорически не рекомендуется. Производительность, стабильность и простота обслуживания на Linux-системах или в Docker несопоставимо выше. Windows следует рассматривать только как среду для локальной разработки и тестирования.

Почему SQLite нельзя использовать в production?

SQLite — это встраиваемая база данных, не поддерживающая эффективную параллельную запись с нескольких процессов или экземпляров. В production это приведет к конфликтам блокировок, частым ошибкам «database is locked», потере данных и крайне низкой производительности при нескольких одновременных выполнениях workflows.

Каков минимальный реалистичный сервер для небольшой команды?

VPS или облачная виртуальная машина с 2-4 ядрами CPU, 8 ГБ оперативной памяти, 50 ГБ SSD-диском, операционной системой Ubuntu 22.04 LTS. N8n должен быть развернут в Docker, с внешней PostgreSQL на том же или отдельном сервере.

Как правильно настроить вебхуки для работы за обратным прокси?

Критически важно установить переменную окружения `WEBHOOK_URL` на публичный адрес вашего инстанса (например, `https://n8n.mydomain.com`). В конфигурации обратного прокси (nginx) необходимо корректно передавать заголовки, особенно `X-Forwarded-Proto`, `X-Forwarded-Host`, `X-Forwarded-For`.

Нужен ли отдельный сервер для базы данных?

Для начального этапа и небольших нагрузок допустимо размещение PostgreSQL на том же сервере, что и N8n. При росте нагрузки (более 50-100 активно выполняющихся workflows, большое количество данных) базу данных обязательно нужно выносить на отдельный сервер или управляемый облачный сервис (например, AWS RDS, Google Cloud SQL).

Как организовать высокую доступность (High Availability) для N8n?

Требуется: 1) Два или более экземпляра N8n в Docker или Kubernetes. 2) Общая производственная СУБД (PostgreSQL) вне этих экземпляров. 3) Общее файловое хранилище (например, Amazon S3). 4) Балансировщик нагрузки (например, AWS ALB, nginx) для распределения запросов. 5) Настройка координации планировщика через Redis (опционально, но рекомендуется).

Какие порты нужно открыть на фаерволе?

Для самого сервера с N8n: исходящий доступ к интернету (для API-интеграций) и к порту СУБД (если она вынесена). Входящий доступ должен быть ограничен: открыт только порт для веб-сервера/обратного прокси (например, 443 для HTTPS). Порт по умолчанию для самого N8n (5678) должен быть закрыт на внешнем интерфейсе и доступен только локально или для прокси.

Как обновлять N8n при развертывании через Docker?

1. Остановить текущий контейнер. 2. Получить новую версию образа: `docker pull n8nio/n8n:latest` (или конкретной версии). 3. Запустить новый контейнер с теми же параметрами и томами данных. N8n автоматически выполнит миграции схемы базы данных при запуске. Настоятельно рекомендуется предварительно создать полную резервную копию базы данных.