Ключевые тезисы
- •Главный архитектурный водораздел — self-hosted vs cloud-only. Make — облачный SaaS в EU, n8n работает self-hosted в РФ. Это определяет применимость по 152-ФЗ
- •Любой воркфлоу с ПД российских граждан = n8n строго (Make передаёт данные в EU)
- •Make часто быстрее в первые недели — нативные интеграции, выше полировка UX. Через 12 месяцев экономика n8n выигрывает за счёт фиксированного CAPEX
- •JSON-экспорт + git для воркфлоу — главное операционное преимущество n8n на горизонте 12+ месяцев (code review, CI/CD, откатываемость)
- •Гибрид допустим: Make для публичных интеграций без ПД, n8n для всего что касается клиентских данных
«Какая платформа автоматизации лучше — n8n или Make» — это формально некорректный вопрос. У них разная модель развёртывания, разная архитектура, разная экономика и разные сценарии, в которых одна выигрывает у другой. Этот текст — про 12 параметров, по которым выбор реально отличается, и про четыре типичных PR-сценария с конкретным вердиктом для каждого. Все наши workflow-продукты Кельва — [Генератор медиакомментариев](/products/media-comment-generator), [Генератор кейсов](/products/case-study-generator), [Tender Docs App](/products/tender-docs-app) — построены на n8n, поэтому позиция понятная, но обоснование честное.
Что сравниваем и для кого
Сразу зафиксируем контекст — это сравнение для PR- и креативных агентств, не для энтерпрайз-ИТ. Что это значит:
- Команды 5-50 человек, бюджет на инструменты — десятки тысяч рублей в месяц, не сотни
- Воркфлоу — обработка медиа-запросов, генерация комментариев, подготовка кейсов, мониторинг упоминаний, синхронизация CRM
- Нет выделенной DevOps-команды; либо есть один tech-lead, либо вся техническая поддержка — на внешнего подрядчика
- 152-ФЗ — постоянный фон, особенно если в воркфлоу попадают клиентские данные
В этом контексте n8n и Make — два рабочих варианта. Каждый закрывает большинство сценариев, но архитектурные различия дают разные потолки и разную стоимость владения через 6-12 месяцев.
12 параметров сравнения
| # | Параметр | n8n | Make |
|---|---|---|---|
| 1 | Модель развёртывания | Self-hosted (Docker, Yandex Cloud) или Cloud | Только облачный SaaS (EU) |
| 2 | 152-ФЗ для воркфлоу с ПД клиентов | Закрывает (self-hosted в РФ) | Не закрывает — данные идут в EU |
| 3 | Биллинг | Per-execution на n8n.cloud / фиксированный на self-hosted | Per-operation (каждый шаг счётчик) |
| 4 | Стартовый порог входа | Выше — нужно поднять инстанс или развернуть Docker | Ниже — регистрация и сразу в редактор |
| 5 | Визуальный редактор для не-инженера | Хороший, но local-only без cloud-share | Лучше отполирован, нативно cloud-shared |
| 6 | Кастомные интеграции | Через HTTP-ноду + JS-код или собственная нода | Через HTTP-модуль + ограниченный inline JS |
| 7 | Версионирование воркфлоу | JSON export → git (наш паттерн) | Snapshot внутри платформы |
| 8 | Локальная разработка / тестирование | Полная — n8n запускается на ноутбуке | Никакая — только cloud |
| 9 | Лимиты на один воркфлоу | Практически нет (RAM/CPU инстанса) | Жёсткие на operations/min на тарифе |
| 10 | Webhook-эндпоинты | Свои домены + базовая auth | Свои домены (Make-домен), Bearer-токены |
| 11 | Лог-история | На self-hosted — сколько вместит диск | 7-30 дней в зависимости от тарифа |
| 12 | Vendor-lock-in | Низкий (JSON-экспорт, open-source ядро) | Высокий (snapshots внутри платформы) |
Главный архитектурный водораздел — пункт 1-2 (self-hosted vs cloud) и пункт 12 (vendor-lock-in). Всё остальное — оттенки. Если ваши воркфлоу касаются ПД клиентов или вы хотите гарантию миграции, n8n. Если ни ПД ни долгосрочной миграции — Make часто быстрее в первые месяцы.
Четыре типичных сценария
Сравнения «на бумаге» полезны, но решения принимаются на конкретных задачах. Четыре сценария, в которых мы видели обе платформы в работе, и вердикт по каждому.
Сценарий 1. Мониторинг упоминаний клиента в СМИ
Берём список ключевых слов, опрашиваем агрегатор (Brand Analytics, Медиалогия, Babkee), фильтруем релевантные, отправляем в Telegram-канал клиента и/или в Notion.
Что считается: Цикл — 4-6 раз в сутки. Данные — публичные упоминания, не ПД. Объём — десятки-сотни упоминаний в день.
Make лучше. Просто потому, что воркфлоу типовой, ПД нет, и Make имеет нативные интеграции с большинством агрегаторов из коробки. Стартовая стоимость и время до production меньше.
n8n работает. Если у вас уже стоит инфраструктура n8n для других воркфлоу, добавить ещё один — тривиально.
Сценарий 2. Генерация комментариев спикеров для медиа
Запрос пришёл от издания → собрать контекст по теме → подобрать спикера → подготовить черновик комментария с цитатой → согласовать с спикером → отправить редактору.
Что считается: Цикл — несколько раз в неделю. Данные — имя спикера, его компания, должность, цитаты (всё это ПД сотрудника + ПД клиента в зависимости от компании). Объём — 10-30 комментариев в неделю на крупное агентство.
n8n строго. Промпт с именем спикера, его должностью и компанией — обработка ПД. Передача в Make означает обработку в EU, что под 152-ФЗ нарушение. n8n self-hosted на Yandex Cloud закрывает требование. Это не «n8n удобнее», это «Make юридически нельзя».
Это сценарий, под который мы делали Генератор медиакомментариев — внутри n8n воркфлоу, с подключённой LLM на YandexGPT API.
Сценарий 3. Синхронизация HubSpot ↔ Notion ↔ Slack для команды продаж
Лид завёлся в HubSpot → создать соответствующую страницу в Notion с шаблоном → уведомить ответственного в Slack-канале → обновлять статус по жизненному циклу.
Что считается: Цикл — десятки лидов в неделю. Данные — контактные данные лидов (ПД). Объём — небольшой.
Make лучше. Нативные интеграции HubSpot, Notion, Slack отлично отлажены. Стартовая стоимость минимальная. Но: ПД лидов в Make означает их передачу в EU. Для российской B2B-компании это либо нарушение 152-ФЗ (если лиды — российские граждане), либо допустимо (если лиды только из EU). Решение зависит от целевого рынка.
n8n правильнее для смешанной аудитории. Если ваши лиды — российские и зарубежные одновременно, n8n self-hosted закрывает оба периметра. Универсальное решение, выше входной порог.
Сценарий 4. Подготовка большого кейса агентства с AI
Источники — emails, транскрипты звонков, заметки команды, материалы клиента. Собрать в один документ. Прогнать через LLM для генерации сторителлинга. Привести в формат Google Docs. Отдать редактору.
Что считается: Цикл — 2-4 раза в месяц. Данные — конфиденциальные материалы клиента, потенциально с ПД. Объём — большой по объёму одного workflow run (десятки источников, тысячи токенов в промпте).
n8n единственный вариант. В Make материалы клиента нельзя отправлять — раз. Объём операций на один run приближается к лимитам Make-тарифов — два. Гибкость в составлении промптов и обработке источников у n8n существенно больше — три.
Это сценарий, под который мы делали Генератор кейсов — n8n + self-hosted LLM или YandexGPT API, всё внутри российского периметра.
Когда Make — правильный выбор
Чтобы заявление «всегда n8n» не звучало предвзято — три сценария, где Make объективно лучше:
- Простая интеграция между 2-3 публичными SaaS без ПД клиентов. Skipping Make ради n8n в этих сценариях — это over-engineering, который тратит время команды на инфраструктуру, не на продукт.
- Команда без любого технического сопровождения. Make имеет более полированный UX и меньше edge-cases требующих CLI. Если внутри агентства некому поднять Docker-контейнер, n8n превратится в риск.
- Прототипирование — попробовать гипотезу на 2-3 неделях. Спин-ап на Make быстрее. Перенос работающего прототипа на n8n позже — стандартная процедура.
В этих случаях советовать клиенту n8n из-за «суверенности и self-hosting» — это симуляция консультанта, не реальная польза.
Когда n8n единственный путь
И обратные случаи — когда Make нельзя:
- Любой воркфлоу с ПД российских граждан. Здесь нет дискуссии — Make передаёт данные в EU, что под 152-ФЗ требует согласия и часто формально не закрывается.
- Контракт с госзаказчиком или регулируемым сектором. Большинство тендеров фиксируют требование локализации обработки на сертифицированной инфраструктуре. Make не проходит.
- Долгосрочный продукт с продаваемым доступом (white-label воркфлоу для клиентов агентства). Vendor-lock-in Make означает риск повышения цен / изменения политик в будущем. n8n под Apache-license даёт независимость.
- Воркфлоу с большим объёмом операций на один run. Make-тарифы лимитируют operations/min — большой батч обработки данных упрётся в потолок.
Стоимость владения через 12 месяцев
Сравнение по single-payment стартовой стоимости вводит в заблуждение. Через 12 месяцев картина выглядит иначе.
Make. Тариф уровня Pro — порядка $40-150 в месяц в зависимости от operations limit. Условный B2B-агентский воркфлоу на 2-5 миллионов operations в месяц стоит порядка $100-300/мес. За год — $1200-3600.
n8n self-hosted на Yandex Cloud. Инстанс standard-v3-2cpu-4gb — порядка 2000 руб/мес ($20). Плюс managed PostgreSQL — ещё 1500 руб/мес. Итого порядка 3500 руб/мес ($35), independent of operations volume. За год — $420.
n8n self-hosted с GPU для встроенной LLM. Если на той же машине крутится локальная Qwen — добавляется GPU-инстанс ($1000-1500/мес). Но тогда вы экономите на per-token LLM-биллинге.
Главная разница не в долларах, а в предсказуемости. n8n — фиксированный CAPEX. Make — линейная функция от использования с непредсказуемой границей.
Архитектурное следствие — про vendor-portability
Один из главных аргументов в пользу n8n у нас — JSON-экспорт воркфлоу и хранение в git. Это даёт три выигрыша:
- Code review воркфлоу. Pull request с изменением workflow.json виден в git diff, обсуждается командой. Make snapshots — внутри платформы, не cross-team.
- CI/CD для воркфлоу. Мы запускаем тест-run воркфлоу при PR на staging-инстансе n8n, потом deploy на prod. Make таких возможностей не даёт.
- Откатываемость. Сломанный воркфлоу = git revert. На Make — восстановление из snapshot вручную, в зависимости от тарифа сохраняется 7-30 дней.
Для небольших агентств эти три выигрыша звучат как over-engineering. Но через 12 месяцев работы с 10-20 production-воркфлоу разница становится критической — git-based pipeline даёт коллективный контроль качества, чего Make-only setup структурно не позволяет.
Закрыть выбор инструмента осознанно
Если вы оцениваете автоматизацию для агентства и стоите перед выбором между Make и n8n — поговорим. Мы пройдём по конкретным сценариям вашей команды и предложим архитектуру, которая работает в долгую: где можно начать с Make для скорости, где сразу нужен n8n, где имеет смысл гибрид.
