СТАТТЯ

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

Віталій Дорошенко Опубліковано

Розбираємо оновлення n8n 2.35+: що дають нові AI-агенти, MCP та швидкий запуск через Docker, і як побудувати межу між Bubble та бекенд-автоматизацією без зайвого DevOps.

Коли ви збираєте MVP на Bubble або експериментуєте з вайбкодінгом, головне завдання — якомога швидше запустити працюючий прототип, отримати перших реальних користувачів і підтвердити цінність ідеї. Будь-яке ускладнення інфраструктури на цьому етапі здатне зупинити реліз на тижні.

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

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

У вересні 2026 року інструмент було офіційно перейменовано з «AI Assistant» на n8n Assistant. Головні нововведення включають:

  1. Чат-асистент у редакторі: можливість створювати, редагувати, тестувати та налагоджувати воркфлоу через текстовий діалог прямо в інтерфейсі n8n.
  2. AI Agents (Preview): створення агентів із власними інструкціями, інструментами та навичками (skills). У селф-хості функція стала доступною як бета з версії 2.32.3 через модуль N8N_ENABLED_MODULES=agents.
  3. Дворівнева підтримка MCP:
    • Instance-level MCP-сервер: дозволяє підключати зовнішні інструменти (наприклад, AI-редактори чи Cursor) для перегляду, редагування та тестування сценаріїв і агентів у вашому екземплярі n8n (з версій 2.33+ / 2.34+).
    • Підключення до MCP Registry: сам асистент n8n може підключати зовнішні сервери з реєстру MCP під час конструювання воркфлоу.
  4. Швидкий запуск через Docker: офіційний скрипт curl -fsSL https://get.n8n.io | sh для Docker Compose v2, який розгортає оточення в папці ./n8n/.

Карта рішень: що лишати в Bubble, а що виносити в n8n

Офіційного посібника з інтеграції Bubble та n8n розробники не надають, але інженерна логіка диктує чіткий розподіл обов'язків:

Що завжди має залишатися в Bubble:

  • Користувацький інтерфейс (UI/UX): форми, списки, стан кнопок та миттєва реакція інтерфейсу на дії користувача.
  • Авторизація та безпека даних (Privacy Rules): розмежування доступу до даних між користувачами має відбуватися всередині Bubble. Виносити правила доступу в зовнішній сервіс для сирого MVP — це прямий шлях до витоків інформації.
  • Синхронна бізнес-логіка з низькою затримкою: якщо користувач натискає кнопку і чекає на результат за частку секунди, запит має оброблятися всередині додатку через рідні workflow або простий виклик API.

Що має сенс винести в n8n поруч із Bubble:

  • Міжсервісна інтеграція: надсилання повідомлень у Slack/Telegram, додавання лідів у CRM, експорт у Google Sheets, обробка платіжних вебхуків.
  • Фонова синхронізація за розкладом: регулярне оновлення статусів, очищення чи аналітика бази даних у фоновому режимі.
  • Багатоетапні сценарії з AI: коли для відповіді потрібно опитати кілька зовнішніх API, зібрати дані з різних джерел і повернути зведений результат у Bubble через вебхук.

Реальність «one-line Docker» для нетехнічного фаундера

Команда curl -fsSL https://get.n8n.io | sh виглядає як магічне рішення, але для людини без технічного бекграунду це пастка часу. Ось що насправді відбувається «під капотом»:

  • Скрипт розгортає складний мультиконтейнерний стек: n8n із базою SQLite за замовчуванням, пошуковий сервіс SearXNG та окрему пісочницю коду (n8n-sandbox).
  • Згідно з офіційною документацією n8n, цей стандартний бандл призначений виключно для локальної розробки та тестування, а не для продакшену. Для бойового середовища розробники рекомендують повноцінний PostgreSQL та середовище Daytona.
  • Стандартний раннер пісочниці використовує привілейований режим Docker-in-Docker, що суттєво розширює поверхню вразливостей і вимоги до безпеки сервера.
  • Витрати та налаштування (BYOK): селф-хост вимагає підключення власних API-ключів до моделей (OpenAI, Anthropic тощо). Водночас у хмарі (n8n Cloud) діє подвійна система кредитів (AI credits для асистента та Gateway credits для виконання побудованих сценаріїв).

Якщо ви не вмієте адмініструвати Linux-сервер і лагодити контейнери, які «впали», самостійний хостинг перетворить вас із продуктового засновника на системного адміністратора.

Чому не варто будувати ядро MVP на n8n Agents

Модуль Agents та сам Assistant прямо позначені розробниками як Preview (попередній перегляд). Це означає наступне:

  1. Нестабільність поведінки: моделі можуть помилятися в коді, а логіка інтерфейсу та API змінюється між мінорними релізами (наприклад, у документації вказується поріг 2.35+, тоді як у релізному блозі згадується 2.36+ для Docker).
  2. Відсутність черг (Queue mode): виконання агентів наразі не підтримує режим розподілених черг, що обмежує їх масштабування під навантаженням.
  3. База знань (Knowledge Base): для роботи з локальними базами знань у селф-хості необхідна інтеграція з Daytona, яка також перебуває у статусі Preview.
  4. Спільний простір MCP: instance-level MCP не має ізоляції між окремими клієнтами. Будь-який підключений до вашого n8n клієнт бачить усі увімкнені для MCP воркфлоу та агенти.

Чому не варто будувати ядро MVP на n8n Agents

Резюме для вайбкодерів і соло-засновників

  1. Не ускладнюйте старт: якщо ви будуєте перший прототип, щоб перевірити попит або показати демо інвесторам, тримайте основну логіку в Bubble. Використовуйте штатний Bubble API Connector для підключення готових зовнішніх API.
  2. Обирайте хмару замість VPS: якщо вам дійсно потрібен n8n для зв'язування зовнішніх сервісів, скористайтеся n8n Cloud або звичайними вебхуками, а не витрачайте час на підтримку Docker-контейнерів.
  3. Експериментуйте ізольовано: розглядайте n8n Agents та MCP як потужну лабораторію для тестування нових гіпотез, але не зав'язуйте на них життєво важливі функції вашого першого релізу.

Схожі статті

← Усі статті