Choose a backend
FlowDrop is an editor plus a backend of your choice. Deciding which backend runs your workflows is the first decision, not the last.
FlowDrop ships as two halves that are deployed separately.
The editor is a front-end component you mount in your own application. It draws the canvas, renders node configuration forms, and validates connections. It stores nothing and runs nothing.
The backend is whatever answers the FlowDrop REST API. It owns the node types the editor offers, the storage workflows are saved to, and the execution that gives a workflow meaning. FlowDrop does not supply one implicitly — you pick it, and the editor talks to it over one HTTP contract.
That is why this is the first page. Everything after it — mounting, theming, custom nodes — is the same whichever backend you chose, and nothing works until you have chosen one.
The options
There are three of them, and they are peers: two you run yourself, one you buy.
Drupal
A complete backend shipped as a contributed Drupal module, with the editor included. Node processors, workflow storage as configuration entities, execution modes, triggers and human-in-the-loop.
Your own server
Implement the documented REST contract on the stack you already run. The API reference is written as a contract for exactly this.
Hosted by Factorial.io
Do not run a backend at all. Factorial.io operates flowdrop-rs, a Rust
server implementation of the FlowDrop API. Enterprise only, and priced by
conversation.
Drupal — the one that is finished
The Drupal module is the mature backend implementation. It is
published on Drupal.org, it implements the whole contract, and it ships the
editor with it: there is no endpointConfig to wire and no separate front-end
build. If you are already on Drupal, this is a one-step install.
It is also the only backend for which the editor's front-end integration is not your problem — see FlowDrop for Drupal for how the module maps onto FlowDrop's concepts.
Roll your own — a first-class option, not a fallback
FlowDrop is a specification with an editor attached. The API reference documents the endpoints your server implements; the backend implementation guide walks through them in the order you need them, and authentication patterns covers attaching credentials from the editor side.
Any stack that can serve JSON over HTTP qualifies. Nothing in the editor assumes a language, a framework or a database.
Hosted — Factorial.io runs the backend for you
The third option is not to run one. Factorial.io operates flowdrop-rs, a
Rust server implementation of the FlowDrop API, as a hosted service. You mount
the same editor against it, and the backend is somebody else's to operate.
Two things to know before you plan around it:
- It is an enterprise offer, and the price is a conversation. There is no sign-up, no self-serve tier and no published rate — pricing depends on the deployment. Pricing sets out the offer, and the contact form is how you start it.
- It has no public source and no public documentation yet.
flowdrop-rsis a private repository with no public release, so nothing on this site documents the server itself. The MIT licence covers the editor, not the Rust backend.
What is public is the part you build against: flowdrop-rs implements the same
REST contract as every other backend, so the editor-side work — mounting,
theming, custom nodes, authentication — is identical to the other two options.
Develop against the example Express server first
Whichever backend you end up with, you do not need it running to start. The
example Express server is a
reference implementation of the full contract with seed data and CORS already on.
It keeps everything in memory, so it is for local development only — but it means
the editor has real node types to place within a minute of npm install.
If you want to see how the same server is built rather than just run it, the Express backend recipe constructs one from an empty directory.