Make или n8n: что выбрать для автоматизации бизнеса

Коротко: для быстрого старта без возни с серверами бери Make, он живёт в облаке, открывается в браузере и прощает новичку почти любые ошибки. n8n имеет смысл разворачивать на своей машине, когда нужен контроль над данными, надоело считать операции и хочется платить российскому хостеру вместо зарубежного сервиса. Счёт в Make привязан к объёму работы, зато первый сценарий там собирается за вечер. У self-host обе оси развёрнуты в другую сторону: платёж за сервер не двигается при росте нагрузки, но сервером кто-то должен заниматься. Ниже показываю, как эта развилка выглядит на практике и по каким признакам выбирать под конкретную задачу.

Что такое Make и n8n?

Оба сервиса относятся к визуальным конструкторам автоматизаций. Ты соединяешь сервисы между собой в виде схемы: пришло событие (заявка, письмо, сообщение), робот прогоняет его через цепочку действий (записал в CRM, отправил в Telegram, добавил строку в таблицу). Код почти не нужен, логика собирается мышкой из готовых блоков.

Устройство сценария от конструктора не зависит. Начинается всё с триггера - события, которое запускает цепочку. За ним идут шаги, то есть действия в конкретных сервисах. Между шагами ставятся условия, по которым робот выбирает ветку. Отдельно описывается поведение при сбое: куда девать заявку, если CRM не ответила. Освоив эти четыре элемента, ты соберёшь сценарий в любом конструкторе, включая те, которых пока не существует.

• Make - облачный сервис. Ты заходишь в браузер, собираешь сценарий, он работает на их серверах. Ставить и обслуживать ничего не требуется.
• n8n - инструмент с открытым кодом. Есть облачная версия, но главная его особенность это self-host: ты ставишь его на свой сервер (VPS) и владеешь всем целиком.

Отдельно про коннекторы, потому что новички упираются в них раньше всего. Готовый блок для сервиса экономит вечер: поля подставляются из выпадающих списков, авторизация делается в два клика. Экзотику вроде самописной CRM или регионального сервиса рассылок приходится подключать универсальным HTTP-запросом, и тут уже нужно читать документацию сервиса, разбираться с заголовками и форматом ответа. Проверять наличие нужных блоков лучше до того, как ты выберешь инструмент, а не после оплаты годовой подписки.

Развилка отсюда простая: платить за удобство или вложить время в свой сервер. Если ты пока смотришь на автоматизацию сверху и выбираешь направление, помогает карта возможностей автоматизации бизнес-процессов с ИИ - там видно, куда вообще годится конструктор, а куда лучше зайти с другой стороны.

Чем Make отличается от n8n?

Выбор на практике решают три вещи: цена, self-host и порог входа. Ниже разбор по каждому пункту, а сначала общая картина.

Критерий	Make	n8n
Модель оплаты	По количеству операций в месяц	Бесплатно на своём сервере, либо подписка в облаке
Стоимость на малых объёмах	Бесплатного тарифа хватает на старт	Бесплатно (self-host) или бесплатный триал облака
Стоимость на больших объёмах	Растёт вместе с числом операций	Фиксированная, только цена VPS
Self-host (свой сервер)	Нет	Да, это основной сценарий
Порог входа	Низкий: собрал и работает	Средний: надо развернуть и обслуживать
Оплата из России	Сложность с картой	Своя карта не нужна, если хостишь сам
Открытый код	Нет	Да

Ещё одно отличие не помещается в таблицу, хотя всплывает на второй неделе работы. В Make сценарий существует только внутри их интерфейса: посмотреть его можно, вытащить в понятном виде и положить рядом с кодом проекта не получится. Схему n8n ты выгружаешь файлом, кладёшь в репозиторий и видишь в истории, кто и что менял месяц назад. Для одного человека разница почти незаметна, для команды из трёх это решающий пункт.

Таблица задаёт направление, а решение всё равно упирается в цифры твоей нагрузки. Поэтому дальше разбираем арифметику.

Сколько стоит сценарий и как посчитать операции заранее?

На малых объёмах разницы почти нет: бесплатного тарифа хватает у обоих. Дальше пути расходятся, и разобраться в этом лучше до того, как ты соберёшь двадцать сценариев и прирастёшь к одному инструменту.

Одна операция это один шаг сценария. Пришла заявка, робот создал карточку в CRM (операция 1), отправил уведомление в Telegram (операция 2), записал строку в таблицу (операция 3). Один клиент стоит три операции.

Дальше арифметика:

• 10 заявок в сутки по 3 шага - около 900 операций в месяц;
• 100 заявок в сутки по 3 шага - 9 000 операций в месяц;
• ежечасный парсинг каталога на 1 000 позиций - 720 000 операций в месяц.

Первая строчка живёт на бесплатном тарифе годами. Третья требует уже другого тарифного плана Make, а счёт поднимается ровно с той скоростью, с какой растут твои объёмы. На заявках и уведомлениях Make почти ничего не стоит, зато парсинг и массовые рассылки быстро превращаются в отдельную статью расходов.

Есть три места, где счёт разбухает незаметно.

Циклы по массивам. Блок, который перебирает список из 200 позиций, тратит операции на каждой позиции. В схеме это выглядит как один аккуратный квадратик, в отчёте по расходу - как двести шагов.

Пустые проходы. Сценарий раз в пять минут спрашивает почтовый ящик, есть ли новое письмо. Писем нет, но опрос уже случился и его посчитали. За месяц набегает около девяти тысяч операций, из которых полезны единицы.

Фильтры не в том месте. Если отсеивать лишние записи в конце цепочки, все предыдущие шаги успевают отработать. Перенос фильтра ближе к началу режет расход в разы, и с этого разумно начинать, когда счёт пополз вверх.

К этому добавляются повторные попытки. Сервис ответил ошибкой, робот дёрнул его ещё раз, потом ещё - каждая попытка тоже уходит в счётчик. Один нестабильный коннектор в цепочке способен удвоить месячный расход, причём в отчёте это выглядит как ровная работа сценария.

Прикинуть сумму можно за пять минут на салфетке. Умножь количество событий в сутки на число шагов, добавь запас процентов тридцать на ошибки и повторы, умножь на тридцать. Полученное число сравни с лимитами тарифов на сайте Make - и ты уже понимаешь, во что обойдётся идея, которую пока держишь в голове.

У n8n на своём сервере логика другая: ты оплачиваешь VPS, а число прогнанных через него операций на цену не влияет. Десять запусков или десять тысяч - счёт за сервер один и тот же. Под потоковые задачи self-host почти всегда выходит выгоднее. Взамен появляется другая цена, твоё время на обслуживание, и её тоже честно считать в часах.

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

Что такое self-host и зачем он n8n?

Self-host означает, что инструмент крутится на твоём собственном сервере под твоим полным контролем. У n8n это норма, у Make такого нет вовсе.

Что даёт свой сервер:

• Контроль данных. Клиентская база, переписки, цифры остаются внутри твоего периметра. Для чувствительных данных это весомый аргумент, особенно если ты подключаешь к сценариям нейросети и собираешь для них базу знаний из внутренних документов.
• Нет лимитов по операциям. Ты оплачиваешь железо, и количество шагов внутри сценария на счёт не влияет.
• Независимость. Сервис не поднимет цену в одностороннем порядке и не отключит тебе доступ.

Что это стоит. Нужен VPS: отдельный ежемесячный счёт, фиксированный, одинаковый при десяти запусках и при десяти тысячах. Нужно развернуть n8n и время от времени обновлять. Сегодня установка идёт по инструкции почти в два клика, но упавший в субботу вечером сервер чинишь ты сам, без службы поддержки на том конце.

Полезно заранее закрыть бытовые вопросы, которые всплывают на второй неделе. Скажем, доступы к серверу: если они лежат только в твоей голове, отпуск превращается в риск для всей автоматизации, поэтому пароли уезжают в менеджер паролей с доступом ещё для одного человека. Резервные копии сценариев стоит выгружать по расписанию и хранить не на том же сервере, где крутится n8n. Переезд к другому хостеру проходит спокойно, когда у тебя есть выгруженные схемы и записанный список интеграций. Полчаса на эти три пункта экономят неделю нервов.

Для России self-host закрывает ещё и вопрос с оплатой. Зарубежная карта не понадобится: ты платишь только за сервер, а сервер берётся у российского хостера. Пошаговый маршрут развёртывания я разбирал отдельно в материале как освоить n8n с нуля - там как раз про то, что делать после аренды VPS. Общая ситуация с доступностью инструментов описана в обзоре ИИ-агенты для бизнеса в России.

Что проще для новичка?

Тут честно выигрывает Make. Зашёл, собрал сценарий, он сразу работает, серверов в кадре нет вообще. Интерфейс дружелюбный, ошибки прощаются, для первого знакомства с автоматизацией это лучший вход.

n8n на старте требует чуть больше: развернуть, настроить доступ, разобраться с обновлениями. Сборка самих сценариев выглядит похоже, вокруг них появляется техническая обвязка. Человеку, который никогда не имел дела с сервером, первый раз придётся посидеть с инструкцией час или два.

Здесь выручает ИИ: попроси у него пошаговую инструкцию по развёртыванию n8n на VPS, и он проведёт тебя за руку, включая команды и типовые ошибки. Решение о том, куда что ставить и кому дать доступ к базе клиентов, всё равно остаётся за тобой.

Есть и третий вариант, о котором забывают: не брать конструктор совсем. Разовая выгрузка отчёта или разбор одного файла делаются скриптом на двадцать строк быстрее, чем схемой из восьми блоков. Что реально закрывается кодом, разобрано в материале автоматизация рутины на Python, а сравнение с офисными инструментами есть в разборе макросы VBA против ИИ в Excel.

Как выглядит один и тот же сценарий в Make и в n8n?

Возьмём задачу, которая встречается почти в каждом малом бизнесе: заявка с сайта должна попасть в CRM, руководитель отдела должен получить уведомление, а маркетолог - строчку в таблице для отчёта.

В Make. Первым блоком ставится Webhook, он ловит отправку формы. Дальше идёт модуль CRM с действием «создать сделку», в поля подставляются данные из вебхука. Третий блок - Telegram, туда уходит текст с именем клиента и телефоном. Четвёртый - Google Sheets, добавляет строку. Между вебхуком и CRM ставится фильтр: заявки без телефона дальше не проходят. Сценарий включается тумблером, и всё, он живёт в облаке.

В n8n. Порядок узлов тот же самый: Webhook, узел CRM, узел Telegram, узел Google Sheets. Развилка делается узлом IF. Отличается обвязка вокруг: вебхук указывает на адрес твоего сервера, поэтому у сервера должен быть внешний адрес и сертификат, а сам n8n должен быть запущен как сервис, чтобы пережить перезагрузку машины.

Со стороны сборки разница измеряется четырьмя щелчками мыши. По ответственности она гораздо больше: за доступность этого адреса в три часа ночи в облаке отвечает поставщик услуги, а на своём сервере ты. Первое решается за вечер, второе определяет, сколько внимания автоматизация будет требовать через полгода.

Полезная деталь для обоих конструкторов: сразу добавь ветку на случай ошибки. Пусть при сбое CRM робот кидает сообщение в отдельный чат с текстом заявки. Тогда потерянная заявка превращается в письмо, которое можно обработать руками, и клиент не пропадает.

Куда уходят деньги: разбор случая

Условный пример, собранный из типовых ситуаций. Небольшой интернет-магазин автозапчастей держит на Make три сценария: обработку заявок, рассылку статусов заказа и уведомления менеджерам. Заявок в день немного, счёт держится в пределах бесплатного тарифа, всё устраивает.

Дальше владелец решает следить за ценами конкурентов. Сценарий обходит 800 позиций каждый час и записывает изменения в таблицу. Расход подскакивает до сотен тысяч операций в месяц, тариф улетает вверх, и появляется вопрос, за что именно уходят деньги.

Разбор показывает три вещи. Каталог конкурента обновляется примерно раз в сутки, поэтому ежечасный обход бессмысленен. Из 800 позиций реально важны 120, остальные лежат мёртвым грузом. Запись в таблицу идёт по одной строке, хотя пакетная запись сокращает число шагов в разы.

Дальше расходятся два пути. Можно остаться в Make: урезать частоту до двух раз в сутки, сузить список до 120 позиций, писать пакетом. Расход падает примерно в тридцать раз, и задача снова помещается в недорогой тариф. Другой вариант - вынести именно парсинг на n8n на своём сервере, оставив в Make лёгкие сценарии по заявкам. Тяжёлая задача перестаёт зависеть от счётчика операций, а простые вещи остаются там, где их удобно править вечером с телефона.

Смешанная схема, кстати, работает лучше, чем кажется. Никто не заставляет держать всю автоматизацию в одном инструменте: облако хорошо там, где важна скорость правок, свой сервер - там, где важен объём. Связать их можно тем же вебхуком.

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

Что выбрать под свою задачу?

Решение упирается в то, во что ты уткнёшься первым: в счёт по операциям, в чужое облако с твоей клиентской базой или в проблему с зарубежной картой.

Make подходит, когда объёмы измеряются сотнями операций: заявки, уведомления, редкие интеграции между сервисами. Сюда же попадают случаи, когда серверы трогать не хочется вообще и когда вопрос оплаты закрыт зарубежной картой или бесплатным тарифом.

n8n стоит брать, если счётчик операций уже пополз вверх, если данные клиентов не должны лежать в чужом облаке или если оплата картой превратилась в главную головную боль. Self-host снимает все три пункта разом: платишь только за сервер, а сервер арендуешь у российского хостера.

Если задача пока не выбрана, полезнее сначала определиться с ней, а не с инструментом. Короткий список того, что окупается первым, есть в подборке 7 задач для ИИ-ассистента в малом бизнесе.

Отдельная развилка возникает, когда автоматизация перестаёт быть цепочкой шагов и начинает принимать решения. Конструктор хорош там, где логика описывается условиями. Если задача требует понимания текста, ответов клиенту и выбора действия по смыслу обращения, дальше идут ИИ-агенты для бизнеса, а конструктор служит агенту руками. Самый частый первый шаг в эту сторону - чат-бот для бизнеса, собранный поверх той же связки. Вопрос, делать это самому или заказать, разобран в материале ИИ-агенты под ключ или собрать самому.

Как перенести сценарий из Make в n8n?

Автоматического переноса между сервисами нет. Пересборка руками занимает меньше времени, чем кажется, если делать её по порядку.

1. Выпиши логику на бумагу. Триггер, шаги, условия, что происходит при ошибке. Именно это и есть твоя автоматизация, конструктор лишь способ её выполнить.
2. Проверь, есть ли нужные узлы. Популярные сервисы поддержаны в обоих инструментах. Экзотику придётся подключать через HTTP-запрос, и лучше выяснить это заранее.
3. Собери одну ветку и прогони на тестовых данных. Начинай с главного пути, остальные развилки подключишь потом.
4. Перенеси доступы. Ключи и токены создаются заново, старые после переезда стоит отозвать.
5. Подержи оба сценария параллельно несколько дней. Пусть новый пишет в тестовую таблицу, пока старый работает по-боевому. Расхождения вылезут сразу.
6. Отключи старый сценарий, схему сохрани. Экспорт из n8n делается в файл, положи его в репозиторий или в облако рядом с описанием процесса.

Отдельно про сроки: на простую цепочку из четырёх шагов уходит вечер, на связку с самописной CRM и хитрыми условиями закладывай пару дней. Основное время съедают не блоки, а восстановление тех мелких договорённостей, которые копились в старом сценарии месяцами: какой формат телефона считается правильным, куда девать заявки с корпоративных доменов, кому уходит уведомление в выходные.

Тот же порядок работает и в обратную сторону, если после эксперимента с сервером ты решишь вернуться в облако.

Что отвечать на частые возражения?

«А вдруг сервис закроют или заблокируют оплату, и я потеряю все сценарии?» Логику разумно держать в описании процесса, а копию схемы - в файле у себя. Тогда закрытие сервиса превращается в вечер работы по пересборке. Потеря случается у тех, у кого автоматизация существует единственным экземпляром внутри чужого интерфейса.

«Свой сервер это дорого». Ежемесячная аренда VPS под n8n сопоставима с недорогой подпиской на облачный сервис, при этом счёт не реагирует на рост нагрузки. Дорогим self-host делает время: обновления, бэкапы, разбор падений. Если такого времени нет и не предвидится, честнее платить за облако.

«У меня нет технаря». Для сценариев на заявках и уведомлениях технарь и не нужен, Make закрывает это целиком. Понадобится он, когда пойдут потоковые задачи и чувствительные данные. До этого момента прекрасно живётся без него.

«Проще нанять человека, чем городить роботов». Робот выигрывает на повторяющихся однотипных операциях без исключений. На задачах с разговором, договорённостями и нестандартными случаями человек остаётся дешевле и надёжнее. Разграничение подробно разобрано в материале цифровой двойник сотрудника: миф или рабочий инструмент.

«Хочу сразу собрать всё и красиво». Автоматизация, собранная за один заход на двадцать сценариев, ломается вся сразу и разбирается неделями. Один рабочий сценарий, проживший месяц без вмешательства, полезнее двадцати сырых.

«Мне советуют сразу брать n8n, раз он бесплатный». Бесплатен там только софт. Час твоего времени на настройку сервера тоже чего-то стоит, и на старте, когда задача ещё не проверена, этот час выгоднее потратить на саму логику процесса. Проверил гипотезу в облаке - тогда и переезжай.

Из-за чего ломаются готовые сценарии?

Нет обработки ошибок. Сервис не ответил, сценарий встал, заявки ушли в пустоту. Ветка на случай сбоя с уведомлением в чат закрывает большую часть таких историй.

Дубли из-за повторных запусков. Робот заводит новую карточку на каждое письмо от одного клиента. Лечится проверкой на существующую запись перед созданием.

Опросы вместо вебхуков. Регулярный опрос сервиса тратит операции впустую. Там, где сервис умеет присылать вебхук, разумно переключиться на него.

Хрупкие привязки к структуре. Сценарий читает третью колонку таблицы по номеру. Кто-то вставляет колонку, всё разъезжается. Обращение по названию поля переживает такие правки.

Секреты внутри схемы. Токены и пароли, вписанные в текст блока, утекают вместе с экспортом схемы. В обоих конструкторах есть хранилище доступов, и оно существует ровно для этого.

Отсутствие логов. Через месяц ты не вспомнишь, почему сценарий однажды сработал странно. Отдельная таблица с записью ключевых событий разбирает такие вопросы за минуты.

Молчаливое истечение токена. Доступ к почте или таблицам выдан на срок, срок кончился, робот тихо перестал работать. Заметить это лучше по отсутствию ожидаемых записей, чем по звонку клиента через две недели.

Что делать после запуска, чтобы автоматизация жила?

Собранный сценарий требует немного внимания, иначе он тихо разваливается вместе с сервисами вокруг. Много времени это не занимает, если завести три привычки.

Первая - сигнал о тишине. Помимо уведомлений об ошибках заведи проверку, которая раз в сутки смотрит, было ли за день хоть одно срабатывание. Сломанный сценарий чаще всего не кричит, он просто молчит, и молчание надо ловить отдельно.

Вторая - копии и версии. Выгружай схему после каждого заметного изменения и подписывай, что именно поменял. Когда через два месяца окажется, что уведомления уходят не тому менеджеру, ты найдёшь правку за минуту вместо вечера догадок.

Третья - короткое описание процесса рядом со схемой. Три абзаца текста: зачем этот сценарий, что он трогает в боевых системах, кому звонить, если он встал. Без такого файла автоматизация превращается в чёрный ящик, который страшно выключать и невозможно передать другому человеку.

Раз в квартал полезно пройтись по списку живых сценариев и выключить те, чей результат никто давно не смотрел. Отчёт, который делался для ушедшего сотрудника, продолжает исправно есть операции и внимание.

Где в автоматизации всё равно нужен человек?

Робот исполняет то, что ему поручили, и вопросов не задаёт. Сценарий, который каждый час дёргает каталог, обновляемый раз в неделю, отработает свои сотни тысяч операций и промолчит. Тот, что плодит дубли карточек, бодро отчитается словом «выполнено». Ни Make, ни n8n не заметят бессмысленности процесса, они просто выполнят его быстрее.

Порядок работы отсюда простой: сначала разбираешь руками, как устроен процесс, потом отдаёшь роботу. Как проверить перед запуском: прогони сценарий на тестовых данных, возьми пять-десять реальных случаев и пройди их вручную. Сверь, что робот записал данные туда, куда нужно, и ничего не задублировал. После этого включай на поток.

По сути и Make, и n8n работают как цифровой сотрудник в твоей команде: тот, кто без устали перекладывает данные между сервисами. Если хочется собрать такого помощника целиком, а не отдельный сценарий, посмотри разбор как собрать ИИ-сотрудника с нуля. Разборы связок, готовые промпты и шаблоны ролей мы собираем в закрытом канале ИИмперии - оттуда можно взять рабочую заготовку вместо сборки с чистого листа.

Так что выбрать, Make или n8n?

Для первого сценария бери Make: он поднимается за вечер и не требует ничего, кроме браузера. Когда появится парсинг, массовые рассылки или клиентская база, которую нежелательно держать в чужом облаке, разворачивай n8n на своём сервере и переноси туда тяжёлую часть. Спокойный маршрут для большинства выглядит как переезд из простого в контроль, причём в тот момент, когда для переезда появилась реальная причина. Если ты только присматриваешься к теме и ещё не выбрал задачу, начни с обзора ИИ для малого бизнеса: с чего начать.

Источники

• Официальный сайт n8n - описание возможностей и модели self-host.
• Документация n8n - как развернуть и обслуживать инструмент на своём сервере.
• Тарифы n8n - актуальные планы облачной версии.
• Официальный сайт Make - описание платформы и модели оплаты по операциям.
• Тарифы Make - как считаются операции и лимиты.