Оркестрация без n8n: когда своя архитектура выходит дешевле конструктора

n8n в июле 2026-го поднял $180 млн серии C под тезис «приблизить ИИ к ценности через оркестрацию». Инструмент действительно хороший, и я сам ставил его первым выбором в отчёте по одному проекту. А потом убрал из стека. Ниже — почему так вышло и в какой момент своя архитектура становится дешевле готового конструктора.

Что обещает конструктор

n8n продаёт скорость для соло-билдера. Ты собираешь пайплайн мышкой: вот триггер, вот HTTP-запрос, вот ветвление, вот запись в базу. Не пишешь бойлерплейт, видишь поток данных глазами, дебажишь по нодам. Для типового сценария вроде «пришло письмо → достали вложение → положили в таблицу → уведомили в чат» это честная экономия дней.

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

Где обещание рассыпается

Мой проект — аналитика и закупка рекламы в Telegram и VK. Ключевые источники: TGStat, Telemetr.io, Telega.in, TeleTarget, маркет-платформа VK и ОРД для маркировки. Я проверил каждый: готовых нод n8n под них нет. Ни одной.

Это значит, что весь код интеграций я всё равно пишу руками — в Code-нодах n8n. HTTP-запросы, разбор ответов, обработка ошибок API, лимиты — всё моё. n8n в этой картине добавляет ровно две вещи: UI-обёртку вокруг моего же кода и ещё один сервис на VPS, который надо обновлять, бэкапить и чинить.

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

Чем заменил

Вместо n8n собрал тонкий Python-оркестратор. Ядро — стейт-машина на Postgres: таблица с задачами, статусами и попытками. Крутится persistent-цикл, который забирает задачи, гоняет их через код интеграций и двигает по статусам. Всё это в Docker Compose рядом с базой.

Логика простая:

• Postgres как источник правды. Состояние каждой задачи лежит в строке таблицы. Упал контейнер — после рестарта цикл поднимает незавершённые задачи по статусу. Отдельного стейт-стора не нужно, база уже есть.
• Оркестратор тонкий. Его работа — доставать задачу, вызывать нужный обработчик, ловить ошибки, ставить следующий статус. Никакой бизнес-логики внутри, только диспетчеризация.
• Интеграции — обычные функции. Тот же HTTP-код, который лёг бы в Code-ноды, живёт как питоновские модули. Тестируется юнит-тестами, версионируется в git, переиспользуется между задачами.

По строкам кода это сопоставимо с тем, что я всё равно написал бы внутри n8n. Разница в том, что с VPS уходит целый сервис, а состояние процесса я вижу простым SQL-запросом к таблице задач.

Когда конструктор всё же выигрывает

Я не против n8n. Он остаётся сильным выбором, и я вернул бы его в трёх случаях:

1. Под твои сервисы есть готовые ноды. Gmail, Slack, Google Sheets, популярные CRM — тут конструктор реально снимает работу.
2. Пайплайн правят нетехнические люди. Визуальный редактор позволяет коллеге поменять ветку без деплоя.
3. Сценарии живут недолго и часто меняются. Быстро собрать, проверить гипотезу, выкинуть — это про n8n.

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

Как решить у себя

Перед тем как ставить оркестратор-конструктор, я теперь задаю один вопрос: сколько моих интеграций он закрывает готовыми нодами?

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

Оркестрация — это управление состоянием и порядком шагов. Postgres и цикл справляются с этим без отдельного продукта за $180 млн, когда всю тяжёлую работу по интеграциям ты всё равно делаешь сам.