n8n vs Make vs Zapier: честное сравнение для среднего бизнеса в 2026

Что выбирают компании сейчас и почему этот выбор изменился

Интерес к self-hosted автоматизации растёт: n8n Community Edition всё чаще разворачивают прямо на серверах компании, минуя облако вендора. Причин несколько, и они не одинаковые для разных сегментов рынка.

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

Make прошёл интересный путь после ребрендинга с Integromat в 2022-м. Сначала казалось, что смена названия просто запутала старых пользователей. К 2025-му Make добавил поддержку AI-агентов и сценариев с разветвлённой логикой, и это вернуло интерес. Сейчас Make берут те, кому нужна визуальная логика сложнее, чем в Zapier, но без своего сервера.

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

По деньгам: точные цифры зависят от объёма операций, но при серьёзном использовании Zapier для операционных процессов стоимость подписки быстро растёт, и разовые затраты на разворачивание n8n на VPS начинают смотреться иначе.

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

К середине 2025 года сегмент корпоративных AI-ассистентов вырос втрое по сравнению с 2023-м, оставив позади инструменты для индивидуальных разработчиков.

Модели ценообразования: где деньги утекают незаметно

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

Zapier: таск за каждое действие. Тариф Professional начинается от $73/мес за 2000 тасков. Таск это одно действие в Zap. Получили вебхук, отправили в Slack, записали в Google Sheets, обновили в HubSpot, четыре таска за один прогон. И тут начинается главная боль: цикл по массиву. Если ваш Zap получает список из 100 строк и для каждой делает Create Contact в CRM, это 100 тасков за один входящий триггер. Плюс фильтр, который отсеял запись, в ряде конфигураций всё равно списывает таск. На потоке в 10к операций в день вы вылетаете в Company-тариф очень быстро.

Make (бывший Integromat): operations. Считает операции, и одна операция это один модуль, обработавший один bundle. Похоже на Zapier по логике, но цены другие: Core $10.59/мес за 10к операций, Pro $18.82 за те же 10к плюс расширенные фичи. На сопоставимой нагрузке Make нередко выходит заметно дешевле Zapier. Бонус: фильтры и роутеры, которые ничего не пропустили, операцию не съедают.

n8n Cloud: executions. Здесь учётная единица это весь workflow целиком. Запустился флоу, отработал 200 шагов внутри, обработал массив из 5000 элементов через SplitInBatches, это один execution. Starter $24/мес даёт 2500 executions, Pro $60 за 10к. Для тяжёлых пакетных задач это принципиально другая модель по сравнению с Zapier.

Self-hosted n8n. VPS за $10-40/мес, и никаких лимитов на запуски вообще. Платите только за CPU и RAM. Подводный камень один: вы сами админите, бэкапите Postgres и обновляете контейнер. Для команды без девопса это скрытый налог часами разработчика.

Реальный пересчёт. Возьмём типовую задачу: синхронизация amoCRM с 1С, 10 000 изменённых записей в день. Воркфлоу: триггер по вебхуку из amoCRM, нормализация полей, проверка дубля в 1С через HTTP, апдейт или создание, лог в Postgres. Пять шагов на запись.

Ниже приблизительные ориентиры для такого сценария. Точные цифры зависят от тарифной сетки на момент расчёта:

Платформа	Единиц в день	Тариф	Месяц (ориентир)
Zapier	~50 000 тасков	Company (высокий объём)	высокий
Make	~50 000 операций	Teams (высокий объём)	умеренный
n8n Cloud	~10 000 executions	Pro 10k	$60
n8n self-hosted	без счёта	VPS 4 vCPU	$20-40

Разрыв между Zapier и self-hosted n8n на подобном сценарии может быть весьма значительным. А если ту же синхронизацию в n8n завернуть в один workflow с батчингом, executions существенно падает.

Вывод по биллингу простой: считайте не подписку, а единицу работы вашего конкретного воркфлоу. Цикл из 100 элементов в Zapier и в n8n Cloud это разница между "сожрал дневную квоту" и "одна галочка в логах".

Стартовая цена в $20 в месяц превращается в $400+ после учёта расходов на API-вызовы, хранение контекста и дополнительные интеграции.

Каталог интеграций: цифры против реальности

Цифры на лендингах любят все. Zapier хвастается 7000+ приложениями, Make около 2000, n8n называет более 500 нод. Если смотреть только на эти числа, выбор очевиден. Но это маркетинг, а не инженерия.

Zapier действительно лидер по охвату западных SaaS. Если у вас стек из Notion, HubSpot, Airtable, Slack и десятка нишевых американских инструментов, ничего быстрее Zapier вы не соберёте. Готовый коннектор, два клика, поехали. За это вы платите по задачам и упираетесь в потолок логики: ветвления есть, но сложный data mapping превращается в боль.

Make сильнее именно там, где Zapier пасует. Визуальный маппинг полей, итераторы, агрегаторы, нормальная работа с массивами и вложенными JSON. Около 2000 нативных модулей, каждый продуман с точки зрения структуры данных, а не просто "вход-выход". Когда сценарий начинает ветвиться на 20 шагов с фильтрами и трансформациями, в Make это читается, в Zapier превращается в простыню.

n8n играет в другую игру. Ноды это база, но настоящая сила в HTTP Request. Любой REST или GraphQL API подключается за пять минут: URL, метод, заголовки, тело, аутентификация. Если у сервиса есть документация, у вас есть интеграция. Плюс self-hosted, плюс код прямо в ноде на JavaScript или Python.

Теперь про российскую реальность. Bitrix24, amoCRM, МойСклад, 1С, нативных коннекторов почти нигде нет. У Make появились модули для Bitrix24 и amoCRM, но они покрывают базовые сущности и регулярно отстают от изменений API. У Zapier с этим совсем плохо. На практике всё равно делаешь через webhook на вход и HTTP-запросы на выход, так что вопрос только в том, насколько удобно платформа даёт работать с произвольным HTTP.

Мессенджеры распределены неровно. Telegram, WhatsApp Business и VK у n8n и Make закрыты прилично: Telegram через бот-API нативно, WhatsApp Business через официальные провайдеры (Twilio, 360dialog, Wazzup), VK через сообщества. У Zapier WhatsApp ограничен парой коннекторов с жёсткими лимитами по шаблонам, для русскоязычных рассылок это часто тупик.

Конкретный кейс из практики. Интеграция с 1С через OData: нужно тянуть документы реализации, фильтровать по контрагенту, обновлять статусы. В Make это делается, но HTTP-модуль там менее гибкий по работе с заголовками и сессионными куками, а 1С любит и то и другое. В n8n HTTP Request нода съедает OData-запросы целиком, включая $filter, $expand, $select, авторизацию через Basic или сессионный токен. Парсинг ответа в JS-ноде, дальше в Bitrix24 через webhook. Сценарий собирается за вечер и держится годами.

Вывод простой: число коннекторов в каталоге говорит о том, насколько платформа удобна для типового западного SaaS-стека. Для российского контура смотрите не на цифру, а на то, как платформа работает с сырым HTTP и аутентификацией. По этому критерию n8n впереди, Make близко, Zapier заметно отстаёт.

Сложность входа: кто справится без разработчика

Zapier рассчитан на человека, который открыл браузер и хочет результат сегодня. Маркетолог без технического бэкграунда собирает первый зап за 15 минут: выбрал триггер, выбрал действие, смапил поля. Больше 6000 готовых шаблонов покрывают 80% типовых задач ещё до того, как нужно будет думать самостоятельно. Порог входа здесь минимальный.

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

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

Экономику тоже стоит считать. Привлекать разработчика под n8n оправдано тогда, когда количество активных воркфлоу создаёт устойчивую нагрузку. При небольшом числе автоматизаций затраты на поддержку часто превышают стоимость подписки на Zapier Teams. Компании, которые приходят к n8n с тремя автоматизациями и большими амбициями, обычно через квартал возвращаются к Zapier или оставляют воркфлоу сломанными.

Практический ориентир: если в команде нет человека, который комфортно работает с API и отлаживает запросы в Postman, Zapier закроет задачу быстрее и дешевле. Make подойдёт, если есть хотя бы один человек с аналитическим складом ума и временем разобраться. n8n требует выделенного ресурса с первого дня.

Тимлиды осваивают AI-ассистентов быстрее джуниоров: им не нужно одновременно учиться писать код и объяснять задачи на языке промптов.

Безопасность и размещение данных

Запускаете автоматизацию в Zapier или Make и передаёте через неё персональные данные клиентов? Оба сервиса держат инфраструктуру в США и частично в Европе. Для большинства западных компаний это нормально: у них есть SOC 2 Type II, стандартные DPA-соглашения, GDPR-ready архитектура. Но если вы работаете под российским ФЗ-152 или попадаете под требования ЦБ к банковской тайне, облако в Вирджинии или Франкфурте вам не поможет без дополнительных обходных схем, которые сами по себе создают новые риски.

n8n в self-hosted режиме закрывает эту проблему структурно. Вы ставите его на свой VPS или внутрь корпоративной сети, и данные физически не покидают ваш периметр. Никаких транзитных серверов, никаких внешних логов по умолчанию.

Из практики: бывают ситуации, когда compliance-требования прямо исключают Zapier и Make на этапе оценки безопасности. Причина: данные определённых типов (платёжные операции, медицинские записи, ПДн в чувствительных отраслях) не должны покидать внутреннюю сеть. В таких случаях n8n на приватном Kubernetes-кластере или выделенном VPS оказывается единственным рабочим вариантом среди трёх платформ.

Credentials в n8n шифруются через AES, ключ хранится локально у вас. Это означает, что даже если кто-то получит дамп базы, он не прочитает токены и пароли без вашего ключа. Но это же означает: потеряли ключ, потеряли доступ к секретам. Backup ключа шифрования нужно планировать сразу при деплое, не потом.

У n8n Cloud (их облачная версия) тоже есть SOC 2 Type II, как у Zapier и Make. Но если вы выбираете cloud-версию n8n ради безопасности, то вы теряете главное преимущество. Self-hosted означает, что ответственность за защиту данных лежит полностью на вашей команде: настройка сетевых политик, ротация ключей, контроль доступа, логирование. Это не сложно, но это работа, которую надо делать осознанно.

Self-hosted развёртывание оставляет все данные внутри корпоративного контура, но перекладывает ответственность за патчинг и мониторинг полностью на команду.

AI-возможности и работа с LLM-агентами

После добавления AI Agent ноды n8n из обычного workflow-движка превратился в оркестратор LangChain-сценариев. Под капотом так и есть LangChain.js: вы получаете chains, tools, memory, vector stores, всё прямо на канвасе. К агенту цепляете инструменты (HTTP-запрос, SQL, кастомная функция, другой workflow), даёте system prompt, и он сам решает, что вызывать. По глубине AI-интеграции n8n сейчас один из лидеров среди no-code платформ.

Make подтянулся в 2025: их AI Agents с визуальным конструктором промптов выглядят аккуратнее, чем у конкурентов. Перетаскиваете шаги рассуждения, видите, какие данные агент держит в контексте, удобно дебажить. Набор поддерживаемых моделей при этом закрытый: OpenAI, Anthropic, Google, ряд других крупных провайдеров. Подключить произвольную модель через свой эндпоинт там значительно сложнее.

Zapier пошёл дальше всех в маркетинге и меньше всех в технике. Zapier Central и Zapier Agents заточены под облачные сценарии с моделями от OpenAI и Anthropic. Глубокой оркестрации с памятью, кастомными инструментами и локальными моделями там нет.

Локальные модели нормально работают только в self-hosted n8n. Ollama для прототипов, vLLM для продакшена с батчингом, llama.cpp если совсем по-спартански. Подключение элементарное, через HTTP Request ноду или прямо из Function:

// n8n Function node: вызов локальной Ollama для классификации тикета
const response = await $http.request({
  method: 'POST',
  url: 'http://ollama:11434/api/generate',
  body: {
    model: 'llama3.1:8b',
    prompt: `Классифицируй обращение: ${$json.text}`,
    stream: false
  }
});
return [{ json: { category: response.data.response } }];

По деньгам есть момент, который маркетинг любой платформы прячет. Токены вы всегда платите LLM-провайдеру отдельно, платформа считает только свой overhead (выполнения, операции, активные агенты). И вот тут разница может быть большой.

Грубое сравнение для AI-сценариев с высокой нагрузкой: облачная платформа (Zapier или Make) к стоимости токенов добавляет стоимость своих операций, причём на агентских сценариях с много шагами это накручивает счёт ощутимо. Self-hosted n8n с открытым векторным хранилищем (Qdrant, pgvector) убирает overhead платформы целиком, оставляя только токены и стоимость сервера. На объёмных задачах разница в общем счёте может быть кратной.

Если заменить GPT-4o на Llama 3.1 70B в vLLM на арендованной A100, цена падает ещё сильнее, но появляется головная боль с latency и качеством на русском. Для FAQ-сценариев llama 3.1 8B хватает с запасом, для сложного reasoning я пока остаюсь на Claude Sonnet через API.

Локальный агент на Mistral 7B отвечает за 80 мс против 400 мс у GPT-4o через API, но проигрывает по качеству рассуждений на сложных задачах.

Надёжность и обработка ошибок

Zapier ведёт себя как инфраструктура, которую ты арендуешь: есть автоматические retry, сохранение логов на платных тарифах, задекларированный SLA. Звучит солидно. Но у любой облачной платформы бывают инциденты. Если твой бизнес-процесс ждал триггера от Stripe или HubSpot в момент даунтайма, ты это почувствовал.

Make решает проблему иначе. Там нет единой кнопки "повторить" по умолчанию: ты сам строишь логику обработки ошибок через error handler-ветки. Это гибко. Можно настроить разное поведение для таймаута, для 429-го ответа от API, для пустого массива в ответе. Но это требует, чтобы ты вообще эту логику написал. Много людей её не пишут, и сценарии просто молча падают.

С n8n self-hosted разговор другой. Надёжность установки равна надёжности твоего сервера. Без мониторинга, без бэкапов рабочих процессов, без настроенного автоперезапуска контейнера это может превратиться в головную боль. Я видел команды, у которых n8n тихо лежал два дня, потому что никто не следил за disk space.

Зато n8n с Redis-очередью горизонтально масштабируется и обрабатывает высокий параллелизм. Облачные платформы ограничивают одновременные задачи по тарифному плану, и на пиковых webhook-нагрузках лимит встречаешь быстро.

Вывод простой: хочешь минимальных усилий на поддержку и терпишь периодические инциденты на стороне вендора, Zapier справится. Хочешь контроля над логикой ошибок, Make интереснее. Хочешь контроля над инфраструктурой и готов её сопровождать, n8n.

Типичные сценарии среднего бизнеса и победитель в каждом

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

Синхронизация лидов amoCRM → email-рассылка + Slack. Берёт Make. Сценарий простой: вебхук из amoCRM, разветвление, в одну сторону Unisender или Mailchimp, в другую сообщение в канал отдела продаж. На умеренном объёме лидов Make заметно дешевле Zapier из-за модели "одна задача = один шаг", которая быстро съедает бюджет в Zapier. n8n тут избыточен, его сила в другом.

ETL из пяти источников в ClickHouse с трансформациями. Только n8n, без альтернатив. У меня типичная связка: PostgreSQL продакшена, MySQL легаси, Stripe, HubSpot и какой-нибудь S3 с CSV от партнёров. Внутри n8n я пишу нормальный JS в Code-нодах, делаю инкрементальные выгрузки по cursor, склеиваю, гоняю через дедуп и заливаю в ClickHouse батчами по 50к строк. Make задохнётся на трансформациях, у Zapier нет нормальной работы с ClickHouse и батчингом в принципе.

Уведомления продажникам в Telegram при изменении статуса сделки. Zapier, и тут спорить не о чём. Триггер на amoCRM, фильтр на нужные статусы, отправка в Telegram. Настройка занимает минут пятнадцать, включая тест. Make попросит чуть больше возни с роутером и iterator-ом, n8n потребует поднятого инстанса. Если у вас 2-3 таких сценария и больше ничего, поднимать сервер ради них смешно.

AI-обработка входящих писем с извлечением сущностей. n8n плюс локальная LLM, обычно Llama 3.1 70B или Qwen 2.5 через Ollama на отдельной машине с парой A6000. Письма идут с корпоративных адресов, там бывают договоры, паспортные данные, суммы. Гнать это в OpenAI через Zapier или Make я отказываюсь, и заказчики после короткого разговора с безопасниками тоже. В n8n собирается пайплайн: IMAP → парсинг вложений → промпт в локальную модель → валидация JSON-схемы → запись в Bitrix или 1С. Полный контроль, ничего не уходит наружу.

Бухгалтерская выгрузка из 1С в Google Sheets для руководства. Тут Make и n8n идут ноздря в ноздрю, выбирайте по тому, что уже стоит. Если в компании есть n8n под другие задачи, добавьте сюда же: коннектор к 1С через HTTP-запросы к опубликованному REST-сервису, агрегация, запись в Sheets раз в сутки. Если ничего нет и нужно быстро, Make с готовыми модулями Google Sheets и cron-триггером собирается за час. Цена сопоставима, надёжность тоже.

Онбординг нового сотрудника, восемь систем. Развилка по инфраструктуре. Чистый SaaS-стек (Google Workspace, Slack, Notion, Jira, 1Password, GitHub, Figma, Miro): Zapier, потому что у него готовые actions под каждый из этих сервисов с поддержкой SCIM-полей и приглашений по email. Собирается мультистеп Zap, HR заполняет форму, дальше всё едет само.

Если в стеке есть Active Directory или FreeIPA, картина другая. Zapier с локальным AD не дружит без костылей через Zapier Agents или платный middleware. n8n ставится в той же сети, ходит в AD по LDAP напрямую, создаёт пользователя, добавляет в группы, дёргает SaaS по API, отправляет приветственное письмо с временным паролем. У меня такой сценарий крутится в производственной компании на 400 человек, текучка средняя, пайплайн отрабатывает по 5-7 раз в неделю и не падал ни разу за последний год.

Стратегия выбора: гибрид вместо одной платформы

Я не видел компанию на 200 человек, которой хватало бы одного инструмента. Либо всё на Zapier и маркетинг счастлив, но годовые затраты высокие, либо всё на n8n и DevOps доволен, но маркетолог раз в неделю пишет в Slack "помогите починить воркфлоу". Обе ситуации я наблюдал. Обе плохие.

Рабочая схема выглядит так: Zapier или Make берёт на себя всё, что касается маркетинга и продаж. Синхронизация лидов из форм в CRM, уведомления в Slack при закрытии сделки, триггеры на email-кампании. Эти воркфлоу меняются часто, их правит маркетолог самостоятельно, и это нормально. Маркетолог должен иметь такую возможность.

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

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

Документация воркфлоу долж

Гибридная схема делит платформу на зоны: вендор управляет inference-слоем, а команда контролирует данные, промпты и политики доступа.