N8n system requirements

Системные требования для развертывания и эксплуатации n8n

n8n — это мощный инструмент автоматизации рабочих процессов с открытым исходным кодом, который может быть развернут в различных средах: от локальной машины разработчика до масштабируемого облачного кластера. Точные системные требования сильно зависят от планируемой нагрузки, сложности workflows (воркфлов) и выбранного режима развертывания. Данная статья детально рассматривает все аспекты, необходимые для успешной установки и поддержания производительной работы n8n.

1. Режимы развертывания и их влияние на требования

Перед оценкой железа и программного обеспечения необходимо определиться со стратегией развертывания. Основных вариантов три:

• n8n Desktop App (Для ознакомления и личного использования): Автономное приложение для Windows, macOS, Linux. Все компоненты (веб-сервер, внутренняя БД, планировщик) работают как единый процесс на вашем компьютере. Не предназначено для производственной среды.
• Самостоятельный хостинг с внутренней базой данных (SQLite): Стандартный режим для быстрого старта. n8n и встроенная БД SQLite работают в одном процессе. Подходит для небольших персональных или тестовых развертываний с низкой нагрузкой. Не поддерживает горизонтальное масштабирование.
• Самостоятельный хостинг с внешней базой данных (PostgreSQL, MySQL): Обязательное требование для производственного использования. Позволяет разделить сервисы, обеспечивает надежность, производительность и возможность масштабирования (например, запуск нескольких экземпляров n8n).
• Развертывание в Docker-контейнерах: Рекомендуемый способ для production. Обеспечивает изоляцию, упрощает обновления и развертывание, особенно в оркестраторах типа Kubernetes.

2. Аппаратные требования (CPU, RAM, Диск)

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

2.1. Базовые требования для начала работы и тестирования

• Центральный процессор (CPU): 1-2 ядра современного процессора. Этого достаточно для запуска нескольких простых воркфлов.
• Оперативная память (RAM): Минимум 2 ГБ. Для комфортной работы с несколькими активными воркфлами и веб-интерфейсом рекомендуется 4 ГБ.
• Дисковое пространство: 2-4 ГБ для установки n8n, его зависимостей и временных файлов. Скорость диска влияет на производительность, особенно при использовании SQLite.

2.2. Рекомендации для производственного окружения (Production)

• Центральный процессор (CPU): 4+ ядер. Сложные воркфлы с множеством операций (парсинг JSON, преобразования данных, циклы) потребляют значительные вычислительные ресурсы. Чем больше параллельных выполнений, тем больше требуется ядер.
• Оперативная память (RAM): 8 ГБ — абсолютный минимум. 16 ГБ и более — рекомендуется. Память используется для:
  • Хранения данных активных воркфлов.
  • Кэширования.
  • Работы самого Node.js процесса.
  • Каждый экземпляр n8n (worker) может потреблять от 500 МБ до нескольких гигабайт в зависимости от нагрузки.
• Дисковое пространство и тип:
  • Объем: Зависит от объема хранимых данных о выполнении воркфлов (execution history). Рекомендуется мониторить рост и устанавливать политики очистки. Начать можно с 50-100 ГБ.
  • Тип: SSD накопители обязательны для production. Они критически важны для скорости отклика базы данных и файловой системы, особенно при высокой частоте запуска воркфлов.

3. Программные требования и зависимости

3.1. Операционные системы

n8n кроссплатформенный. Официально поддерживается и тестируется на:

• Linux (Ubuntu 20.04/22.04 LTS, Debian, CentOS/RHEL — наиболее популярные для серверов)
• Windows 10/11 (для Desktop App или Docker)
• macOS (для Desktop App или Docker)

3.2. Среда выполнения Node.js

При самостоятельной установке (не через Docker) требуется Node.js. Требуемая версия всегда указана в официальной документации. По состоянию на актуальную версию n8n:

• Node.js 18.x или 20.x. Версия 16.x и ниже не поддерживаются.
• Рекомендуется использовать LTS (Long Term Support) версии.
• Также потребуется менеджер пакетов npm (обычно поставляется с Node.js).

3.3. Базы данных

Выбор базы данных — ключевое решение для production-развертывания.

База данных	Назначение	Минимальная версия	Рекомендации и примечания
SQLite	Встроенная, для тестирования и малых нагрузок	3.25.0+	Не подходит для production. Не поддерживает параллельные запись/чтение из нескольких экземпляров n8n. Нет масштабируемости.
PostgreSQL	Основная, рекомендованная для production	12.x	Настоятельно рекомендуется. Лучшая производительность и совместимость. Требует отдельного сервера или контейнера. Поддерживает все функции n8n, включая планировщик и несколько «воркеров».
MySQL / MariaDB	Альтернатива для production	8.0 / 10.6+	Полная поддержка. Некоторые пользователи отмечают чуть меньшую производительность по сравнению с PostgreSQL на идентичных нагрузках. Требуется кодировка utf8mb4.

3.4. Дополнительные программные компоненты

• Docker / Docker Compose: Для контейнеризованного развертывания. Рекомендуется последняя стабильная версия.
• Reverse Proxy (Обратный прокси): Nginx или Apache. Обязателен для production для обработки SSL/TLS (HTTPS), балансировки нагрузки (если несколько экземпляров n8n), кэширования и безопасности.
• Process Manager (Менеджер процессов): Для standalone-установок на Linux рекомендуется использовать pm2 или systemd для автоматического перезапуска n8n в случае сбоев.

4. Требования к сети и внешний доступ

• Исходящий интернет-доступ: n8n должен иметь доступ к тем внешним API и сервисам, которые используются в ваших воркфлах (Google, Slack, Telegram, HTTP-запросы и т.д.).
• Входящие подключения (порты):
  • По умолчанию веб-интерфейс и API n8n слушают порт 5678.
  • В production этот порт должен быть закрыт от прямого доступа из интернета. Доступ должен осуществляться только через обратный прокси (Nginx/Apache) на стандартных портах 443 (HTTPS) и/или 80 (HTTP).
• Доступ к SMTP-серверу: Для отправки уведомлений по электронной почте (например, при сбоях воркфлов) необходимо настроить доступ к SMTP-серверу.

5. Рекомендации по масштабированию

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

5.1. Архитектура с основным процессом и воркерами

• Main Process (Web-Process): Отвечает за обслуживание веб-интерфейса и REST API. Запускается один экземпляр.
• Worker Process(es): Отвечают исключительно за выполнение воркфлов. Можно запустить множество таких процессов на одном или разных серверах.
• Все процессы подключаются к одной внешней базе данных (PostgreSQL/MySQL) и единой очереди сообщений (например, Redis) для координации.

5.2. Очередь сообщений (Message Queue)

Для координации между Main Process и Worker Processes в масштабируемой установке требуется очередь. Рекомендуемый и наиболее интегрированный вариант — Redis. Он используется для управления очередями заданий и событий.

5.3. Пример конфигурации для высоких нагрузок

Компонент	Сервер 1	Сервер 2	Сервер 3	Примечания
База данных PostgreSQL	✓ (Primary)	✓ (Replica)		Режим репликации для отказоустойчивости и чтения.
Redis	✓ (Sentinel)	✓ (Sentinel)	✓ (Sentinel)	Кластер Redis Sentinel для высокой доступности очереди.
n8n Main Process	✓			За балансировщиком нагрузки (Load Balancer).
n8n Worker Processes	✓ (4 workers)	✓ (4 workers)	✓ (4 workers)	Итого 12 воркеров, обрабатывающих воркфлы.
Reverse Proxy / Load Balancer	✓ (Nginx)			Распределяет запросы к Main Process и отдает статику.

6. Рекомендуемые конфигурации для различных сценариев

Сценарий использования	Пользователи	Воркфлов в день	Рекомендуемая конфигурация	Ориентировочные ресурсы (CPU/RAM/Диск)
Персональное использование / Оценка	1	До 100	Desktop App или Docker с SQLite	2 ядра, 4 ГБ ОЗУ, 10 ГБ SSD
Небольшая команда / Стартап	5-15	100-5000	Docker Compose (n8n + PostgreSQL) на одном VPS	4 ядра, 8-16 ГБ ОЗУ, 50-100 ГБ SSD
Производство, средняя нагрузка	15-50	5 000 — 50 000	Отдельные сервисы: n8n (Main + 2-4 Workers), PostgreSQL, Redis на выделенных инстансах/контейнерах	n8n: 4-8 ядер, 16-32 ГБ ОЗУ. БД: 4+ ядра, 16+ ГБ ОЗУ, 200+ ГБ SSD
Крупное предприятие / Высокая нагрузка	50+	50 000+	Горизонтально масштабируемый кластер: Load Balancer, несколько Main/Worker процессов, кластер PostgreSQL, кластер Redis, оркестратор (K8s).	Масштабируется по мере необходимости. Каждый worker-сервис: 4+ ядер, 8+ ГБ ОЗУ. Высокопроизводительные БД.

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

Можно ли запустить n8n на Raspberry Pi?

Да, это возможно, особенно на моделях 4 и 5. Однако это подходит только для личного использования, тестирования или очень легких рабочих нагрузок из-за ограничений ARM-архитектуры, CPU и оперативной памяти. Необходимо использовать Docker-образ для ARM или устанавливать через Node.js. Производительность будет низкой при сложных воркфлах.

Почему для production обязательно нужна внешняя БД, а не SQLite?

SQLite не поддерживает конкурентный доступ на запись из нескольких процессов. Это означает, что вы не сможете запустить несколько экземпляров n8n для масштабирования, а также возможны блокировки и потери данных при высокой нагрузке. Внешние БД (PostgreSQL/MySQL) созданы для обработки множества одновременных соединений, обеспечивают целостность данных и отказоустойчивость.

Какой объем оперативной памяти требуется на 1000 воркфлов в день?

Сложно дать точную оценку без данных о сложности воркфлов. Для 1000 простых воркфлов (например, HTTP-запрос + запись в Google Sheets) может хватить 4-8 ГБ ОЗУ. Если воркфлы сложные, с большими массивами данных, парсингом и множеством узлов, потребление памяти может быть значительно выше. Необходимо проводить нагрузочное тестирование в своей среде.

Нужен ли отдельный Redis для production?

Да, для любого production-развертывания, где планируется запускать более одного экземпляра n8n (например, Main + Worker), Redis является обязательным. Он выступает в качестве брокера сообщений для координации выполнения воркфлов между процессами. Без Redis несколько экземпляров не смогут корректно работать вместе.

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

Рекомендуется использовать:

• Встроенные метрики Prometheus (эндпоинт /metrics).
• Мониторинг логов (stdout/stderr).
• Системные инструменты: мониторинг загрузки CPU и RAM (например, через node_exporter для Prometheus).
• Мониторинг производительности базы данных (PostgreSQL pg_stat_statements).
• Ведение истории выполнения воркфлов в самом n8n для анализа долгих операций.

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

• EXECUTIONS_DATA_PRUNE: Включение автоматической очистки старых данных выполнений для предотвращения разрастания БД.
• GENERIC_TIMEZONE и EXECUTIONS_TIMEOUT: Корректные таймауты для предотвращения зависаний.
• Конфигурация пула соединений с БД: Правильные настройки DB_POSTGRESDB_POOL_SIZE для оптимального количества одновременных подключений.
• Режим ведения журнала (logging level): В production установите уровень info или warn, чтобы избежать записи огромного количества отладочных сообщений.