n8n — конструктор сценариев автоматизации: логика собирается из блоков на холсте, а не пишется кодом. Один сценарий читается как фраза — случилось событие, взяли данные, проверили условие, записали в систему, написали человеку. Код в блоках допускается, но не обязателен: большинство сценариев обходится без него.
Что это такое и зачем оно нужно
Между программами, которыми компания уже пользуется, остаётся зазор, и закрывает его человек: заявка пришла на почту — менеджер перенёс её в таблицу, наступил понедельник — кто-то сел собирать сводку. n8n забирает эти операции себе. На холсте рисуется цепочка: слева блок, срабатывающий от события, дальше блоки, которые что-то делают с данными, между ними стрелки. Запущенный сценарий выполняет цепочку сам и сохраняет протокол каждого прохода.
Слово «конструктор» точнее слова «программа»: n8n соединяет то, что уже есть, — почту, таблицы, мессенджер, учётную систему, сайт, базу данных. Собственных бизнес-данных и своего интерфейса для сотрудников у него нет.
Чем он отличается от облачных конструкторов
Большинство конструкторов сценариев работает только как чужой сервис: сценарий живёт на стороне поставщика, оплата идёт за количество выполненных операций. n8n можно поставить на свой сервер, и отсюда две вещи, ради которых его обычно и выбирают.
Данные не уходят наружу. Содержимое заявок, договоров, писем и карточек клиентов идёт от одной вашей системы к другой через ваш же сервер. Там, где в данных персональные сведения, реквизиты или коммерческие условия, это условие, при котором автоматизацию вообще разрешают.
Цена не зависит от числа операций. Облачный конструктор берёт деньги за каждое срабатывание: сценарий, обходящий тысячу строк таблицы, стоит в тысячу раз дороже сценария на одну строку. На своём сервере платят за сервер — одинаково и при сотне операций в сутки, и при сотне тысяч. Разница проявляется на объёме, то есть там, где автоматизация и начинает приносить пользу.
n8n сценарии: из чего они собираются
Триггер — то, с чего всё начинается: расписание («каждый будний день в 10:00»), вебхук от сайта, новое письмо, новая строка в таблице, сообщение в мессенджере. Он один на сценарий.
Узлы-действия — прочитать таблицу, создать запись, отправить письмо, вызвать чужой сервис. Типовой рабочий сценарий — от пяти до пятнадцати таких узлов.
Условия и ветвления. Блок сравнивает значение и пускает данные по одной из веток: срок вышел — в одну сторону, не вышел — в другую.
Преобразование данных. Форматы между системами почти никогда не совпадают: дата в одном виде, телефон в другом, имена полей третьи. Отдельные блоки приводят их к нужному виду и объединяют потоки.
Обработка ошибок. Сервис не ответил, таблица оказалась пустой, в поле пришло не то. У узла настраивается, что делать при сбое: повторить, уйти по запасной ветке, остановиться и сообщить. Этот слой в готовых сценариях чаще всего отсутствует — и именно он отличает работающую автоматизацию от демонстрации.
n8n примеры: что на нём делают на практике
Утренний обход таблиц с договорами. Проектная компания вела договоры в сводных таблицах, но таблица молчала о сроках. Сценарий выходит на работу каждое утро в 10:00, читает таблицы целиком и находит договоры, до конца которых осталось пять рабочих дней. В рабочую группу приходит сообщение с датой, номером договора и заказчиком; если за пять дней ничего не изменилось, в день окончания приходит второй сигнал. Поправили дату в таблице — напоминания прекратились сами. Сборка заняла день.
Счётчик дней налогового резидентства. Статус держится на арифметике — 183 дня в стране за период, — но каждый выезд сдвигает дату. Сценарий ведёт счёт сам: по понедельникам присылает статус без запроса и отвечает по команде в любой момент, например до покупки билетов. Считаются две даты — без выездов и с учётом запланированных поездок.
Приём заявок с сайта прямо в мессенджер. Обычная форма отправляет письмо на общий ящик, где заявка ждёт, пока его откроют; здесь она попадает туда, где менеджер и так сидит весь день. Весь сценарий — два узла: вебхук и сообщение.
Конвейер из пяти сервисов. Салону маникюра нужен поток коротких видео, но снимать и монтировать их некому. Сценарий берёт фотографию готовой работы, описывает её нейросетью, генерирует по описанию три видеосцены, сочиняет музыку и монтирует ролик на 24 секунды — около десяти минут от фото до результата. Всё промежуточное пишется в базу: по каждому ролику видно, что готово, а что в работе.
Голосовая заметка становится событием календаря. Фраза вроде «встретимся в четверг в три» превращается в запись с тремя напоминаниями за 3,7 секунды. Распознавание речи и разбор смысла идут на локальной машине, обращений к облачным моделям нет — в ежедневнике имена, адреса и договорённости. Четыре сценария, 53 шага, собрано за день. Здесь же виден предел инструмента: перевод разговорного времени в цифры («полтретьего» — это 14:30) пришлось вынести в отдельный шаг — модель на таких формах ошибалась устойчиво.
n8n хостинг: облако или свой сервер
| Облачная версия | На своём сервере | |
|---|---|---|
| Что нужно | учётная запись | сервер, домен, сертификат |
| Кто обслуживает | поставщик | администратор заказчика или подрядчик |
| Данные | идут через чужую инфраструктуру | не покидают контур |
| Цена | зависит от числа операций | стоимость сервера, от объёма не зависит |
| Обновления | приходят сами | ставятся вручную, в удобное время |
| Кому подходит | проверить идею, пара сценариев | постоянная работа, объём, чувствительные данные |
Для развёртывания хватает недорогой виртуальной машины. Установка — работа администратора; заказчику важнее два условия: у сервера есть человек, который его обслуживает, и резервная копия, которая делается сама. Обновление изредка меняет поведение блоков, поэтому обновляются не по факту выхода версии, а по необходимости, предварительно выгрузив сценарии.
Где n8n не подходит
Высокая нагрузка. Тысячи операций в минуту — не его случай: за наглядность конструктор платит накладными расходами на каждом шаге. Признак приближения к границе — сценарий, переставший укладываться в свой интервал запуска.
Сложная бизнес-логика. Когда ветвлений два десятка и правка в одном месте ломает соседнее, честнее вынести логику в код: клубок из полусотни блоков читается хуже сорока строк кода.
Задачи, где нужен интерфейс для пользователя. Сценарий — это механика, а не экран. Если сотрудникам нужно смотреть списки, фильтровать и редактировать карточки, нужна система с интерфейсом, а сценарии живут на её стыках.
На что смотреть, если сценарии собирает подрядчик
Журнал запусков и уведомление об ошибке. У каждого сценария виден список проходов с результатом, а сбой приходит сообщением. Сценарий без оповещения ломается молча, и все продолжают считать, что он работает.
Доступы не лежат в сценарии открытым текстом. Пароли, ключи и токены хранятся отдельно, в разделе учётных данных. Ключ, вписанный прямо в блок, уедет вместе с выгрузкой кому угодно, кто её получит.
Сценарии выгружаются и переносятся. Если подрядчик не отдаёт выгрузки, получается ровно та зависимость, ради ухода от которой конструктор обычно и берут. Отдельно проверяется, на кого оформлены сервер и домен, — на компанию, а не на исполнителя.
Понятные названия блоков. «HTTP Request1» через полгода не расшифрует и автор.
Сколько занимает сборка
| Что собирается | Срок |
|---|---|
| Форма на сайте — сообщение в мессенджер | день |
| Обход таблиц по расписанию с двумя сигналами | день |
| Расчёт с накоплением данных и ответом по команде | день |
| Связка нескольких внешних сервисов в конвейер | несколько дней |
| Комплект связанных сценариев с базой и локальными моделями | от дня до недели |
Строки таблицы — из собранных сценариев, а не из оценки. Удлиняет срок не количество блоков, а количество исключений: каждое «а если в таблице пустая ячейка» — это ветка, проверка и способ отката. Как выбрать, с какого процесса начинать, — в статье Что автоматизировать первым.
Вопросы и ответы
Нужно ли уметь программировать, чтобы работать с n8n? Для типового сценария — нет: триггер, несколько действий, условие и уведомление собираются мышкой. Код появляется там, где данные нужно преобразовать нестандартно; таких мест немного, но полностью без них обходятся редко.
Чем n8n отличается от других интеграционных платформ? Главное — возможность поставить его на свой сервер и не отдавать данные наружу, а вместе с ней независимость цены от числа операций. Остальное сравнимо: набор готовых блоков, холст, журнал запусков. Разбор класса инструментов — в статье Интеграционные платформы.
Заменяет ли n8n CRM или учётную систему? Нет: у него нет ни своего хранилища бизнес-данных, ни интерфейса для сотрудников. Типичная связка — заявки и сделки живут в системе, а сценарии закрывают стыки между ней, сайтом, мессенджером и учётом.
Можно ли собрать на нём что-то с искусственным интеллектом? Да: расшифровка речи, разбор письма, выжимка из текста, поиск по смыслу. Модель встраивается как обычный блок и работает как в облаке, так и на своём железе — в ежедневнике с голосовым вводом распознавание идёт локально.
Что будет со сценариями, если подрядчик перестанет отвечать? При работе на своём сервере — ничего, если сервер оформлен на компанию, а выгрузки лежат у заказчика. Сценарий читается визуально, поэтому разобраться в чужом легче, чем в чужом коде.
Коротко
n8n — инструмент для стыков между системами: там, где данные переносит человек, встаёт сценарий из блоков. Сильная сторона — свой сервер, а с ним данные внутри контура и цена, не зависящая от объёма. Границы — нагрузка, сложная логика и всё, где нужен экран для пользователя. Про предел низкокодового подхода в целом — в статье Low-code: что это и где предел.
Разбор задачи и оценка — через контакты.