What is Flowdrome

Flowdrome is a workflow automation platform — in the family of n8n, Zapier and Power Automate — with one defining difference: your workflows run on your machines, not in somebody’s queue. Every host embeds the same engine the editor tests with; deploying a workflow pushes the exact document you tested to a machine you control, where its real triggers serve continuously.

A -drome is a place where things run: velodrome, aerodrome. Flowdrome is where workflows run.

The three pieces

PieceWhat it isWhere it runs
StudioThe visual editor: canvas, node library, live testing, single-step debugger, run history. Embedded in the Nucleus.Your browser
NucleusThe control plane: workflow registry, credentials vault, users & roles, host fleet, deployments, the approvals inbox. It manages everything and executes nothing.One server (port 48170)
HostsThe data plane: machines that execute workflows. A host serves its deployed workflows’ triggers on an embedded engine, keeps a run ledger, reports resource telemetry, and dials home to the Nucleus.As many machines as you like (port 48150)

The split matters operationally: hosts keep executing if the Nucleus goes down, and management traffic never shares a process with workflow traffic.

The lifecycle

  1. Build a workflow visually in Studio — 106 nodes, typed ports, live validation, and {{ }} expressions in any string field.
  2. Test it from the editor against real services. Every run records the whole data envelope on every wire; you can single-step, inspect any node’s exact input and output, and retry a failed run from the node that broke.
  3. Deploy. One click pushes the same flowdrome.workflow.v1 document you tested — stamped with its saved version — to a host in your fleet. The host’s embedded engine takes over serving the real triggers: HTTP, schedules, Telegram, Slack, WhatsApp, web chat, forms, WebSocket, file events.

What’s in the box

  • 106 nodes — triggers, flow control (if/switch/merge/loop/try/wait/approval/rate-limit), list tools, data shaping, SQL (Postgres/MySQL), S3, Redis, Mongo, FTP/FTPS, IMAP, RSS, CSV, crypto, email, Telegram, Slack, Discord, WhatsApp, Google Sheets/Docs/Drive, Gmail, Notion, HubSpot, Outlook, message queues — and 17 AI nodes: agents with tools and memory, wired model carriers, a full RAG pipeline, guardrails, evals, transcription, speech and image generation. See the node reference — it is generated from the node registry itself.
  • A credentials vault with OAuth2 connect flows (Google, Microsoft, Notion, HubSpot, and a generic provider). Deployed workflows lease secret values at run start; nothing is baked into deployments.
  • Human-in-the-loop approvals — a workflow pauses at an approval gate until someone decides, and every pending gate across the fleet lands in one inbox.
  • Observability — whole-envelope run data, per-node timings, bottleneck stats, host run ledgers and resource telemetry.
  • Error handling — try frames, error-trigger recovery lanes, and stop-and-error.
  • An AI that builds for you — the in-Studio AI Copilot edits the workflow you have open from plain sentences, and every Nucleus serves the Model Context Protocol at /mcp, so Claude Code or Cursor can discover nodes, build, validate and test-run workflows on your instance — one URL, zero setup.
  • A real API — the Authoring REST API (and the mock/service layer under /api/mock/…) is implemented as workflows you can open on the canvas.

A note on names

Flowdrome’s engine carries its codename, flowdrome, in technical surfaces: environment variables use the FLOWDROME_ prefix, artifacts are named flowdrome-host, and the workflow document format is flowdrome.workflow.v1. Commands in these docs are verbatim — what you see is what runs.

Where next