n8n локально ставлю обычно в двух случаях: когда клиент уже упёрся в лимит бесплатного тарифа на Zapier или Make и переплачивать за облако не хочет, либо когда через сценарии идут данные, которые нельзя гонять через сторонний сервис - контакты клиентов, платежи, внутренняя CRM. Self-hosted вариант снимает лимиты на количество workflow и вызовов, но добавляет статью расходов, которой в облаке просто нет: сервер, который нужно обновлять, бэкапы, которые нужно проверять, и время на администрирование. Ниже разбираю, что нужно под самостоятельный запуск, как закрыть n8n от посторонних и во сколько это выходит против подписки на n8n Cloud.
Что нужно для n8n локально: требования к серверу
Под n8n не нужен мощный сервер. Для типичной нагрузки - десяток-два активных workflow, вебхуки от Telegram-бота, CRM и форм, пара сценариев по расписанию - хватает VPS с 2 ядрами и 2-4 ГБ оперативной памяти. Больше памяти закладываю, если в сценариях гоняются большие payload (выгрузки из 1С, обработка файлов, парсинг с Python-скриптами через ноду Execute Command) или крутится несколько тяжёлых workflow одновременно.
Диск считаю не только под саму систему и Docker-образы, но и под историю выполнений: n8n по умолчанию хранит логи каждого запуска сценария, и если workflow дёргается часто, база разрастается быстро. На практике настраиваю очистку старых executions через переменные окружения, иначе через пару месяцев база весит гигабайты, а бэкап занимает кратно дольше.
Из софта на сервере нужен только Docker - официальный образ n8nio/n8n тянет за собой Node.js и все зависимости внутри контейнера, отдельно их ставить не надо. Это тот случай, когда отдельный сервер оправдан: n8n - это среда выполнения сценариев с вебхуками, планировщиком и очередью задач, для такой нагрузки обычный shared-хостинг под сайты не подходит, и держать это нужно на VPS с постоянно работающим процессом.
Разворачиваю n8n локально через Docker
Поднимаю контейнер одной командой, без docker-compose, если сервис единственный на сервере:
docker run -d \
--name n8n \
--restart unless-stopped \
-p 127.0.0.1:5678:5678 \
-e N8N_HOST=n8n.example.ru \
-e N8N_PROTOCOL=https \
-e WEBHOOK_URL=https://n8n.example.ru/ \
-e GENERIC_TIMEZONE=Europe/Moscow \
-e N8N_ENCRYPTION_KEY=замените-на-случайную-строку \
-v n8n_data:/home/node/.n8n \
n8nio/n8nПорт 5678 сознательно биндю на 127.0.0.1, а не на все интерфейсы - снаружи к n8n будут ходить только через обратный прокси, об этом ниже. WEBHOOK_URL и N8N_HOST важны, если сервис стоит за прокси: без них n8n может генерировать ссылки на вебхуки с внутренним адресом контейнера вместо реального домена, и внешние сервисы вроде Telegram или CRM просто не достучатся до триггера.
N8N_ENCRYPTION_KEY - отдельный больной момент. Этим ключом n8n шифрует все credentials внутри workflow: токены CRM, пароли от почты, ключи API. Если ключ не задать явно, n8n сгенерирует его сам и сохранит в volume - при переносе на другой сервер без этого же ключа все сохранённые credentials станут нечитаемыми и их придётся вводить заново. Поэтому ключ задаю вручную и храню отдельно от бэкапа самого volume, не в одном месте.
Для небольших и средних инсталляций встроенной SQLite-базы внутри volume достаточно. Если workflow много и они интенсивно пишут в историю выполнений, переключаю n8n на внешний Postgres через переменную DB_TYPE=postgresdb - это уже отдельный сервис (контейнер с Postgres или managed-база), и его тоже придётся обслуживать и резервировать отдельно.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Закрываю доступ снаружи: сеть, прокси и авторизация
При первом запуске n8n просит создать учётную запись владельца - email и пароль, это встроенный механизм авторизации, отдельно ничего доустанавливать не нужно. Но полагаться только на форму входа не стоит: если порт 5678 торчит наружу напрямую, это готовая мишень для перебора паролей и сканеров.
Схема, которую использую на практике:
- n8n слушает только 127.0.0.1, наружу не публикуется вообще
- перед ним стоит Nginx или Caddy с HTTPS - сертификат беру бесплатный через Let’s Encrypt, он обновляется автоматически
- файрвол (ufw или аналог) пропускает снаружи только 80 и 443, порт 5678 закрыт для внешних адресов в принципе
- доступ к панели n8n дополнительно можно ограничить по IP на уровне прокси, если админят сценарии из одного-двух мест
Полностью спрятать n8n за VPN получается не всегда. Если в сценариях есть триггеры-вебхуки - форма с сайта, событие из CRM, сообщение боту в Telegram - сервису нужен публичный HTTPS-адрес, иначе внешний сервис до вебхука не достучится. В таком случае закрываю только панель администрирования, а сам эндпоинт вебхука остаётся доступным, но без интерфейса управления рядом.
Если внешних вебхуков в сценариях нет и всё общение с внешними сервисами n8n инициирует сам по расписанию или через polling, доступ проще всего закрыть полностью и заходить в панель только через VPN или WireGuard - тогда сервис вообще не виден из интернета.
Резервные копии сценариев n8n
Под угрозой три вещи: сами workflow, credentials (они зашифрованы N8N_ENCRYPTION_KEY) и история выполнений. Экспорт сценариев в JSON делаю штатной командой CLI прямо из контейнера:
docker exec n8n n8n export:workflow --all --output=/home/node/.n8n/backup/workflows.jsonЭта команда выгружает все сценарии в файл внутри volume, дальше его забираю на другой сервер обычным rsync или scp по расписанию через cron. Но экспорт workflow - это не полная копия: credentials в нём не хранятся в читаемом виде, а история выполнений вообще не попадает в файл. Поэтому вторым слоем бэкаплю весь volume целиком (или делаю pg_dump, если база вынесена в Postgres) - это единственный способ восстановить сервис один в один после падения сервера.
N8N_ENCRYPTION_KEY храню отдельно от бэкапа volume - если оба окажутся в одном архиве и архив утечёт, шифрование credentials теряет смысл. Если в сценариях гоняются контакты клиентов из CRM или интернет-магазина, бэкапы храню на серверах в РФ, а не в зарубежных облачных бакетах - того требует 152-ФЗ по локализации персональных данных, и для автоматизаций с CRM это правило соблюдаю так же строго, как для самих баз клиентов.
Считаю полную стоимость владения n8n локально
Основные статьи расходов при самостоятельном запуске:
| Статья расходов | Что входит |
|---|---|
| Сервер (VPS) | ежемесячная аренда, зависит от характеристик и хостера |
| Домен и SSL | домен по цене зоны, сертификат Let’s Encrypt бесплатный |
| Настройка и перенос сценариев | разовая работа: Docker, прокси, авторизация, бэкапы |
| Администрирование | обновления n8n и системы, мониторинг, разбор падений |
Точную цену VPS называть не буду - она зависит от хостера и меняется со временем, ориентируйтесь на тариф с 2 ядрами и от 2-4 ГБ памяти как на стартовую точку и уточняйте у конкретного провайдера. А вот свою часть работы оцениваю по прайсу: настройка и перенос сценариев на свой сервер, закрытие доступа и бэкапы как отдельная задача - автоматизация в n8n от 25 000 ₽, а если после запуска не хочется самому следить за обновлениями и падениями сервера, беру такие задачи на постоянную техподдержку от 15 000 ₽/мес.
Если сомневаетесь, какой вариант выгоднее в вашем конкретном случае - самостоятельный сервер или облачный тариф, беру такие вопросы на консультацию от 3 000 ₽, разбираем нагрузку и считаем вместе.
Главное, что часто не закладывают в расчёт: время на администрирование не разовое. Обновления n8n выходят регулярно, и откладывать их надолго рискованно - разрыв между версиями увеличивает шанс, что миграция базы или credentials пройдёт не гладко. Если готовности вникать в это на постоянной основе нет, самостоятельный запуск обходится дороже, чем кажется по одной только цене VPS.
n8n локально или облачный тариф: когда что выгоднее
Самостоятельный запуск оправдан, когда данные в сценариях чувствительные и держать их в стороннем сервисе не вариант, когда нужны кастомные npm-пакеты или ноды, которых нет в облачной версии, либо когда объём вызовов уже вырос настолько, что упирается в лимиты подписки. Тогда разовые расходы на сервер и настройку окупаются за счёт отсутствия постоянной платы за тариф.
Облачный n8n Cloud выигрывает, если своей команды под администрирование сервера нет, а сценариев немного и они не требуют доступа к внутренней инфраструктуре. Тарифы у n8n Cloud построены на количестве активных workflow и выполнений и со временем меняются, поэтому актуальные цифры смотрите прямо на сайте n8n перед тем, как считать окупаемость самостоятельного сервера - ориентироваться на старые цифры из статей смысла нет.
На практике для клиентов с одним-двумя интеграционными сценариями (форма на сайте в CRM, уведомления в Telegram) обычно советую остаться в облаке - разница в деньгах против аренды сервера и моего времени на настройку не отбивается. Самостоятельный сервер начинает иметь смысл, когда сценариев становится много и они завязаны друг на друга, либо когда через n8n идут вебхуки от эквайринга или платёжной системы и хочется контролировать инфраструктуру целиком.
n8n регулярно обновляется, поэтому перед внедрением я сверяюсь с актуальной документацией.
Частые вопросы
Хватит ли самого дешёвого VPS для n8n?
Для одного-двух простых сценариев с редкими вебхуками хватит и минимального тарифа с 1 ГБ памяти, но с запасом в 2-4 ГБ работать спокойнее: n8n держит в памяти данные текущего выполнения, и на тяжёлых payload-ах (файлы, большие JSON-ответы от API) слабый сервер начинает подтормаживать или падать по памяти.
Что будет, если сервер упадёт вместе с базой n8n?
Без бэкапа volume или дампа Postgres сценарии, credentials и история выполнений теряются полностью - n8n не хранит их нигде, кроме сервера. Поэтому бэкап volume целиком, а не только экспорт workflow в JSON, обязателен, если сервис используется не для тестов.
Можно ли перенести сценарии с n8n Cloud на свой сервер?
Да, workflow экспортируются в JSON и импортируются на самостоятельном сервере штатной командой CLI. А вот credentials перенести один в один не получится - их придётся ввести заново на новом экземпляре, потому что они привязаны к encryption key конкретной установки n8n.
Нужен ли Postgres или хватит встроенной SQLite?
Для небольшого и среднего числа сценариев встроенной SQLite достаточно, она входит в docker-образ из коробки и не требует отдельного сервиса. На Postgres переключаюсь, когда workflow много, они интенсивно пишут историю выполнений и нужна более надёжная работа с базой под нагрузкой - но это уже отдельный сервис, который тоже надо обслуживать и резервировать.