Flowise

For three years this was the answer when somebody wanted to assemble a retrieval chatbot by dragging boxes, and it was a good answer. Drag-and-drop got a lot of people building who would never have written the code, and that is a real contribution to the field.

It is ending, so the recommendation writes itself. Do not start anything new here. Pick Dify if you want the same shape of tool with a project that is still shipping, and if you already have flows running, treat this quarter as the migration quarter rather than next year.

The sequence matters. A hosted tier existed at monthly prices, meaning people were paying for something now marked as ending, and the code that backs it accepts no further changes. Anyone whose flows live in that cloud has a deadline set by somebody else and no way to influence it.

Export everything now and assume no further fixes. What it does right: self-hosting was always available and always the primary path, so the shutdown is a maintenance problem for most users rather than a data-loss event.

A visual builder's capability is the union of its integrations, so its maintenance burden grows with the number of external interfaces it wraps, none of which it controls. Each provider that changes an endpoint imposes work that produces no new capability, and the total cost rises monotonically while the differentiation does not.

That is a structural property, not a failure of effort, and it explains more sunsets in this category than any competitive argument. No benchmark was ever published, which for an authoring environment is reasonable, since the thing being measured would be the user.

The numbers tell the story without commentary. Enormous developer adoption, a hosted tier priced in the range where a solo builder pays and a company does not notice, and no path from one to the other that covered a team. Self-hosting was free and good, so the people most likely to pay were the people least likely to need the cloud.

That is the open-source business problem stated in its purest form. Likely outcome from here: the code persists in forks. Position: none, and this belongs in every deck about monetising an open project.

My only question is whether anyone here already depends on it, and if so, which flows and how quickly they can be rebuilt. There is no supplier to hold to a support commitment, no security contact for the next dependency advisory, and nobody to answer the retention question for whatever was stored in the hosted tier.

A tool with a published end date cannot enter procurement, and one already inside the estate becomes a tracked risk with an owner and a date. Not yet, which in this case means not ever.

The licence is clean and the code is all there, which is the best thing an ending project can leave behind. It installs globally from npm and runs locally with no account, it consumes MCP servers, and it takes any model endpoint I point it at, including my own.

The catch is what a fork actually commits you to. Taking this on means maintaining every connector against APIs owned by other people, forever, which is a lot of unpaid work for a canvas. I would take the parts I want rather than the project. That is not ownership, and it is the honest option.