n8n 2.35+: Agents, MCP і one-line Docker поруч із Bubble

Для фаундерів і креаторів, які збирають MVP без технічного бекграунду за допомогою no-code та вайбкодінгу, головна мета — якнайшвидше перевірити гіпотезу, показати прототип користувачам або пітчити першим інвесторам. Bubble закриває інтерфейс, базову базу даних і логіку, проте зі зростанням кількості сторонніх сервісів виникає питання: чи варто виносити фонові процеси в окремий оркестратор?

Оновлення n8n 2.35+ зібрало в одному релізі три ключові компоненти: AI Agents у режимі preview, інтеграцію Model Context Protocol (MCP) і спрощене встановлення Docker однією командою. Розглянемо прагматично, що це дає соло-розробнику поруч із Bubble і де межі доцільності.

Що нового в n8n 2.35+

1. Agents (Preview): Інструмент дозволяє створювати агентні сценарії, де асистент пропонує інструкції, підключення інструментів та навичок. На self-hosted версії агенти реалізовані як окремий модуль agents (починаючи з 2.32.3+), а генерація структури спирається на instance-ai. Зверніть увагу: функціонал перебуває на етапі preview і розгортається поступово (доступний ще не всім інстансам).
2. MCP у контексті n8n Assistant: Тепер можна підключати сервери з реєстру MCP через панель бічного меню Connections. Асистент використовує ці контексти для конструювання сценаріїв. Це доповнює вже наявні вузли робочих процесів (MCP Client Tool та MCP Server Trigger) та інстанс-рівень підключень.
3. One-line Docker Setup: Для швидкого старту додано команду curl -fsSL https://get.n8n.io | sh. Поки реліз має статус beta, офіційні матеріали рекомендують фіксувати версію (--version 2.35.0). Скрипт вимагає наявності Docker із compose v2, створює каталог ./n8n, автоматично налаштовує вбудований пісочницю (bundled sandbox), локальний пошук SearXNG та активує Assistant. Ключі до моделей штучного інтелекту додаються через інтерфейс або файл .env.

Архітектура: як Bubble взаємодіє з n8n

Стандартний перевірений патерн інтеграції виглядає так:

Bubble (API Connector / Backend Workflows) ➔ n8n Webhook ➔ Робота агентів або інтеграцій ➔ Respond to Webhook / Зворотний виклик у Bubble

Bubble залишається фронтендом для клієнтів і панеллю введення даних, а n8n виступає зовнішнім виконавцем ресурсомістких завдань.

Коли варто ставити n8n поруч із Bubble

• Складні багатоетапні ланцюжки інтеграцій: якщо ваш MVP агрегує дані з десятків зовнішніх сервісів або API, якими незручно керувати через стандартний API Connector Bubble.
• Агентні сценарії та MCP-інструменти: якщо вам потрібні автономні LLM-агенти, які виконують перевірку умов, пошук контексту через MCP і виклик зовнішніх тулів поза межами Bubble.
• Фонові довгі процеси: щоб не витрачати робочі потужності Bubble на тривалі синхронізації чи обробку великих файлів.

Коли це зайве ускладнення для запуску

Якщо ви перевіряєте першу гіпотезу, а логіка застосунку зводиться до базових форм, створення записів у базі даних і пари простих викликів API — не розгортайте додатковий стек.

Спрощений Docker усуває рутину з конфігурацією compose-файлів, але не прибирає відповідальність за інфраструктуру. Self-hosted рішення має технічні нюанси, які нетехнічному засновнику варто знати наперед:

• Assistant для self-hosted працює виключно через Docker (установка через npm для цього шляху не підтримується).
• Вбудована пісочниця розрахована на швидкий старт; для надійного production-середовища документація рекомендує ізоляцію на базі Daytona.
• Функціонал перебуває у статусі preview: логіка агентів може містити помилки, тому всі критичні сценарії вимагають обов'язкового ручного аудиту перед релізом.
• На self-hosted версії агенти наразі не підтримують queue mode, вебхуки каналів вимагають коректного публічного WEBHOOK_URL, а підтримка для Enterprise-інстансів ще перебуває в розробці.

Для перших користувачів і швидких тестів завжди обирайте найкоротший шлях до релізу. Підключайте n8n 2.35+ як зовнішній шар тоді, коли можливостей вбудованих воркфлоу Bubble дійсно перестає вистачати.