В России n8n почти всегда ставят на свой сервер, и дешевизна тут ни при чём. Причин две. Первая: оплата облачной подписки из России по состоянию на сентябрь 2026 года проходит только через посредников, а значит, у компании нет ни договора с российским юрлицом, ни закрывающих документов на расход. Вторая, и главная: часть 5 статьи 18 152-ФЗ требует, чтобы базы данных с персональными данными граждан России находились на территории России, а через сценарии автоматизации почти всегда ходят имена, телефоны и адреса.
Дальше начинается подмена, из-за которой мы и написали эту статью. Фраза «мы поставили n8n на свой сервер в России, значит, у нас всё по 152-ФЗ» неверна. Своя установка закрывает ровно одно требование закона — локализацию. Уведомление в Роскомнадзор, правовое основание обработки, поручение обработки подрядчику, который администрирует этот сервер, организационные меры по статье 19 и реагирование на утечку — всё это остаётся на компании и от места сервера не зависит.
Ниже — конфигурация контура под 30–50 сценариев, годовая смета на 339 200 ₽ с разбором каждой строки, порядок обновления боевого контура и расчёт точки, после которой российская облачная платформа снова дешевле. Пошаговая установка с первым сценарием у нас разобрана отдельно — здесь мы не повторяем команды, а считаем деньги и разбираем правовой слой.
Почему в России прижился self-hosted
Облачный тариф неудобен не только оплатой. Оплата через посредника — это расход без счёта и акта, который бухгалтерия проводит как что угодно, кроме подписки на ПО. Но неудобство оплаты можно пережить; непереживаемо другое — данные. Как только в сценарии появляется поле «телефон клиента», сценарий начинает обрабатывать персональные данные, и вопрос «где физически лежит база, в которой это поле сохранилось» становится вопросом к вам, а не к платформе.
На архитектуру это влияет сильнее, чем кажется. Облако — это чужая зона ответственности: доступность, обновления, резервные копии и восстановление после сбоя делает провайдер, а вы платите за операции. Свой сервер переносит всё это внутрь: появляется дежурный, окно обновлений, регламент копий и учение по восстановлению. Технически контур становится проще в контроле и сложнее в эксплуатации. Именно поэтому 64 % годовой сметы, которую мы посчитаем ниже, приходится не на железо, а на человека.
n8n распространяется не по классической открытой лицензии, а по Sustainable Use License. Использовать продукт для внутренних задач своей компании она разрешает; перепродавать его как сервис третьим лицам — нет. Если вы планируете собирать сценарии клиентам и брать за это абонентскую плату на своей установке, условия лицензии нужно прочитать до старта, а не после первого договора.
Что self-hosted закрывает по 152-ФЗ, а что нет
Разберём построчно. В левой колонке — обязанность оператора персональных данных, в правой — что вам всё равно придётся сделать руками, независимо от того, где стоит сервер.
| Требование | Закрывает ли своя установка | Что делать всё равно |
|---|---|---|
| Локализация баз ПД в России, ч. 5 ст. 18 152-ФЗ | Да, если сервер физически в РФ | Зафиксировать в документах, в какой именно базе и на какой площадке лежат данные |
| Отсутствие трансграничной передачи | Да, но только пока ни один узел не ходит наружу | Проверить узлы: обращение к зарубежной языковой модели, геокодеру или сервису проверки адреса — это уже передача |
| Уведомление в Роскомнадзор об обработке ПД | Нет | Подать уведомление: оператором остаётесь вы, а не платформа |
| Правовое основание и согласия субъектов | Нет | Цели, объём и сроки обработки от места сервера не зависят |
| Поручение обработки, ч. 3 ст. 6 | Нет | Если сервер администрирует подрядчик — договор поручения с перечнем разрешённых действий |
| Меры защиты, ст. 19 | Нет | Разграничение доступа, журналирование, парольная политика, приказ об ответственном за обработку |
| Реагирование на инцидент, ч. 3.1 ст. 21 | Нет | Уведомление регулятора в течение 24 часов и повторное — в течение 72 часов |
| Требование к отечественному ПО | Нет | n8n — зарубежный продукт, своя установка его отечественным не делает |
| Размещение у провайдера хостинга из реестра | Частично | Проверить, что выбранная площадка есть в реестре, который Роскомнадзор ведёт с 1 февраля 2024 года |
Сравнение в две колонки. Левая, узкая, подписана «Закрывает своя установка» и содержит один блок: «Локализация баз ПД в РФ, ч. 5 ст. 18». Правая, широкая, подписана «Остаётся на компании» и содержит восемь блоков: уведомление в Роскомнадзор, согласия и правовое основание, поручение обработки по ч. 3 ст. 6, меры защиты по ст. 19, реагирование на инцидент за 24 и 72 часа, требование к отечественному ПО, глубина хранения журналов прогонов, проверка провайдера по реестру. Внизу подпись: «Сервер в России — это один пункт из девяти». Чертёжный стиль, подписи по-русски.
n8n по умолчанию сохраняет содержимое каждого прогона целиком: тело входящего запроса, ответы систем, все поля. Через полгода работы парка из 30 сценариев в базе лежит теневая копия клиентской базы, которую никто не заводил, не описывал в уведомлении и не включал в модель угроз. Практическое правило: глубина хранения удачных прогонов — 14 дней, неудачных — 30, дальше автоматическая чистка. Всё, что нужно для разбора инцидентов, за этот срок успевают разобрать.
Отдельно про подрядчика. Если сервер поднимал и обслуживает не ваш сотрудник, он получает доступ к базе, где лежат персональные данные ваших клиентов, — а значит, отношения оформляются договором поручения обработки, а не просто договором на услуги. Что в нём должно быть перечислено, мы разбирали в материале про поручение обработки данных подрядчику; как устроен наш собственный периметр и какие меры мы применяем на проектах — на странице про безопасность.
Конфигурация под 30–50 сценариев
Типичная ошибка — поставить всё на один недорогой сервер на 2 ядра и 4 ГБ памяти, потому что «в инструкции так». Такая установка честно работает до 10–15 сценариев. Порог, на котором однопроцессный режим перестаёт держать нагрузку, — примерно 30 активных сценариев или 5 000 прогонов в сутки: долгий прогон с выгрузкой в 3 000 строк блокирует очередь, и всё остальное встаёт вместе с ним.
Рабочая конфигурация разносит четыре вещи, которые в стартовой установке живут вместе: приложение, базу, очередь и резервные копии. Плюс отдельный тестовый контур, который включается только на время обновлений и правок.
| Узел | Конфигурация | Почему именно так |
|---|---|---|
| Приложение: главный процесс и 2 воркера | 4 vCPU, 8 ГБ RAM, 100 ГБ NVMe | Воркеры уносят долгие прогоны из основной очереди — один тяжёлый сценарий больше не блокирует остальные 29 |
| База PostgreSQL | 2 vCPU, 4 ГБ RAM, 100 ГБ | SQLite не держит параллельную запись от нескольких воркеров: журналы прогонов начинают теряться |
| Redis для очереди | На сервере приложения, 1 ГБ | Режим очереди — обязательное условие работы воркеров, отдельная машина под него на этом масштабе не нужна |
| Хранилище резервных копий | 200 ГБ, отдельная площадка | Копия на том же сервере не является копией: она умрёт вместе с ним |
| Тестовый контур | 2 vCPU, 4 ГБ RAM | Место, где обновление и правка проверяются до боевого контура. Включается на 2–3 дня в квартал |
Карта связей из пяти узлов внутри рамки «периметр компании, РФ». В центре блок «Приложение n8n: главный процесс + 2 воркера, 4 vCPU / 8 ГБ / 100 ГБ». Слева блок «Redis, очередь, 1 ГБ» со стрелкой «задания». Справа блок «PostgreSQL, 2 vCPU / 4 ГБ / 100 ГБ» со стрелкой «сценарии, учётные данные, журналы прогонов». Снизу блок «Хранилище копий, 200 ГБ, отдельная площадка» со стрелкой «суточная копия». Сверху отдельно стоящий блок «Тестовый контур, 2 vCPU / 4 ГБ» с пунктирной стрелкой «обновление проверяется здесь». Все подписи по-русски, чертёжный стиль.
Ещё одна вещь, которую забывают заложить, — диск. Журналы прогонов растут быстрее всего остального: парк из 30 сценариев при 150 000 операций в месяц набирает десятки гигабайт за квартал, если не включена автоматическая чистка. Стоят эти гигабайты копейки, но кончившееся место останавливает весь контур целиком и обычно ночью.
Годовая смета контура
Считаем модельную компанию: парк из 30–50 сценариев, около 150 000 операций в месяц, свой инженер или подрядчик на почасовой оплате по 3 000 ₽/час. Цены на инфраструктуру — по российским площадкам, вилка по рынку ±30 %.
Шесть часов администрирования в месяц — не догадка, а сумма конкретных работ: разбор алертов и повторные запуски — 2 часа, обновления и прогон на тестовом контуре — 2 часа в среднем по году, резервные копии и учение по восстановлению — 1 час, чистка журналов и диска, мелкие правки конфигурации — 1 час. Это инфраструктурные часы. Работа над самими сценариями — новые ветки, правки под изменившийся прайс, разбор «почему не пришло» — сюда не входит и считается отдельно: полный разбор годовой сметы владения парком есть в материале сколько стоит low-code за год.
Что двигает смету вверх. Требование к доступности: если контур должен работать круглосуточно, а не в рабочее время, добавляется резервный сервер и дежурство — это ещё 150 000–250 000 ₽ в год. Требование аттестации по конкретному классу защищённости — отдельный проект. Что двигает вниз: отказ от тестового контура (экономия 14 400 ₽ и рост риска, обмен неравноценный) и снижение числа инфраструктурных часов до 3–4 в месяц, если сценарии стабильны и парк не растёт.
Чего в смете нет и что часто забывают заложить отдельно. Первое — разовая сборка контура: развернуть узлы, настроить очередь, копии и мониторинг, перенести существующие сценарии — это 24–40 часов инженера, 72 000–120 000 ₽, и платится один раз. Второе — перенос сценариев из облачной платформы: они выгружаются, но узлы соседних систем в разных платформах устроены по-разному, и часть связок собирается заново. Считайте по 1–2 часа на сценарий и проверяйте каждый на тестовых данных, а не на боевых.
Обновления: почему автообновление на боевом контуре выключают
Самая дорогая строчка в конфигурации самой установки — тег версии. Если вместо конкретной версии указан «latest», установка подтягивает свежий образ при любом перезапуске: после планового ребута площадки, после сбоя питания, после чистки диска. Версия меняется в момент, который вы не выбирали, и ломается тот сценарий, который в этот момент кому-то нужен. Правило простое: в боевом контуре стоит конкретная версия, и меняется она только вручную, в окно.
Не обновляться тоже нельзя: релизы выходят часто, среди них есть закрытия уязвимостей, а разрыв в год-полтора делает обновление уже не обновлением, а миграцией. Рабочий ритм — плановое окно раз в квартал плюс внеплановые обновления безопасности по мере появления.
- 1Шаг 1. Снять полную копию и проверить, что она читается
База со сценариями и журналами, файлы конфигурации и — обязательно — ключ шифрования учётных данных. Без ключа восстановленная база бесполезна: все пароли и токены в ней зашифрованы. Копия, которую ни разу не разворачивали, копией не считается.
- 2Шаг 2. Поднять новую версию на тестовом контуре
На копии боевой базы, а не на пустой. Именно на реальных сценариях вылезают изменившиеся форматы данных в узлах и переименованные параметры.
- 3Шаг 3. Прогнать контрольный набор
10–15 сценариев, покрывающих все типы узлов парка, на заранее подготовленных тестовых данных. Что такое регрессионный набор и как его собрать один раз, чтобы пользоваться годами, мы разбирали в материале про проверку после обновлений.
- 4Шаг 4. Обновить боевой контур в окно
Окно — время, когда сценарии либо не работают, либо их простой безболезнен: обычно раннее утро выходного. Приём заявок с сайта на это время переводится на резервный путь — хотя бы на письмо ответственному.
- 5Шаг 5. Наблюдать 48 часов и держать путь назад
Предыдущая версия и копия базы не удаляются двое суток. За это время отрабатывают суточные и недельные сценарии, которые в момент обновления просто не запускались, и именно они ломаются чаще ежеминутных.
Схема из пяти блоков слева направо со стрелками: «1. Полная копия + ключ шифрования», «2. Развернуть новую версию на тестовом контуре», «3. Контрольный набор: 10–15 сценариев», «4. Обновление боевого контура в окно», «5. Наблюдение 48 часов». Под блоками 2 и 3 — пунктирная стрелка возврата к блоку 1 с подписью «нашли поломку — откат бесплатный». Под блоком 5 — подпись «предыдущая версия не удаляется двое суток». Сверху над всей схемой пометка «плановое окно — раз в квартал». Чертёжный стиль, подписи по-русски.
Точка, где облако снова дешевле
Арифметика простая, и её стоит проделать до покупки сервера. Годовая смета контура — 339 200 ₽, то есть 28 267 ₽ в месяц. Цена операции на российских облачных площадках лежит в диапазоне 0,10–0,25 ₽ — мы разбирали разброс в сравнении Albato, ApiX-Drive и Nodul. Делим одно на другое и получаем объём, при котором подписка сравнивается со своим сервером.
| Цена операции в облаке | Объём, при котором свой сервер сравнивается с облаком | Что это значит на практике |
|---|---|---|
| 0,10 ₽ | около 283 000 операций в месяц | Свой сервер оправдан только у крупного парка |
| 0,15 ₽ | около 190 000 операций в месяц | Типичный порог для компании 20–300 человек |
| 0,25 ₽ | около 113 000 операций в месяц | Свой сервер окупается уже на среднем парке |
Модельная компания из нашей сметы делает 150 000 операций в месяц. При 0,15 ₽ за операцию это 270 000 ₽ в год подписки против 339 200 ₽ своего контура: облако выигрывает 69 200 ₽ в год. Вывод неприятный для инженерного самолюбия, но честный: на этом объёме свой сервер покупают не за деньги. Его покупают за то, что персональные данные клиентов не покидают периметр, за отсутствие зависимости от платёжного посредника и за то, что глубину хранения журналов вы задаёте сами, а не выясняете из документации.
Двухосевой график. Горизонтальная ось — операций в месяц, от 0 до 300 000. Вертикальная — рублей в год, от 0 до 900 000. Горизонтальная серая линия на уровне 339 200 ₽ подписана «свой контур, не зависит от объёма». Наклонная синяя линия из нуля подписана «облако, 0,15 ₽ за операцию». Точка пересечения около 190 000 операций выделена и подписана «точка равенства». Вертикальная пунктирная отсечка на 150 000 операций с подписью «модельная компания: облако 270 000 ₽ против 339 200 ₽, разница 69 200 ₽». Все подписи по-русски.
Когда своя установка избыточна
Свой сервер — не признак зрелости, а инженерное решение с ценой. Есть пять ситуаций, в которых мы сами советуем взять российскую облачную платформу и не строить контур.
- В сценариях нет персональных данных. Если через них ходят только артикулы, остатки, суммы и номера документов без имён и телефонов, главный аргумент за свою установку исчезает. Остаются деньги, а по деньгам ниже 190 000 операций в месяц облако выигрывает.
- Меньше 15 сценариев и меньше 50 000 операций в месяц. Контур из пяти узлов на таком парке — это дорогая машина, которая возит одного человека. Разница в пользу подписки на этом объёме превышает 200 000 ₽ в год.
- Нет ни своего администратора, ни договора на поддержку. Сервер без дежурного хуже облака по всем параметрам: обновления не ставятся, копии не проверяются, диск кончается ночью, и никто об этом не узнаёт до утра. Кто именно должен держать этот контур и во что обходится роль, разбираем в материале про поддержку после запуска.
- Требуется отечественное ПО из реестра. Госзаказчику, субъекту КИИ или компании с таким требованием в контракте своя установка не поможет: n8n — зарубежный продукт, и место сервера этого не меняет. Здесь нужна платформа, присутствующая в реестре Минцифры.
- Нужна доступность 24/7 без окна на обслуживание. Один сервер её не даёт: любое обновление — это простой. Резервный контур с переключением стоит в полтора-два раза дороже базовой сметы, и на парке из 30 сценариев такие деньги обычно правильнее потратить на сами сценарии.
И общее правило, которое переживёт и n8n, и текущие тарифы. Решение «своё или облако» принимается не по вкусу к технологиям, а по двум числам: сколько операций в месяц делает ваш парк и есть ли в этих операциях персональные данные. Первое число даёт границу по деньгам, второе — границу по закону. Если оба ответа против своей установки, а её всё равно строят, значит, покупают не архитектуру, а спокойствие — и стоит хотя бы честно назвать эту статью расхода её именем.
Сервер в России закрывает вопрос «где лежат данные». Все остальные вопросы 152-ФЗ он оставляет вам.
