Автоматизация под ключ: собрал MVP на своей оркестрации вместо n8n

С чего началось

Я собирал MVP системы, которая крутит рекламу в Telegram и VK: подбор каналов, закупка, учёт в ОРД, сведение отчётов. В первом отчёте по архитектуре у меня стоял n8n. Логика простая, её поймёт любой, кто тянет автоматизацию в одиночку: визуальный конструктор, готовые ноды, собрал схему мышкой — запустил. Для соло-разработчика скорость решает всё.

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

Почему n8n не подошёл именно мне

Вот на чём держится продукт: TGStat, Telemetr.io, Telega.in, TeleTarget, маркет-платформа VK, API оператора рекламных данных (ОРД). Я проверил каждую интеграцию. Готовых нод под них в n8n нет ни одной.

Тут и кроется весь фокус. n8n силён, когда у тебя Gmail, Slack, Notion, Google Sheets — сотни коробочных интеграций, где схема правда собирается без кода. Но стоит твоим сервисам выйти за пределы этого каталога, и HTTP-запросы ты пишешь руками. В n8n для этого есть Code-ноды: тот же Python или JS, только внутри чужого UI.

Я прикинул, к чему всё придёт. Код интеграций я всё равно пишу сам, целиком. Сверху держу на VPS ещё один сервис — со своей базой, воркерами и панелью. И отлаживаю логику кликами в интерфейсе, где половина состояния спрятана по нодам. То есть n8n дал бы мне не готовые интеграции. Он дал бы обёртку вокруг кода, который я и так пишу, плюс лишнюю точку отказа на сервере.

Для соло-билдера это плохая сделка. Ты платишь сложностью инфраструктуры за удобство, которым не пользуешься.

Что поставил вместо

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

Звучит скромно, и в этом весь смысл. Постоянный цикл исполнения, который переживает перезапуск, спокойно живёт без отдельной платформы. Состояние хранится в базе. Оперативная память процесса тут ни при чём: упал воркер — поднялся, прочитал из Postgres, где остановился, поехал дальше. Никакой магии, которую нельзя объяснить за пять минут.

Более тяжёлые варианты я сюда сознательно не тащил. LangGraph Platform по лицензии звонит домой на свои серверы — для проекта с рекламными бюджетами и данными клиентов это лишний внешний контур, а он мне не нужен. Голые Skills в Claude Code живут в рамках сессии и не работают как демон — это инструмент под другую задачу. Мне же нужен был всегда включённый слой исполнения. Postgres со стейт-машиной его и дал.

Что я на этом понял

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

• Больше половины сервисов — готовые ноды. Бери n8n, ты правда сэкономишь недели. Это его территория.
• Ключевые сервисы без нод, всё на HTTP. Код ты всё равно пишешь. Тогда UI-конструктор ничего не ускоряет — это просто второй сервис, который надо кормить и чинить.

Мой случай был вторым. И выяснилось это только тогда, когда я перестал любоваться красивой схемой в отчёте и выписал список API руками.

Честный минус своего решения

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

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