Автоматизация на n8n и Make

Зачем автоматизировать процессы с n8n и Make

Автоматизация бизнес-процессов — это перенос повторяющихся действий из головы сотрудника в сценарий, который выполняется сам: заявка пришла, карточка в CRM создалась, менеджер получил уведомление. Рынок no-code автоматизации начинался с Zapier — конструктора «если в одном сервисе что-то произошло, сделай действие в другом». n8n и Make выросли как аналоги Zapier, но пошли дальше: добавили визуальные ветвления, работу с массивами данных и, к 2026 году, полноценные AI-агентные ноды. Для агентства, которое работает с владельцами интернет-бизнеса, автоматизация — конкретный вопрос: где заканчивается ручная работа менеджера и начинается сценарий, который делает то же самое без него.

n8n и Make: что это и чем отличаются друг от друга

n8n — визуальный конструктор workflow с открытым кодом (fair-code лицензия, не классический open source), который можно развернуть на собственном сервере через n8n cloud или полностью самостоятельно. Make (бывший Integromat) — исключительно облачный сервис: self-hosted версии у него нет и не планируется, вся инфраструктура работает на стороне вендора.

Здесь и начинается первая практическая проблема для российского пользователя. n8n cloud с 2022 года закрыл регистрацию новым клиентам из России и Беларуси — прямая оплата российской картой не проходит. Make формальных блокировок для россиян не вводил, но платёж российской картой тоже не проходит — приходится использовать зарубежную карту или платёжного посредника с комиссией примерно 350–1050 рублей за платёж или процент от суммы.

Практический выход для n8n прямой и бесплатный: self-hosted community edition разворачивается на любом VPS, включая российский хостинг, без ограничений по числу workflow, сценариев и шагов. Для Make такого пути нет — только облако и посредник для оплаты. С этого стоит начинать выбор инструмента: если вы не готовы администрировать сервер, Make проще на старте; если готовы — self-hosted n8n снимает и вопрос оплаты, и вопрос хранения данных.

Из чего состоит сценарий: ноды, триггеры, workflow

Workflow — это сценарий целиком: последовательность нод (шагов), соединённых связями. Нода в n8n — единица действия: получить данные, отфильтровать, отправить запрос, записать в таблицу. Есть триггерные ноды, с которых сценарий стартует (webhook, расписание, ручной запуск, событие в другом сервисе), и обычные ноды-действия. У n8n порядка 400+ готовых нод под конкретные сервисы, но ключевое отличие — универсальная HTTP Request-нода: если готовой интеграции нет, можно обратиться к любому API напрямую. У Make каталог готовых модулей шире — свыше 3000 — но при работе с нестандартным или закрытым API часто приходится ждать, пока появится готовый модуль, либо оплачивать кастомную разработку.

Порог входа у инструментов разный. Make визуально нагляднее и проще для человека без технического бэкграунда: сценарий читается как последовательность иконок. n8n требует понимания структуры JSON и, для нетривиальной логики, немного JavaScript в Code-ноде — но по мере роста сложности это окупается: n8n лучше держит ветвления и даёт прозрачную отладку данных на каждом шаге, тогда как у Make сложные сценарии с множеством условий превращаются в трудноотлаживаемую «простыню» модулей.

Отдельно стоит понимать модель ценообразования — она напрямую определяет архитектуру сценария (подробнее в таблице ниже). n8n считает по executions: один запуск всего workflow — это одна единица расхода независимо от числа шагов внутри. Make считает по операциям — с 27 августа 2025 года модель официально переименована в credits, и это важно: старые обзоры ещё пишут «операции», хотя единица списания и то, как её тратят AI-модули, изменились. Каждый модуль в Make — минимум один кредит, включая каждую итерацию цикла, поэтому обработка таблицы из тысячи строк «съедает» кредиты кратно быстрее, чем в n8n то же самое execution. Вывод простой: чем сложнее и многошаговее автоматизация, тем выгоднее n8n; для линейного сценария из одного триггера и двух-трёх действий разница в цене не критична.

Webhook и API: как сервисы обмениваются данными в сценарии

Webhook — это URL-адрес, на который внешний сервис сам присылает данные в момент события: пришла заявка на сайте, изменился статус заказа, написали в Telegram. Сценарий не спрашивает «есть ли что-то новое» по расписанию — он ждёт, пока данные придут сами, и реагирует мгновенно. Это отличается от вызова API, где инициатор запроса — сам сценарий: он обращается к чужому сервису и запрашивает или отправляет данные.

Частая ошибка новичков — путать встроенный REST API n8n и Webhook-ноду. REST API n8n предназначен для управления самой платформой (создать workflow, запустить его программно, получить список выполнений) — это административный интерфейс, а не точка приёма внешних событий. Для приёма данных снаружи — от Telegram, CRM, формы на сайте — нужна именно Webhook-нода с триггером.

Технически webhook принимает POST-запрос с телом в формате JSON: сервис-отправитель формирует структуру данных (имя клиента, телефон, текст сообщения) и отправляет её на webhook url, который выдаёт n8n или Make при создании сценария. Дальше данные внутри workflow можно фильтровать, преобразовывать, направлять по разным веткам условиями роутера.

Для self-hosted n8n webhook-триггеры требуют настроенного обратного прокси (Nginx или Traefik) с валидным SSL-сертификатом — без этого часть внешних сервисов не сможет достучаться до сервера. Это упускают в беглых руководствах «разверни n8n за десять минут»: сценарий может быть собран идеально, но не получать ни одного события, потому что вебхук физически недоступен снаружи.

AI-агенты внутри n8n: как встроить нейросеть в сценарий

Связка «визуальный workflow + AI-агенты» — то, что сделало именно n8n самым обсуждаемым инструментом автоматизации 2026 года. Акцент сместился с «no-code коннектора сервисов» на «конструктор AI-агентов»: сценарий может включать ноду AI Agent, которая сама решает, какой инструмент вызвать и в каком порядке, опираясь на выбранную языковую модель.

Ключевое преимущество n8n здесь — открытая архитектура: агент не привязан к одному провайдеру модели, можно подключить любую доступную LLM. К AI Agent-ноде добавляется Memory-нода — она удерживает контекст диалога между сообщениями: простая Simple Memory для базового сценария или подключение к Postgres/Redis, если истории диалогов должны переживать перезапуск сервиса. Без Memory-ноды агент отвечает на каждое сообщение так, будто видит пользователя впервые — для чат-бота поддержки или продаж это неприемлемо.

Make тоже добавил AI-модули, но для кастомной агентной логики с собственной памятью гибкость n8n за счёт открытой архитектуры и Code-ноды пока ощутимо выше — если задача не «вызвать нейросеть один раз», а собрать агента, который помнит контекст и принимает решения по сложной логике.

Примеры сценариев: от простой интеграции до бизнес-процесса

Три сценария, которые показывают диапазон задач — от чат-бота до потока писем на масштабе.

Telegram-бот с AI-агентом и памятью. Telegram Trigger принимает сообщение → AI Agent обрабатывает его выбранной языковой моделью → Memory-нода (Simple Memory, Postgres или Redis) удерживает историю диалога → ответ уходит обратно в Telegram. Это уровень 2026 года: не бот-эхо с заранее прописанными кнопками, а агент, который ведёт связный диалог и помнит, о чём говорили минуту назад.

CRM, уведомления и аналитика для интернет-бизнеса. Заявка с сайта или формы → создание либо обновление карточки в CRM (у российского бизнеса это чаще amoCRM или Bitrix24) → уведомление менеджеру и клиенту в Telegram → запись данных в таблицу для отчёта по конверсии. Это прямой мостик к внедрению ИИ-менеджеров и автоматизации продаж: один сценарий закрывает и скорость реакции на заявку, и отчётность, которую раньше собирали вручную.

Обработка входящей почты на масштабе. Известен реальный случай, когда компания с потоком до 10 000 писем в день внедрила автоматизацию на n8n силами сотрудника без опыта разработки — любое повторяющееся действие с письмом перевели в сценарий. Пример показывает, что автоматизация на n8n не требует штатного разработчика — требует человека, который методично разбирает процесс на шаги.

Классический пример «таблица → фильтр → персонализированное сообщение» здесь намеренно не привожу подробно — он есть в каждом втором вводном ролике про n8n и как иллюстрация возможностей инструмента уже ничего не добавляет.

Как выбрать между n8n, Make и готовыми SaaS-конструкторами

Универсального ответа «что лучше» нет — есть вопрос, для какой задачи и какого бюджета что выгоднее с учётом полной стоимости владения. Self-hosted n8n почти бесплатен по деньгам (аренда VPS от нескольких долларов в месяц), но требует времени на настройку и администрирование: обновления, бэкапы, мониторинг. Make или готовые SaaS-агрегаторы (в том числе российские аналоги Zapier вроде Альбато) требуют абонентской платы, но не требуют технического обслуживания.

Практический ориентир: для простой линейной интеграции — заявка попала в CRM, отправилось уведомление — визуальная простота Make или локального SaaS-конструктора чаще экономит время, чем разворачивание сервера ради трёх шагов. Для сложной многошаговой логики с ветвлениями, AI-агентами и обработкой больших объёмов данных self-hosted n8n почти всегда выгоднее и по деньгам, и по гибкости.

Частая ошибка на этом этапе — выбирать инструмент не по задаче, а «потому что все советуют»: брать Make под сложную AI-агентную логику, где n8n выигрывает по гибкости и цене, или наоборот пытаться в n8n собрать простейшую линейную интеграцию, где хватило бы визуальной простоты более лёгкого инструмента.

С чего начать обучение автоматизации на n8n

Если вы выбираете self-hosted путь, стандартный и самый надёжный способ установки — Docker Compose, а не прямая установка через npm: так проще обновлять версию и переносить сервер целиком. Рекомендуемая операционная система — Ubuntu 22.04 LTS как наиболее протестированная в сообществе. По требованиям к серверу на август 2026 года: раньше хватало 1 vCPU и 1 ГБ оперативной памяти, но для AI-агентов и более тяжёлых интеграций с CRM и аналитикой реалистичный минимум — 2 vCPU, 4 ГБ RAM и от 20 ГБ диска.

Отдельный пункт, который стоит решить сразу, а не после первого сбоя, — база данных. По умолчанию n8n использует SQLite: она годится только для теста, потому что не держит параллельную запись, не даёт нормального бэкапа и усложняет миграцию при росте истории выполнений. Для рабочего использования нужен PostgreSQL — он настраивается в том же docker-compose за несколько минут и снимает эту проблему полностью.

Из типичных ошибок первых недель, помимо путаницы webhook/API и SQLite в проде: злоупотребление Continue On Fail, которая не даёт сценарию упасть целиком, но маскирует реальные ошибки; отсутствие мониторинга — workflow может зависнуть без уведомления, если не настроен error workflow с оповещением в Telegram; смешение продовых и тестовых ключей API без переменных окружения; и на сервере — открытые порты, отсутствие SSL, дефолтные пароли.

Дальше в разделе «Агенты и автоматизация» я разбираю смежные темы — от базовых терминов до устройства MCP и собственных субагентов, ссылки ниже.