n8n против Make: что выгоднее и когда

MAATRIX

Спор «n8n или Make» упирается не в удобство редактора, а в арифметику: Make берёт деньги за каждое срабатывание каждого модуля, n8n на своём сервере — только за сервер. Ниже — подсчёт на живом сценарии, список задач, где Make честно лучше, и что стоит переезд.

Операция в Make и выполнение в n8n — разные единицы

Make считает операции. Одна операция — один запуск одного модуля над одним бандлом данных. Правила, которые застают врасплох:

• Каждый модуль тратит операцию на каждый элемент, который через него прошёл. Двадцать заказов через четыре модуля — восемьдесят операций, а не четыре.
• Модуль поиска, вернувший ноль результатов, всё равно списывает операцию.
• Роутеры и фильтры бесплатны, операций не тратят.
• Iterator и Aggregator стоят по одной операции, но всё между ними умножается на число бандлов.
• Упавшее выполнение ничего не возвращает: сгоревшие до ошибки операции списаны. Плюс отдельная квота на объём переданных данных.

n8n считает иначе. В облаке единица — выполнение: один запуск сценария целиком, сколько бы в нём ни было нод и элементов. Тот же сценарий с двадцатью заказами — одно выполнение, а не восемьдесят две операции. А на своём сервере не считается ничего: community-редакция не ограничивает ни число активных сценариев, ни число запусков.

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

Считаем деньги на живом сценарии

Типовая задача: каждые 15 минут забрать новые заказы, найти клиента в CRM, обогатить по HTTP, записать в Google Sheets, отправить в Telegram. Пачка — 20 заказов.

96 запусков в сутки — это 7 872 операции в день и около 236 000 операций в месяц. Тот же сценарий в n8n — 2 880 выполнений в месяц. Единицы отличаются в восемьдесят два раза, и в этом вся суть спора.

Порядок цен на начало 2026 года (тарифы меняются, но кривая линейная):

Счёт за свой сервер в этой таблице не меняется ни на строчку. Бесплатный тариф Make — 1 000 операций, два сценария и интервал от 15 минут: песочница, не инструмент. n8n Cloud считает выполнения: порядка €24/мес за 2 500 выполнений и 5 активных сценариев, €60/мес за 10 000 и 15.

Где точка равновесия. По голым счетам VPS под n8n отбивается уже на 15–20 тысячах операций Make. Но счёт нечестный: сервер требует час-два в месяц на обновление образа, размер базы и проверку бэкапа. Если ваш час стоит 3 000 ₽, это ещё 3–6 тысяч сверху, и точка равновесия уезжает к 60–100 тысячам операций.

Где Make честно выигрывает

Готовые коннекторы. У Make порядка двух тысяч приложений, у n8n — несколько сотен нативных нод. HTTP Request-нода закрывает любой REST API, но авторизацию, пагинацию и разбор ответа вы пишете руками. Нишевые SaaS в Make, скорее всего, уже готовы.

Чужое проверенное OAuth-приложение. Самый недооценённый пункт. В self-hosted n8n вы заводите своё: проект в Google Cloud Console, включённый API, экран согласия, OAuth client ID типа Web application и строго такой redirect URI:

https://n8n.example.com/rest/oauth2-credential/callback

Дальше грабля, на которую наступают все. Если оставить приложение в статусе Testing, refresh-токен живёт семь дней: неделю всё работает, а на восьмой день Gmail-нода падает:

invalid_grant: Token has been expired or revoked.

Лечится не в n8n, а в консоли Google: перевести приложение в Production. Для чувствительных скоупов вроде https://www.googleapis.com/auth/gmail.modify придётся пройти верификацию — подтверждённый домен, политика конфиденциальности на нём, демо-видео; от нескольких дней до нескольких недель. Исключение — Workspace с типом пользователя Internal. В Make вы просто жмёте «Sign in with Google»: их приложение проверено один раз на всех.

Доигрывание упавших запусков. Make складывает сорванные выполнения в отдельную очередь, откуда их можно починить и доиграть — например, упавшие из-за пятиминутной недоступности API. В n8n аналога нет: есть Retry On Fail, Continue On Fail и Error Workflow, но не продолжение с места падения.

Аптайм не ваша забота. Если VPS уходит в ребут в три ночи, вебхуки не доходят и никто их не повторит. У Make за это отвечает дежурная смена.

Где выигрывает n8n на своём сервере

Циклы бесплатны. Главный аргумент: список из 5 000 элементов проходит через десять нод и остаётся одним выполнением.

Свой код в сценарии. Code-нода выполняет полноценный JavaScript и Python через Pyodide. Внешние npm-библиотеки заблокированы по умолчанию и включаются переменной вида NODE_FUNCTION_ALLOW_EXTERNAL=cheerio,luxon — иначе Cannot find module 'cheerio'. В Make произвольный код выполнить нельзя: только IML-функции.

Расписание и таймауты без потолка. Schedule Trigger принимает cron вплоть до секунд: */30 * * * * * — дважды в минуту. Make на платных тарифах даёт минимум минуту, на бесплатном — 15. Так же с длительностью: у Make потолок на одно выполнение порядка 40 минут, у вас он задаётся EXECUTIONS_TIMEOUT=7200.

Статический исходящий IP. Make ходит к вашим API из общего пула адресов, который меняется. Свой сервер — один белый IP для вайтлиста банковского API, фаервола или CRM: для интеграций с ограничением по адресу это разница между «работает» и «невозможно».

Данные не покидают периметр. Токены к почте, CRM и платёжкам, персданные и переписка лежат у вас, зашифрованные вашим N8N_ENCRYPTION_KEY, а сценарий — обычный JSON, который кладётся в git.

ИИ и локальные модели. Нативные ноды AI Agent, векторные хранилища, Ollama рядом на том же сервере — без оплаты токенов наружу. Подробности — в материале про n8n с AI-агентами.

Скрытая цена своего сервера

Лицензия — не совсем open source. n8n идёт под Sustainable Use License: fair-code, а не OSI-лицензия. Пользоваться внутри компании и делать автоматизации клиентам — бесплатно. Продавать доступ к своему n8n как сервис третьим лицам, тем более под своим брендом, без коммерческой лицензии нельзя: для агентства, собиравшегося сделать «свой Make», это стоп-фактор.

Community-редакция умеет не всё. SSO/SAML и LDAP, проекты с ролевым доступом, версионирование окружений, внешние секреты (Vault, AWS Secrets Manager), стриминг логов, multi-main для отказоустойчивости — платные редакции.

Ресурсы под нагрузкой. Замер на 2 vCPU / 4 ГБ, стек в простое:

$ docker stats --no-stream
NAME       CPU %   MEM USAGE / LIMIT
n8n        0.42%   564MiB / 3.83GiB
postgres   0.11%   129MiB / 3.83GiB
caddy      0.00%    17MiB / 3.83GiB

Около 710 МБ в покое. Сценарий, который тянет 5 000 элементов через Code-ноду, поднимает n8n до 1,3–1,4 ГБ: движок держит в памяти вход и выход каждой ноды, а не только текущий шаг. Прикидка: 700 МБ плюс примерно трёхкратный объём самого «широкого» набора данных на каждое параллельное выполнение. Детали — сколько RAM нужно для n8n.

Обслуживание. Раз в месяц обновить образ (закрепляйте тег вида n8nio/n8n:1.114.4, а не latest: минорные версии выходят почти еженедельно), следить за размером базы, держать снапшот тома и отдельно сохранённый N8N_ENCRYPTION_KEY — потеряете ключ, и все креды заводятся заново вместе с OAuth-приложениями. Типовые грабли — в разборе частых ошибок n8n. И никакого SLA.

Кому что и как переезжать без потерь

Автоконвертера из Make в n8n нет: blueprint Make и workflow n8n — принципиально разные схемы. Сроки ручного переноса: простой сценарий из пяти-восьми модулей — 20–40 минут, с роутерами, итераторами и обработкой ошибок — 2–4 часа. На портфель из тридцати сценариев закладывайте неделю.

Что ломает голову при переносе:

• Бандлы против элементов. В Make вы мыслите одним бандлом за раз, отсюда Iterator. В n8n нода получает массив items и обрабатывает их все сразу: половина итераторов при переносе исчезает, вторая превращается в Split Out.
• Роутер. Его ветки в Make получают копию данных и идут параллельно. Аналоги в n8n — Switch и IF, но семантика другая, и вложенные роутеры быстрее перерисовать, чем переносить один в один.
• Data store. Встроенного хранилища «между запусками» в community-редакции нет. Замена — $getWorkflowStaticData('global') в Code-ноде: объект переживает выполнения и хранится вместе со сценарием. Минусы честные — он не сохраняется при ручном тестовом запуске и не годится под большие объёмы.
• Креды не переносятся. Все токены и OAuth-приложения заводятся заново, руками, включая описанную выше возню с Google.

Порядок переезда, который не ломает бизнес: поднять n8n рядом, перенести один некритичный сценарий, месяц подержать оба, потом остальное. Не выключайте Make, пока не отработал полный месячный цикл, — иначе выяснится, что отчёт собирал сценарий, о котором все забыли.

Ещё один аргумент, который в 2026 году часто и решает вопрос, — оплата. Make принимает карты, выпущенные за пределами РФ, и PayPal; российская карта на его чекауте не проходит. У n8n Cloud та же история: Stripe и евро. Посреднические карты работают до первого риск-скоринга, а блокировка аккаунта — потеря всех сценариев вместе с историей выполнений. Self-hosted снимает вопрос: вы платите только за сервер — картой из России или криптой.

Какой сервер под n8n взять в MAATRIX

Пересчитайте нагрузку честно. Сценарий из второй секции — 236 000 операций Make в месяц — это 2 880 выполнений n8n, то есть 4 запуска в минуту в пике. По процессору ничто: на 2 vCPU загрузка держится в единицах процентов. Упрётесь вы в память, а она зависит не от числа запусков, а от ширины набора данных.

Минимум под переезд с Make: 2 vCPU, 4 ГБ RAM, 40 ГБ NVMe. Хватает на 10–30 активных сценариев с пачками до нескольких тысяч элементов. Меньше не стоит: 710 МБ уходит на стек в покое, и первое же выполнение с широкой выборкой на двух гигабайтах заканчивается тем, что контейнер убивает OOM-killer.

Комфортная конфигурация: 4 vCPU, 8 ГБ RAM, 80 ГБ NVMe. Нужна, если выполнений больше 10 000 в месяц, есть ИИ-ноды или обработка файлов и вы хотите режим очереди с Redis — тогда пик не тормозит редактор.

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

По локации логичен UK, Лондон: большинство SaaS-API, к которым ходили ваши сценарии, живут в Европе, из Лондона до них 15–35 мс — по задержкам вы остаётесь в привычном контуре. Плюс GDPR-периметр для клиентов из ЕС и статический белый IP вместо пула Make. Если основная нагрузка — зарубежные ИИ-сервисы, берите US, Нью-Йорк: чистые IP и прямой доступ. Если через сценарии идут персданные россиян и вы работаете по 152-ФЗ — только RU.

Сервер выдаётся с root-доступом и статическим IP, оплата — картой российского банка, по СБП, криптой или токеном MAAT. Не уверены, окупится ли переезд, — посчитайте операции в Make за месяц: если цифра ниже 40 тысяч, честнее пока остаться на Make.

Частые вопросы