mrkeyoor.com_
Wed 16 Sept 06:28 UTC
LLM Toolsevaluationupdated 25 Aug 2026

Flowise review

Flowise is a visual builder for AI agents and model-backed workflows. It lets people connect models, data sources, tools, conditions, and human input on a canvas, then expose the result through an application or API.

+12stars / 7d
Verdict

Do not start a new production system on the archived Flowise repository. It remains useful source code and existing users have a clear right to fork it, but the announced code freeze and end of life move dependency, security, and compatibility work onto adopters. Evaluate Langflow or Dify first unless preserving an existing Flowise estate is the deciding requirement.

We ran it

Lab card: what happened when we ran FlowiseScreenshot of Flowise (flowiseai.com)
Install✗ · 8s
Build
Repo2450 files~312,816 lines of source · 43.9 MB · 8 CI workflows · Dockerfile

Answers from our run

Does Flowise build from source?

The dependency install failed, and the project has no separate build step. We cloned commit 9291856 into a clean Debian container with 3 CPUs and no project-specific setup.

Who should not use Flowise?

New production adopters who expect vendor maintenance: the maintainers announced a code freeze, archived the repository on August 13, 2026, and set end of life for August 31.

What are the alternatives to Flowise?

Langflow, Dify, n8n. Do not start a new production system on the archived Flowise repository.

Setup2/5Quick starts exist, but our pinned-package install failed
Docs4/5Good user and deployment docs remain available
Community1/5Repository archived and official support is ending
Maturity2/5Proven product scope, now frozen with unresolved defects

Discussed on

  1. hnFlowise is shutting down58 points
  2. hnWorkday Acquires Flowise10 points
  3. hnShow HN: Quick AI Agent Deployment with Flowise and Qdrant4 points
  4. hnMax severity Flowise RCE vulnerability now exploited in attacks3 points
  5. hnShow HN: A faster way to set up Flowise and Qdrant for AI agent development3 points

Who it’s for

Existing Flowise users who need to operate or fork workflows they already depend on.
Teams evaluating low-code agent builders as reference implementations rather than adopting a maintained product.
Developers prepared to own an Apache-licensed fork, including dependency and security maintenance.
People who learn faster by inspecting a visual flow than by starting with framework code.

Who it’s NOT for

New production adopters who expect vendor maintenance: the maintainers announced a code freeze, archived the repository on August 13, 2026, and set end of life for August 31.
Teams unwilling to maintain a private fork: the end-of-life notice says new pull requests will no longer be reviewed and npm packages and Docker images will be deprecated.
Operators who require a dependable current container image: issue #6688 reports that release 3.1.4 fails during startup on a clean volume with bundled dependency errors.
MCP users who depend on remote SSE servers: issue #6715 reproduces the custom MCP fallback rejecting the response stream in 3.1.4.
Builders whose flows rely heavily on fan-in after Condition or Human Input nodes: issue #5358 reports those paths stalling when the target input already has a value or connection.

Setup reality

Our fresh Node sandbox never completed installation. It failed after 8 seconds because the repository requires pnpm ^10.26.0, while the image supplied pnpm 11.23.0; the log explicitly reports ERR_PNPM_UNSUPPORTED_ENGINE. The run stopped there, so it produced no build or test result.

The README offers a global npm install and a Docker route for ordinary use. Source development is a pnpm monorepo with server, UI, components, and API documentation packages; its build notes warn that Node may need a 4 GB heap. Model providers, vector stores, and other nodes bring their own credentials and service configuration.

The larger problem is ownership, not installation. Flowise is archived and approaching its stated end of life, so a serious deployment now starts with choosing a maintained fork or accepting responsibility for the codebase.

A visual builder that reached the end of its road

Flowise turns agent and AI application logic into connected nodes on a canvas. Its monorepo contains a Node server, a React interface, integration components, and generated API documentation. A user can assemble a chat flow, connect model providers and data, add tools or conditions, and run the result without expressing every step as framework code. That made it approachable for experiments and useful for teams where visual inspection matters.

The buying decision changed in August 2026. The README now opens with an archive notice. In the linked announcement, the maintainers say active feature work stopped on July 29, the repository became a public archive on August 13, and official community support ends on August 31. They also say npm packages and Docker images will be marked deprecated. The Apache-licensed source remains available, but Flowise is no longer a maintained upstream for a new production deployment.

Existing users face a different decision. A working Flowise installation does not become useless on the end-of-life date. Saved workflows, internal knowledge, and integrations may make a controlled fork cheaper than an immediate migration. That path is software ownership, though. Someone must triage dependency updates, review security fixes, test provider API changes, publish images, and decide which community patches to trust.

What happened when we ran it

We cloned commit 9291856 into an unprivileged sandbox with three CPUs, 8 GB of RAM, and the lab's Node 22 image. The repository contained 2,450 files, about 312,816 lines of source, and occupied 43.9 MB. It is a pnpm workspace monorepo and includes eight CI workflow files plus a Dockerfile. There was no top-level tests directory.

Installation failed after 8 seconds, before dependencies were installed. The repository's engine rule expected pnpm ^10.26.0, but the environment had pnpm 11.23.0. pnpm stopped with ERR_PNPM_UNSUPPORTED_ENGINE and told us the package-manager version was incompatible. The log also warned that the pnpm settings in package.json were no longer read by the installed pnpm. Since installation stopped at that check, our run produced no build or test result.

This is a precise failure with a straightforward next experiment: use the required pnpm line. It still counts against source setup because the README's prerequisite says to install pnpm without naming the accepted version in that section. A developer following that instruction and receiving the current latest pnpm can hit the same boundary before any application code runs.

The easy start and the real deployment

For ordinary evaluation, the README is clearer. Install Flowise globally with npm, start it with npx flowise start, and open port 3000. Docker users can run Compose after copying the sample environment file, or build an image locally. Those routes avoid the source monorepo's package-manager mismatch and are appropriate for testing the canvas.

Source contributors have more work. The setup installs every workspace and builds all modules. The README documents an exit-code-134 case where the build exhausts its heap, then suggests raising Node's old-space limit to 4 GB. Development also needs separate environment files for the UI and server. Beyond Flowise itself, useful nodes require credentials for model APIs, databases, vector stores, and external tools. A production operator must persist the database, encryption material, logs, and uploaded data, then put authentication and network controls around the service.

Release 3.1.4 illustrates why image pinning and smoke tests matter. Issue #6688 reports that its official image fails to start on a fresh named volume, citing LangChain export errors, a missing Smithy module, and a SQLite session-store error. The report says 3.1.3 starts with the same host and configuration. With upstream frozen, adopters cannot assume a later official image will repair that report.

Visual workflows still have sharp edges

Flowise's canvas is good at making the sequence and configuration of an agent visible. It lowers the initial cost of trying retrieval, tool calls, branching, human input, or a provider swap. That benefit is strongest when the available nodes match the intended design. Once a workflow depends on behavior that a node does not expose, users end up writing custom components or working around the graph model.

Open issue #5358 documents one such boundary. A Condition or Human Input node can stall when its output connects to a target input that already contains a value or another connection. The report includes reproduction flows and distinguishes the failure from an older similar issue. For teams building approval paths or branching graphs, this is the kind of behavior that needs a regression case around every important workflow.

MCP support also has a reported transport problem. Issue #6715 traces the custom tool's SSE fallback to an incompatible stream type in Flowise 3.1.4. The reporter says a remote SSE server is rejected because one dependency provides a Node stream while another expects a web ReadableStream. Use streamable HTTP where supported, or verify and maintain a patch before promising SSE-based tools.

What to choose now

GitHub lists 1,047 open issues and pull requests together. That queue had activity through August, and the last repository push was August 13, but those signals now describe the final days of an archived project rather than continuing health. Release 3.1.4 arrived on July 29 and included several authorization and allowlist fixes. The timing is uncomfortable: security-sensitive work landed immediately before maintenance stopped.

Flowise is still worth studying and may be worth forking for an established installation. It is a poor default for greenfield work because every unresolved defect and provider change now belongs to the adopter. Langflow is the closest first comparison for a visual agent canvas. Dify fits teams wanting a broader application platform, while n8n makes more sense when AI steps sit inside general business automation. New users should choose an active upstream; current Flowise users should inventory their flows and decide whether a fork or migration has the lower long-term cost.

Alternatives

ProjectWhat it isPick it when
Langflow gh↗A visual builder for AI workflows and agents with an active open-source project.pick this instead when you want a maintained visual canvas and can validate its component model against your existing flows.
Dify gh↗A self-hosted platform for building and operating model-backed applications and workflows.pick this instead when deployment, app management, and a maintained product surface matter more than Flowise compatibility.
n8n gh↗A broad workflow automation system with AI nodes among many business integrations.pick this instead when the job mixes agent steps with ordinary SaaS and operations automation.

Sources

  1. Flowise repository and README
  2. The Future of Flowise announcement
  3. Flowise 3.1.4 release
  4. Flowise documentation
  5. 3.1.4 container startup issue #6688
  6. Custom MCP SSE issue #6715
  7. Condition and Human Input stall issue #5358

More llm tools reviews

headcount · useagent · claude-skills · RAG_Techniques · ux-ui-agent-skills · dictionary-of-ai-coding · the whole board →