Автоматизация без n8n: когда сценарий проще держать в коде

Слово «автоматизация» — и рука сама тянется к n8n. Иногда рефлекс срабатывает верно. А иногда так в проекте заводится ещё один сервис: его надо обновлять, бэкапить и держать живым на VPS.

Расскажу, как я решал этот вопрос на своём проекте и какие признаки видны ещё до того, как поднят первый контейнер.

Кейс: почему n8n выпал из стека

Я собирал MVP для работы с рекламными размещениями в Telegram и VK. Список ключевых интеграций: TGStat, Telemetr.io, Telega.in, TeleTarget, маркет-платформа VK, ОРД для маркировки. Готовых нод в n8n нет ни для одной.

Значит, каждый вызов складывался бы так: HTTP-нода, следом Code-нода — разбор ответа, обработка ошибок, приведение данных к своему формату. Выписал это на бумагу и увидел очевидное: код я в любом случае пишу руками. n8n в такой картине даёт UI-обёртку вокруг моего же кода плюс лишний контейнер в docker-compose.

Заменил тонким Python-оркестратором. Состояние сценария живёт в таблице Postgres, запуск — тот же Docker Compose, шаги — обычные функции. Схему нарисовал отдельно, в документации, где ей и место.

Пять признаков, что сценарий пора держать в коде

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

Логика ветвится по данным. Три условия мышкой рисуются нормально. Пятнадцать превращаются в полотно, которое читать сложнее, чем сорок строк питона с внятными именами.

Сценарий должен переживать перезапуск. Долгие процессы с ожиданием внешнего ответа — модерация, оплата, ответ площадки — просят явную машину состояний. В коде это одна таблица со статусом и полем «на каком шаге остановились».

Нужны тесты. Логику в Code-нодах не прогнать в CI одной командой. Функцию — прогонишь. Скорость правок меняется принципиально.

Работаешь один. Визуальный редактор ценен общим языком с людьми, которые не пишут код. Соло-билдеру этот мост объяснять некому.

Где n8n остаётся сильнее

Против инструмента я не топлю — свой класс задач он закрывает честно:

• много типовых SaaS в цепочке: Google Sheets, Slack, Notion, CRM — ноды есть, писать почти ничего;
• сценарий смотрят и правят люди без разработки, включая заказчика;
• гипотезу надо проверить сегодня, а завтра выкинуть;
• вебхуки, расписания, ретраи, история запусков и логи нужны сразу и без кода.

По этой же причине n8n двигается в enterprise-сторону: партнёрство с SAP, крупный раунд, ставка на оркестрацию AI-агентов. Инструмент для команд, где сценарий должен быть виден многим.

Как выглядит замена

Минимальный набор, который у меня закрыл всё:

• таблица runs в Postgres: id, сценарий, текущий шаг, payload, статус, время обновления;
• каждый шаг — функция, которая берёт payload и возвращает имя следующего шага;
• планировщик — cron или один вечный цикл, который выбирает записи в статусе «ждёт»;
• ошибка пишет статус failed и текст в last_error, ретрай подхватывает по расписанию;
• секреты — переменные окружения, весь запуск — docker compose up.

Бонусом: состояние видно обычным SQL-запросом, а упавший сценарий перезапускается обновлением одной строки.

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

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

Поэтому такое решение принимают один раз и осознанно. Рефлекс тут плохой советчик.

Проверка на один вечер

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

Больше половины минусов — код будет чище и дешевле. Плюсов большинство и сценарий смотрят коллеги — берите n8n и не выдумывайте.

Правило, которое я вынес: n8n окупается коннекторами. Считаете коннекторы — получаете ответ.