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.

