n8n 2.35+: Agents, MCP, and one-line Docker next to Bubble
A practical guide for non-technical founders and vibe coders: how n8n 2.35+ Agents, MCP, and one-line Docker fit alongside Bubble for rapid MVP validation.
For non-technical founders, solo creators, and vibe coders racing to launch an MVP, the primary objective is rapid market feedback and customer validation. Bubble handles the user interface, relational database, and core logic efficiently. However, as workflows scale and AI tools evolve, deciding whether to offload orchestration to a dedicated engine becomes critical.
The n8n 2.35+ update bundles three notable additions: preview support for AI Agents, Model Context Protocol (MCP) connectivity, and a streamlined one-line Docker installer. Here is an honest, technical look at what this changes when pairing n8n with Bubble.
What n8n 2.35+ Brings to the Table
- Agents in Preview: The n8n Assistant can now assist in configuring instructions, external tools, and skills for autonomous agents. On self-hosted deployments, this is managed via the
agentsmodule (available from 2.32.3+), usinginstance-aifor scaffolding assistance. This feature is a rolling preview and is not yet available across all instances. - MCP Registry via Assistant: Users can connect external servers from the MCP registry using the Connections sidebar. The Assistant references these tools while creating workflows and gathering context. This works alongside existing workflow-level nodes (
MCP Client ToolandMCP Server Trigger) and instance-level MCP server configurations. - One-Line Docker Setup: The installer simplifies self-hosting with
curl -fsSL https://get.n8n.io | sh. While 2.35 remains in beta, pinning--version 2.35.0is recommended. Requiring Docker and compose v2, the command provisions a local./n8ndirectory, starts a bundled execution sandbox, launches SearXNG for web search capabilities, and enables the Assistant. Model API keys are configured directly in the web UI or via.env.
The Bubble + n8n Architecture
The standard architectural pattern for combining both platforms is straightforward:
Bubble (API Connector / Backend Workflows) ➔ n8n Webhook ➔ Agent Execution / Integrations ➔ Respond to Webhook / Callback into Bubble
Bubble acts as the front-end application and primary user datastore, while n8n functions as an external worker orchestrating heavier multi-step jobs and AI tasks.
When to Add n8n to Your Bubble Stack
- Complex Multi-Step Integrations: When your product connects to numerous third-party APIs that become cumbersome or fragile to maintain inside Bubble's native API Connector.
- Agentic Logic and MCP Tool Calling: When you need dynamic decision-making trees, autonomous agent loops, or MCP-driven tools operating outside your main application layer.
- Offloading Heavy Background Jobs: To protect Bubble's performance and workflow capacity from long-running synchronization and data aggregation routines.
When to Stick Exclusively to Bubble
If you are building your first MVP to validate customer demand and your workflow consists of standard CRUD operations, email triggers, and simple API requests, do not introduce an external self-hosted orchestrator.
While the one-line installer eliminates manual compose configurations, operating an orchestration server introduces real operational overhead:
- The self-hosted Assistant is Docker-only; npm-based self-hosting does not support this setup.
- The bundled sandbox is designed for rapid initial setup; official documentation points toward Daytona for production-grade security and isolation.
- Agents and the Assistant are in preview: LLM-generated workflows require strict manual review before being exposed to live user traffic.
- Self-hosted agent limitations currently include lack of queue mode support, reliance on a properly configured public
WEBHOOK_URLfor channel webhooks, and pending Enterprise compatibility.
Keep your tech stack lean during the initial validation phase. Consider n8n 2.35+ as an auxiliary engine only when your agentic and integration needs outgrow Bubble's native workflows.