Три сервиса, три разных счётчика
Разобраться в расхождении поможет простая рамка: n8n, Zapier и Make измеряют одну и ту же работу принципиально разными способами.
n8n считает запуски сценария целиком — одно исполнение (execution), сколько бы шагов внутри ни было. Двухшаговый сценарий и двухсотшаговый агент потребляют одинаковое количество биллинговых единиц.
Zapier считает задачи (tasks) — каждое успешно выполненное действие внутри Zap. Триггеры при этом задачу не расходуют, но каждое action-действие — да. AI-шаги, вызовы через MCP, код — всё из того же пула задач, причём некоторые шаги могут потреблять больше одной задачи за раз.
Make перешёл на кредитную модель (credits), где разные типы шагов и операций стоят разное количество кредитов. AI-операции и сложные модули расходуют кредиты заметно быстрее обычных.
На первый взгляд — просто разные слова для одного и того же. На практике — принципиально разная экономика для длинных сценариев.
Как один сценарий превращается в разные суммы
Посмотрим на конкретную иллюстрацию. Разработчик, запускающий контентный пайплайн на самохостинговом n8n, промоделировал реальные рабочие процессы. Один из них — SF-2: webhook, запрос к базе данных, сборка промпта, вызов LLM, парсер, два узла с условиями, запись результата — итого 27 узлов в цепочке. Один запуск, один результат, одна биллинговая единица на n8n.
На task-based платформе те же 27 узлов — это 27 монет в счётчик при каждом запуске. Другой сценарий с 28 узлами при ежедневном запуске целиком исчерпывает квоту входного тарифа Zapier ($19.99/мес., 750 задач) примерно за 26 запусков в месяц. То есть один умеренно разветвлённый сценарий, запускаемый раз в день, съедает весь план.
Чтобы показать это наглядно, посмотрим на путь одного контентного объекта через цепочку автоматизаций:
flowchart TD A[Триггер: новый контент] --> B[Fetch из БД] B --> C[Сборка промпта] C --> D[Вызов LLM] D --> E[Парсер + условия] E --> F[Запись результата] F --> G[Публикация]
На execution-модели этот путь — 1 единица. На task-модели — каждый прямоугольник отдельная монета в счётчик. Чем длиннее цепочка, тем сильнее расходятся суммы.
Таблица: как одна автоматизация считается в разных моделях
| Характеристика | n8n (execution) | Zapier (task) | Make (credit) |
|---|---|---|---|
| Единица биллинга | Один запуск сценария целиком | Каждое выполненное action | Кредиты за каждый шаг/модуль |
| 27-шаговый сценарий, 1 запуск | 1 execution | ~27 tasks | ~27+ credits |
| 27-шаговый сценарий, 100 запусков | 100 executions | ~2 700 tasks | ~2 700+ credits |
| Эффект усложнения сценария | Нейтральный для биллинга | Линейный рост стоимости | Линейный или сильнее при AI-шагах |
| Триггер (polling) | Не считается отдельно | Не считается задачей | Считается операцией |
Таблица показывает структурный разрыв: при execution-модели добавление шагов в сценарий не меняет биллинговую единицу. При task- и credit-моделях каждый новый шаг — это новая статья расхода при каждом запуске.
Где расходятся масштабы: длинные сценарии и объём
Разница между моделями почти не заметна на простых двухшаговых автоматизациях. Она становится критической, когда сценарии длинные и запускаются часто.
Возьмём конкретные числа из смоделированного пайплайна: при 100 единицах контента в месяц через цепочку из 10 рабочих процессов с суммарно ~209 узлами получается около 1 000 n8n executions — это вписывается в Starter-тариф. На task-модели та же работа — около 20 900 задач, что находится значительно выше входного плана.
Это не маркетинговый тезис, это арифметика: 30-шаговый сценарий, запущенный 1 000 раз — 1 000 executions или 30 000 tasks. Разрыв не сокращается по мере роста, он растёт вместе с объёмом и сложностью.
Важно учитывать и особенность polling-сценариев. Если автоматизация периодически проверяет источник на наличие новых данных (скажем, каждые пять минут), сами проверки в Zapier задачу не расходуют — только успешное выполнение action. Но на Make операции могут считаться иначе, и частый polling быстро набегает в кредитах, особенно если каждую итерацию сопровождает хоть один реальный шаг.
Скрытые издержки самохостинга: бесплатного не бывает
Ситуация была бы простой, если бы n8n self-hosted действительно стоил ноль. Технически программная лицензия Community Edition бесплатна — но это не полная картина.
Самохостинг переносит расходы с подписки на инфраструктуру и операционную нагрузку. Сервер, база данных, настройка, мониторинг, бэкапы, обновления, отладка в неудобное время — всё это теперь ваша ответственность. Одни команды справляются с этим легко, для других это полноценная нагрузка на инженера.
Кроме того, у n8n есть несколько нюансов, которые легко недооценить:
- Вызовы подрабочих процессов, тестовые прогоны и автоматические повторные попытки — каждый из них считается отдельным execution. Реальное потребление может заметно отличаться от того, что вы рассчитали на «счастливом пути».
- Сложность порога вхождения: n8n предполагает комфорт с API, JSON и базовым JavaScript. Там, где Zapier с Copilot доведёт нетехнического пользователя до работающей автоматизации за час, n8n потребует больше времени и знаний.
- Лицензия Community Edition — fair-code, не OSI open source. Перепродавать её как собственный сервис нельзя.
Managed-тариф n8n (облачный хостинг от самой компании) убирает операционную нагрузку, но тогда сравнение с Zapier становится не таким однозначным: нужно считать реальную стоимость подписки, а не нулевую цену self-hosted варианта.
Когда какая модель работает в вашу пользу
Здесь нет универсального ответа, и честнее всего сформулировать его как вопрос о природе ваших сценариев.
Короткие и редкие автоматизации — форма → CRM → Slack, несколько шагов, несколько сотен запусков в месяц — вписываются в базовые тарифы любой платформы. В этом случае разница между моделями несущественна, а преимущества Zapier (скорость старта, Copilot, огромная библиотека интеграций) могут быть вполне реальным доводом в пользу именно этого инструмента.
Длинные и частые сценарии — многошаговые пайплайны, разветвлённая логика, регулярные запуски — начинают болезненно упираться в task- и credit-лимиты. Здесь структурное преимущество execution-модели наиболее выражено.
AI-шаги отдельно. И у Zapier, и у Make AI-операции потребляют квоту заметно быстрее обычных шагов. Если ваши сценарии насыщены вызовами LLM или сложными трансформациями, это меняет расчёт даже для коротких цепочек.
Главный практический вывод: прежде чем сравнивать тарифы, стоит замерить реальные параметры своей работы — сколько узлов в типичном сценарии, сколько раз он запускается в месяц, есть ли polling, ретраи, тестовые прогоны. Без этих цифр сравнение прайс-листов даёт ложное ощущение определённости.
Вопрос не «что дешевле», а «что бьёт по вам»
Выбор между n8n, Zapier и Make — это не рейтинг «лучших» и «худших». Это вопрос совпадения единицы тарификации с тем, как вы реально строите и запускаете автоматизации.
Execution-based модель структурно выгодна для длинных и часто запускаемых сценариев — но только если команда готова платить операционными затратами на самохостинг или ценой managed-подписки. Task- и credit-модели честны для простых автоматизаций и дают реальную ценность за счёт простоты входа и надёжности инфраструктуры.
Прежде чем делать выбор, стоит задать себе один вопрос: на что похожа моя типичная автоматизация — на короткую цепочку из трёх шагов или на разветвлённый пайплайн из тридцати? Ответ на него важнее любого сравнения фич на лендинге.
Дисклеймер. Расчёты в статье показывают порядок величин, а не универсальный прайс-лист. Для коротких и редких сценариев разница между платформами может быть несущественной. Если вы рассматриваете самохостинг, экономия на подписке не отменяет затрат на инфраструктуру и сопровождение — их стоит считать отдельно для своего кейса.
