Flowise vs langflow: one is archived, the other turns flows into MCP tools
Flowise is an archived TypeScript canvas for LLM chains; langflow is a maintained Python platform whose flows become HTTP and MCP endpoints. The live difference is not the drag-and-drop editor both share, it is whether the project still receives fixes and whether a flow can leave the canvas as a callable tool.
At a glance
| Project | FlowiseAI/Flowise | langflow-ai/langflow |
|---|---|---|
| Licence | Custom licenceCustom licence: read the LICENSE file | MITPermissive: commercial use allowed |
| Maintenance | ArchivedLast push August 13, 2026 | Commits in the last dayLast push September 29, 2026 |
| Language | TypeScript | Python |
| GitHub stars | 55,492 | 155,375 |
| Read more | Our analysisGitHub | Our analysisGitHub |
Which one to choose
Choose Flowise if you already run it, you need a self-hosted Node and React canvas for LLM chains, and you accept that the repository is archived and the last push was on 2026-08-13, so no further fixes are coming.
Choose langflow if you want a flow you can read and edit as Python, expose as an HTTP or MCP endpoint without writing the server, and run on a project whose last push was on 2026-09-17 under the MIT licence.
What each project actually is
Flowise is a TypeScript monorepo with three parts: a Node server that serves the API, a React frontend holding the canvas, and a components package for third-party node integrations. The README also lists an api-documentation module, swagger-ui generated from express. The visual editor is the product; the server exists to run what you draw. Langflow is a Python project that pairs a drag-and-drop flow editor with built-in API and MCP servers. Its README states that every workflow becomes a tool that can be integrated into applications on any framework or stack, and that flows can be deployed as an API or exported as JSON for Python apps. The architecture difference matters more than the editor, because both editors look similar on screen. Flowise keeps the runtime in Node and the integrations in a separate components package. Langflow keeps the runtime in Python and lets you customize any component in Python, which the README calls source code access. That is the fork in the road: a TypeScript monorepo whose nodes come from a package, against a Python platform where the node you edit is the code you run.
Getting each one running
Flowise documents two short paths. The README gives npm install -g flowise followed by npx flowise start, then http://localhost:3000, with NodeJS 20.0.0 or newer as the prerequisite. Docker is covered both ways: a docker folder with a .env.example you copy to .env and bring up with docker compose up -d, or a local build with docker build --no-cache -t flowise . and docker run -d --name flowise -p 3000:3000 flowise. Developers clone and use pnpm: pnpm install, pnpm build, pnpm start. The README warns about exit code 134, JavaScript heap out of memory, during the build, and gives NODE_OPTIONS=--max-old-space-size=4096 for macOS, Linux, Git Bash, PowerShell and CMD. That warning is the most concrete operational detail in the document. Langflow requires Python 3.10 to 3.14 and uv, installed with uv pip install langflow -U and started with uv run langflow run, which the README says serves at http://127.0.0.1:7860. Docker is a single command, docker run -p 7860:7860 langflowai/langflow:latest, and there is a make run_cli path from a cloned repository. Langflow Desktop is offered for Windows and macOS with dependencies included, so no Python environment has to be managed. The practical difference: Flowise needs a Node toolchain or Docker, langflow needs a Python version inside a stated range and a resolver that can satisfy its bundle ranges. The README does not document rollback for either install path.
Turning a flow into something other systems can call
This is where the two projects stop being interchangeable. Langflow's README states that it has built-in API and MCP servers, that every workflow becomes a tool, and that flows can be deployed as an MCP server for MCP clients. It also lists observability integrations with LangSmith and LangFuse. Flowise exposes a server API, and its api-documentation module generates swagger-ui from express, so a flow can be called over HTTP. What the Flowise README does not document is an MCP server or a comparable tool-exposure layer. If your goal is to hand a workflow to an agent framework as a callable tool, langflow documents that path and Flowise does not. If your goal is a self-hosted canvas whose output is called by your own application over the API the server already exposes, both can serve, and the Flowise route is the older, narrower one. The second difference is inspectability. Langflow's source code access means a component can be edited as Python, and flows export as JSON for Python apps. Flowise's nodes come from the components package, which the earlier analysis flags as a thing to verify: whether your node integrations are covered by that third-party nodes package. A node that is not in the package is work you do yourself inside the monorepo.
Operations, scaling and the sync problem
Flowise is a Node process plus a React build, deployed from a Docker image or from source, with environment variables set in a .env file inside the server package. The README lists self-host deployments on AWS, Azure, Digital Ocean, GCP, Alibaba Cloud, Railway, Northflank, Render, HuggingFace Spaces, Elestio, Sealos and RepoCloud, and points to a Flowise Cloud offering. That breadth is deployment documentation, not a statement about horizontal scaling, and the README does not describe how state is shared across replicas. Langflow runs as a Python process on port 7860, in Docker or from source, and the README says it can be deployed to all major deployment clouds, with a Docker deployment guide and a deployment overview. It claims enterprise-ready security and scalability without stating a mechanism in the README. The constraint that belongs to langflow alone is stated in the earlier analysis: the visual layer and the Python layer have to be kept in sync by hand. Edit a component in the canvas and the Python has to match; edit the Python and the canvas has to match. That is a manual discipline, not a bug, and it is the cost of source code access. Flowise's analogous cost is different: the repository is archived, so operational problems have no upstream fix path. Neither README documents a migration or version-skew procedure for flows.
Where each one falls short
Flowise's shortfall is not technical. It is that the repository is archived and the last push was on 2026-08-13. The README itself carries the notice that Flowise has been archived and points to a discussion titled Future of Flowise. Recent releases exist, [email protected] on 2026-07-29 among them, but releases before an archive do not imply releases after it. The earlier analysis is blunt about the consequence: do not adopt it if you need vendor support, a security response process, or a roadmap you can influence. The licence compounds this. Flowise is listed as Other, a custom licence GitHub cannot classify, with the LICENSE file as the authority, so anyone redistributing needs to read it rather than assume Apache 2.0 terms. Langflow's shortfalls are narrower and more ordinary. The visual and Python layers must be kept in sync by hand. The Python version must sit inside 3.10 to 3.14. The earlier analysis warns that the lfx-* bundle ranges in pyproject.toml are bounded ranges rather than exact pins, so the resolver is where trouble shows up first. The README also does not document rollback, and its security and scalability claims are stated without mechanism. If your pipeline is a single prompt call, the earlier analysis says to skip langflow entirely, because the platform is more machinery than the task needs.
Licence and maintenance implications
The two projects sit at opposite ends of the maintenance question, and the licence question runs in the same direction. Langflow is MIT, a licence most legal teams can clear without a conversation, and its last push was on 2026-09-17, three days before today, with releases v1.11.5 on 2026-08-25, v1.11.4 on 2026-08-19 and v1.11.3 on 2026-08-11. Flowise is Other, and the LICENSE file governs what you may do with it. The earlier analysis puts the obligation plainly: verify that Apache 2.0 obligations are met for whatever you redistribute, which is a check you run against the actual licence text, not the GitHub label. On maintenance, the archived flag and the 2026-08-13 last push mean Flowise cannot be called actively maintained. A security issue found in it stays unfixed unless someone forks. For an internal tool with no external exposure and no redistribution, that may be acceptable. For anything customer-facing, regulated, or shipped inside a product, the archived state is the deciding fact, and it is the one thing no amount of deployment documentation compensates for. Langflow's maintenance is current by its last push, but currency is not a guarantee: no project owes you a roadmap, and the MIT licence gives you the same fork-and-fix right that Flowise's archived state makes relevant.
Choosing for concrete scenarios
For a new project that needs a visual builder and a callable endpoint, langflow is the defensible choice: MIT licence, current last push, documented API and MCP server paths, and Python components you can edit. For a team that already runs Flowise, the question is not which is better but how long the existing deployment must live. If it is an internal canvas with no external exposure and a frozen feature set, keep it and pin the version. If it must grow, plan the move now, because the archived repository will not absorb new requirements. For a Node-only shop with no Python in production, Flowise fits the runtime you already operate, and langflow would add a second language and a second package manager to your operational surface. For a Python shop, the reverse is true, and langflow's flow-as-Python model removes the language mismatch that Flowise would introduce. For a pipeline that is a single prompt call, neither is warranted. For a workflow that must be handed to an MCP client as a tool, langflow documents that capability and the Flowise README does not. For a team that needs a vendor to answer a security report, neither README offers that, and Flowise's archived state rules it out entirely.
Bottom line
Pick langflow for new work unless your production runtime is Node-only or your pipeline is a single prompt call. Pick Flowise only to keep an existing internal deployment alive, with the version pinned and the LICENSE file read. Before committing to either, verify on your own machine that Flowise's npm install -g flowise and npx flowise start resolve on your Node version and that your node integrations exist in the components package, or that langflow's Python version sits inside 3.10 to 3.14 and the lfx-* bundle ranges in pyproject.toml resolve against the rest of your environment. The archived state of Flowise, not any feature comparison, is the fact that decides most cases.