Fluxo is built around nodes. Nodes are the user-facing vocabulary: triggers, AI steps, transforms, review gates, and outbound integrations. Everything else in Fluxo exists to make nodes safe, composable, and operable.
The key architectural decision is that nodes are registry-defined and type-safe. Adding a node is not “drop a component somewhere”. It is deliberate wiring across UI, runtime, validation, and entitlements. That friction is intentional because it prevents partial integrations and long-term inconsistency.
Registry-first design
Fluxo centralizes node definitions through type-safe registries:
- UI component registry for React Flow rendering
- executor registry for runtime behavior
- tier requirement mapping
- trigger type mapping and default variable aliases
When you add a node, you wire all these contracts explicitly. This creates predictable behavior:
- The editor knows how to render and configure the node.
- The runtime knows how to execute the node and record outputs.
- The platform knows which credentials are required and which tiers can use it.
- The template engine and analytics know what output shapes to expect.
Node families I support today
Fluxo ships multiple node families because automation is not only “call an API”. It is “start reliably, transform correctly, govern risk, and ship outcomes”.
Trigger nodes
- MANUAL_TRIGGER
- GOOGLE_FORM_TRIGGER
- STRIPE_TRIGGER
- SCHEDULE_TRIGGER
- EMAIL_TRIGGER
- FILE_WATCHER_TRIGGER
- WEBHOOK_TRIGGER
- RSS_TRIGGER
AI and execution nodes
- OPENAI, ANTHROPIC, GEMINI
- HTTP_REQUEST, GOOGLE_SHEETS, DATABASE
- NOTION, AIRTABLE, GOOGLE_DRIVE
- SLACK, DISCORD, TELEGRAM, EMAIL_SEND
- HUMAN_REVIEW
Logic and transformation nodes
- CONDITIONAL, FILTER, TRANSFORM
- DELAY, CODE, MERGE, SWITCH, LOOP
- MARKDOWN_HTML
Output contracts and variable paths
Nodes are composable only when their outputs are predictable. Fluxo maps known output paths by node type so the platform can:
- improve template validation quality
- provide better autocomplete/intellisense surfaces
- power analytics attribution and debug views
Why plugin-style mattered
A stable node plugin contract lets Fluxo evolve quickly:
- add new integrations without touching core execution loop
- reuse shared interpolation and credential patterns
- maintain predictable UX patterns in node forms/dialogs
I deliberately resisted monolithic node logic because composable automation platforms die when every new integration requires special-case runtime surgery. Registry-first keeps complexity localized: node-specific behavior lives in node modules, while the runtime stays generic.
Practical engineering benefit
This architecture gives Fluxo a clean place to enforce subscription gating, credential typing, and schema validation per node class while keeping the execution runtime generic. That is what makes “add node 31” feel like repeatable engineering work instead of risky surgery.