n8n или Make: что лучше для процесса и как проверить выбор

Если система A уже создала запись, а система B не отправила уведомление, повтор всего маршрута может создать дубль. Поэтому n8n и Make нельзя сравнивать только по редактору, количеству блоков или каталогу приложений.

Сначала задайте один процесс, одинаковые входы и ожидаемый результат. Затем сравните размещение, права, журнал, частичный сбой и цену повторов. Ниже — синтетический пример и протокол будущей проверки, а не live-тест платформ или результат клиентского внедрения Switch On AI.

Какие решения сравниваем и для какой задачи

Возьмём процесс «обращение → запись A → уведомление B». На вход поступают синтетические поля: event_id, имя, контакт, текст обращения и время события.

Маршрут должен:

1. проверить обязательные поля;
2. атомарно создать или прочитать запись event_id; для состояния new либо pending_b получить новую или продлённую аренду обработки — lease;
3. разрешить дальнейшее действие только владельцу действующей lease;
4. для new создать A либо найти ранее созданную A по идемпотентному ключу;
5. после подтверждения A сохранить external_a_id и состояние pending_b;
6. для pending_b вызвать только B;
7. после подтверждения B сохранить состояние completed.

Таблица прокручивается по горизонтали.

Проигравший конкурентный запуск не вызывает A. Он останавливается либо читает состояние после завершения владельца. Обычная последовательность «сначала поиск, затем создание» этого не гарантирует: два запуска могут одновременно ничего не найти.

Если lease в состоянии new истекла, восстановитель сначала ищет A по идемпотентному ключу. Найденную A не создают заново: сохраняют её внешний ID, переводят событие в pending_b и продолжают с B. Если A не поддерживает такой ключ или поиск, отсутствие дубля обещать нельзя.

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

Когда подходит n8n

Сведения ниже относятся к официальной документации и тарифному срезу n8n от 30 сентября 2026 года. Это разбор документированных возможностей, а не заявление о личном запуске.

n8n описывает workflow как набор соединённых узлов. Документация предусматривает создание, запуск и публикацию workflow, работу с версиями и credentials, а также просмотр, фильтрацию и отладку executions. Наличие подходящих узлов A и B либо нужных методов HTTP API проверяют отдельно.

Для размещения доступны n8n Cloud и self-hosted. Self-hosted можно развернуть на собственной инфраструктуре, on-premises или в частном облаке. В этом варианте проект должен назначить ответственных за обновления, базу данных, резервные копии, мониторинг, журналы и восстановление. Для Cloud распределение обязанностей сверяют с условиями выбранного плана.

Code node выполняет JavaScript или Python. В n8n Cloud нельзя импортировать произвольные внешние npm-модули; документация называет доступными для JavaScript crypto и moment. Python в Cloud также не позволяет импортировать библиотеки стандартной поставки или сторонние пакеты. В self-hosted внешние JavaScript-модули можно разрешить настройкой, а native Python в n8n 2 поддерживает явно добавленные и разрешённые зависимости через task runners. Поэтому возможность писать код нужно уточнять редакцией, версией и размещением.

Проектные роли доступны на всех планах n8n Cloud, а также в зарегистрированных self-hosted Community, Business и Enterprise. Пользователь может иметь разные роли в разных проектах. Пользовательские роли уровня экземпляра и проекта доступны в Enterprise. Точный набор прав выбранного плана включают в приёмку.

Community edition относится к self-hosted и работает по Sustainable Use License. Официальный FAQ разрешает внутреннее использование, создание и сопровождение workflow для клиентов и платные консультации, если клиенты не получают возможность создавать или изменять workflow в экземпляре исполнителя. Нельзя предоставлять размещённый n8n как конструктор, в котором внешние пользователи управляют логикой, или использовать функции Enterprise без соответствующей лицензии. Пограничную архитектуру нужно согласовать с правообладателем; статья не заменяет юридическую оценку.

Для тарифного сравнения выбран n8n Cloud Starter по срезу 30 сентября 2026 года: 20 € в месяц при годовой оплате, 2500 workflow executions, неограниченное число шагов внутри исполнения, 5 параллельных executions, один общий проект и неограниченное число пользователей. Тарифицируется полный запуск workflow, а не каждый шаг. На странице также указаны 2500 сохранённых executions, 2,5 ГБ хранения и журнал до 7 дней. Старые записи удаляются при достижении первого ограничения. Условия превышения Starter в полученном тексте не раскрыты, поэтому их проверяют перед оплатой.

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

Когда подходит Make

Сведения относятся к официальной справке и тарифному срезу Make от 30 сентября 2026 года. Автор не заявляет, что запускал описанный scenario.

Make называет автоматизированный маршрут scenario, а его блоки — modules. Standard scenario следует фиксированным правилам и подходит как модель для учебного процесса без ИИ. Router разделяет поток на последовательные ветви по фильтрам; fallback-ветвь принимает данные, не подошедшие под другие условия.

Учебная карта выглядит так:

1. триггер принимает событие;
2. хранилище атомарно создаёт или читает event_id и выдаёт lease;
3. Router разводит состояния invalid, new, pending_b и completed;
4. владелец new вызывает или находит A, затем сохраняет external_a_id и pending_b;
5. владелец pending_b вызывает только B;
6. подтверждение B переводит событие в completed.

Это схема для проверки, а не обещание готовых коннекторов. Наличие приложений A и B, методов HTTP и атомарного хранилища подтверждают для конкретной реализации.

Для ошибок Make предлагает обработчики и incomplete executions. Последние отключены по умолчанию. После включения незавершённый запуск можно повторить автоматически для поддерживаемых ошибок, обработать Retry error handler, разрешить вручную или удалить. Максимальное число incomplete executions зависит от allowance плана, но полученный срез не сообщает его значение.

Scenario settings позволяют обрабатывать данные последовательно, хранить incomplete executions, выбирать фиксацию после каждого модуля и скрывать полезную нагрузку из журнала через Keep data confidential. Скрытие данных ограничивает диагностику. Если хранилище incomplete executions заполнено и включено отбрасывание аварийных данных, удалённые данные восстановить нельзя.

Make хранит сценарии, пользователей и данные внутри организации. При создании организации выбирают обработку и хранение в дата-центре США или ЕС; изменить регион после создания нельзя. Документация перечисляет роли Owner, Admin, Member, Accountant, App Developer и Guest. Доступ к командным ресурсам дополнительно зависит от командной роли и плана.

On-premise agent доступен Enterprise-клиентам и даёт облачному сценарию доступ к API локальной сети через HTTP Agent. Это не подтверждает полное локальное размещение Make или всех данных.

Для сравнения выбран Teams из тарифного среза 30 сентября 2026 года: отображено 29 долларов при объёме 10 000 credits, минимальный интервал планового запуска — 1 минута, максимальная длительность scenario — 40 минут, история — 30 дней; план содержит командные роли. Текстовое извлечение не установило положение переключателя monthly/annually, поэтому 29 долларов нельзя считать окончательной ценой конкретного периода.

Единица расхода Make — credit. Для большинства приложений одно обычное выполнение module соответствует одной operation и одному credit. Расход некоторых функций, особенно встроенных возможностей ИИ, зависит от токенов, размера файла, страниц или времени. Ошибку и повтор считают по фактической реализации и отчёту потребления.

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

Когда рассмотреть Zapier, Albato или Airflow

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

Тарифная единица Zapier — task: обычный успешно выполненный action использует одну task. Trigger, Filter, Paths, остановленные и завершившиеся ошибкой actions обычно не учитываются как tasks. При полном replay ранее успешные actions, выполненные заново, снова учитываются. Поэтому точечный повтор B и повтор всего Zap могут дать разный расход. Цена, лимит, роли, глубина истории и способ восстановления pending_b требуют проверки для выбранного плана.

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

Apache Airflow 3.3.2 — иной класс решения. Официальная stable-документация определяет его как платформу для разработки, планирования и мониторинга пакетно-ориентированных workflow, включая временные и событийно запускаемые конвейеры данных. Workflow задаются кодом на Python, а задачи образуют Dag с расписанием и зависимостями. Airflow позволяет повторно запускать отдельные неудачные задачи и обрабатывать исторические периоды.

Airflow рассматривают для зависимых конвейеров данных, машинного обучения и других процессов с ясным началом, концом и графом задач. Его не следует оценивать как прямую замену событийному маршруту между A и B только потому, что оба решения используют слово workflow.

Как сравнить возможности и расходы

Тарифный срез зафиксирован на 30 сентября 2026 года. Для n8n выбран Cloud Starter, для Make — Teams. Zapier не получает денежной оценки, пока не подтверждён план: известны правила tasks, но не цена и лимит. Такая строка означает «кандидат пока не прошёл ценовой фильтр», а не нулевую стоимость.

Таблица прокручивается по горизонтали.

Размещение и доступы

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

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

Операции, тарифные ограничения и повторы

Синтетическая выборка содержит 1000 входящих подач за один период. Из них 50 повторяют завершённые event_id, а 950 имеют новые уникальные идентификаторы. Двадцать ошибок B входят в эти 950 новых событий.

Карта первого прохода:

• 1000 проверок входа;
• 1000 атомарных чтений или захватов состояния;
• для 950 новых событий — 950 вызовов A;
• 950 записей pending_b;
• 950 первых вызовов B;
• после 930 успешных первых вызовов B — 930 записей completed.

Первый проход содержит 1000 + 1000 + 950 + 950 + 950 + 930 = 5780 прикладных действий.

При точечном восстановлении добавляются 20 вызовов B и 20 записей completed: 5780 + 20 + 20 = 5820 действий.

При повторе от входа каждое из 20 событий снова выполняет проверку, чтение состояния, B и запись completed: 5780 + 20 × 4 = 5860 действий. Разница между способами восстановления — 40 действий.

A вызывается 950 раз. B вызывается 970 раз: 950 первых попыток и 20 повторов. После восстановления ожидаются 950 подтверждённых A и 950 подтверждённых B.

Прикладное действие не равно тарифной единице автоматически. Для n8n вариант «1000 входных workflow и 20 отдельных восстановительных запусков» даёт 1020 executions, только если каждый вход создаёт одно исполнение, а каждое восстановление B запускает отдельный workflow execution. Если повтор B происходит внутри исходного execution средствами обработки ошибок, число executions может отличаться. Внутренние 5820 действий не меняют тарифный счёт n8n, пока остаются внутри указанных исполнений.

Полная синтетическая карта содержит 5820 прикладных действий при точечном восстановлении, но это не число credits Make. Credits можно определить только после сопоставления каждого действия с конкретным module и отчётом потребления. Router, фильтры, триггер и внутренние функции учитывают по фактической реализации.

Для Zapier нижняя граница двух внешних успешных действий составляет 950 A + 950 B = 1900 tasks. Двадцать неуспешных попыток B в этот минимум не входят по полученной справке. Чтение и запись состояния, поиск A и отдельный replay могут добавить tasks, поэтому 1900 — не оценка всего Zap.

Это расчётная модель, а не измерение платформ. Денежное сравнение завершается после построения реализаций и составления карты «прикладное действие → execution, credit или task».

Как платформы переживают сбои и повтор

Синтетическое событие lead-demo-017 попадает в pending_b: система A подтвердила запись, а система B не подтвердила уведомление.

Частично выполненная операция

Таблица прокручивается по горизонтали.

Первое аварийное окно возникает, если A выполнила действие, но процесс упал до сохранения внешнего ID. После истечения lease восстановитель ищет A по переданному идемпотентному ключу. Если A найдена, он сохраняет external_a_id, переводит запись в pending_b и не создаёт A повторно. Если A не поддерживает такой поиск или ключ, отсутствие дубля гарантировать нельзя.

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

Восстановление без повторной записи

Протокол будущего теста включает:

• новое корректное событие;
• повтор события в completed;
• событие без контакта;
• сбой B после подтверждённой A;
• потерю ответа A до сохранения ID;
• потерю ответа B после действия;
• изолированную конкурентную выборку.

Конкурентная выборка содержит 10 новых уникальных event_id. Каждый идентификатор подают одновременно дважды: всего 20 подач. При доступных A и хранилище ожидаются ровно 10 созданий A — не более одного на идентификатор. Десять проигравших захватов A не вызывают. Если отдельно вводится отказ A, критерий меняют на «не более 10», чтобы сбой внешней системы не маскировал ошибку конкурентной защиты.

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

Если нужен подбор и реализация аналогичного процесса, можно сравнить направления услуг Switch On AI. Состав подключения и проверки определяют по вашим системам, правам и обезличенным примерам.

Как выбрать и спланировать перенос

На вопрос «n8n или Make — что лучше» отвечает заполненная матрица процесса, а не общий рейтинг.

Таблица прокручивается по горизонтали.

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

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

Что подготовить для обсуждения интеграции

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

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

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