One name, several pieces: what FlowDrop is and who each part is for

People keep asking us versions of the same question. “Do I need the npm package to use FlowDrop in Drupal?” “Is FlowDrop a hosted service?” “Is it a Drupal module or a JavaScript library?”

These are reasonable questions. The name now covers several things, and each one is for a different reader. This post explains how FlowDrop got here and which part is meant for you.

The short answer

If you are…	Use this	What you get
Building on Drupal	drupal/flowdrop from drupal.org	The editor, the engine and the storage, all inside your site. No npm, no build step, no external FlowDrop service. More on /drupal.
Building your own app or backend and want only the visual editor	@flowdrop/flowdrop from npm	The editor UI. You implement the REST API it talks to, and your backend stores and runs the workflows.
An enterprise that needs orchestration outside a CMS	The Rust backend (flowdrop-rs), hosted	The same editor over a standalone Rust service. Contact Factorial for this.

All three use the same editor and the same workflow specification. What changes is where your workflows are stored and what runs them.

Where it started

Before FlowDrop existed, I (Shibin Das, d34dman on drupal.org) spent time with Flowise and Langflow. I liked them enough to contribute: I worked on a Flowise integration.

In practice, though, putting Drupal next to a third-party workflow system kept hitting the same problem. Once a request leaves Drupal, it leaves behind everything Drupal knows: who the user is, what they’re allowed to see, which content they’re working on, the access checks on every entity. Real projects depend on that context. A workflow that can’t respect a node’s access rules isn’t safe to point at real content.

So I wanted the workflow inside Drupal. The obvious first step was to reuse an existing editor. Flowise and Langflow are both open source, so why not take just their UI?

It turned out you couldn’t. Every workflow UI I looked at was tied to its own backend. The canvas, the node definitions and the execution model were all part of one product, and none of them could be lifted out and pointed at a different server.

Around the same time, Jürgen Haas (maintainer of ECA) announced the Modeler API, a common way for Drupal modules to plug visual modelers into Drupal. That gave me the push to build a workflow UI that lived in Drupal. I chose Svelte because I had worked with it before and preferred it to React or Vue, and Svelte Flow as the graph library underneath.

How it grew

1. A UI in Drupal, decoupled from day one

FlowDrop began on drupal.org as a UI-only project (flowdrop_ui). Even at that stage the editor didn’t reach into Drupal directly. It talked to Drupal through an API described by an OpenAPI contract. Drupal was the first backend, not the only one the editor could have.

That decision is the reason everything after it was possible.

2. The editor moved to npm

Because the editor only knew about the contract, it didn’t need to live inside a Drupal module. We moved it into its own package, @flowdrop/flowdrop, so anyone could use it: the people I’d been in the position of myself, who wanted a workflow UI for their own backend without adopting someone else’s engine.

The Drupal modules now consume the same package, so Drupal sites and other apps get the same editor.

3. The engine came to Drupal

A UI on its own only draws workflows. Shortly before DrupalCon Vienna (October 2025), FlowDrop gained an execution engine for Drupal: pipelines, jobs, triggers, human-in-the-loop interrupts and AI agent nodes, running as Drupal code with Drupal’s permissions.

This is what drupal/flowdrop is today. It includes the editor, so on a Drupal site you install one project from drupal.org and you’re done. You don’t need the npm package or a build step, and you don’t need to write a backend.

4. A Rust backend for enterprise orchestration

The last piece came from the other direction. Stephan Huber built flowdrop-rs, a standalone backend in Rust that uses the FlowDrop editor as its UI. It’s aimed at enterprise orchestration where a CMS isn’t the centre of the system. It’s the clearest evidence that the original bet paid off: the same editor, over a completely different engine, with no fork.

Clearing up the common mix-ups

“Do I need npm to use FlowDrop in Drupal?” No. drupal/flowdrop ships with the editor already built in. The npm package is for people who aren’t on Drupal.

“Is FlowDrop a SaaS?” No. The open-source parts (the npm editor and the Drupal modules) are free and run on your own infrastructure. The only hosted offering is the Rust backend, and it’s for enterprises.

“If I use the npm package, where does execution happen?” In your backend. The editor saves and loads workflows through the REST API you implement. It never sends your data anywhere else.

“What’s the difference between flowdrop_ui and flowdrop?” flowdrop_ui is where the project started, as the UI-only module. Today the editor ships inside drupal/flowdrop, so start there.

“Are the Drupal and Rust versions compatible?” Both implement the same specification. It’s the shared contract that says what a workflow means, independent of which backend runs it.

The thread through all of it

Each step followed from the one before it. A UI that kept Drupal’s context needed an editor that wasn’t tied to an engine. An editor that wasn’t tied to an engine could go to npm. An editor on npm could sit on top of a Drupal engine and a Rust engine at the same time.

If you’re still not sure which part fits your project, the docs go deeper, and the issue queue is open.