Flowise: Visual Agent Builder Now Archived

Flowise is a visual builder for AI agents and chatbots that is now archived. Its team announced a wind-down on 29 July 2026, the repository went read-only on 13 August, and official support ended on 31 August 2026. The code is still available and still runs, but new projects should start somewhere maintained. Checked 31 October 2026.

At a glance

What happened

The repository README now carries a heading: "Flowise has been archived." It points to a discussion called Future of Flowise. In it, the maintainer says the team decided to wind down operations. His stated reason is that developers increasingly use coding agents and that the "typical rigid workflow low-code approach quickly hits the limit" on complexity.

The dates from that post:

The Apache 2.0 code stays available, and the post encourages teams to fork the repository, either for internal updates or as community-led forks. The Flowise website opens with "We're sunsetting Flowise" and links to a sunset page we did not read. It still shows sign-in buttons for Flowise Cloud and a pricing table.

The lesson is the one our AI agent platform page draws: a visual builder tied to a single company can disappear with a notice. Moving off is easier if your prompts, tool descriptions and data live in files you own.

What Flowise did

Flowise's docs describe it as "an open source generative AI development platform for building AI Agents and LLM workflows." It had a visual builder and, alongside it, tracing and analytics, evaluations, human-in-the-loop steps, API, CLI and SDK access, an embedded chatbot and teams with workspaces.

There were three building blocks:

Integrations from the docs: MCP client and server nodes with tool listing, SSE and authentication; connections to 100+ sources, tools, vector databases and memories; JavaScript and Python SDKs and a command line; a customisable embedded chat widget and shareable chatbots. Deployment could be self-hosted, including air-gapped, with vertical and horizontal scaling.

In plain terms: you dragged nodes onto a canvas, wired a model to tools and a knowledge base, tested in a chat pane and published an API endpoint or a widget.

Running it today

The README still documents installation. If you have a reason to run it (an existing flow you need to keep alive), it works as before.

# Node.js 20 or newer
npm install -g flowise
npx flowise start
# open http://localhost:3000

Docker Compose:

# clone the project, then in the docker folder:
cp .env.example .env
docker compose up -d

The repository is a monorepo with a Node backend (server), a React frontend (ui), third-party node integrations (components) and generated API docs. Development uses PNPM.

Cautions for continued use:

• No fixes. Security issues in Flowise or its dependencies will not be patched upstream. A tool that executes model-chosen actions and holds API keys deserves patches.
• Deprecated packages. npm packages and Docker images are marked deprecated.
• Model drift. New model versions and provider API changes will not be added upstream, so integrations may break.
• Network exposure. Do not expose an unpatched instance to the internet. Put it behind a VPN or an authenticating proxy.

If you must keep running it for a while, pin the version, isolate the host and plan a migration date.

Licence

GitHub reports the license as unrecognised because the LICENSE file is a mix. The file says content under the enterprise directory (packages/server/src/enterprise) and files with an explicit copyright notice have their own terms, third-party components keep their own licences, and everything else is Apache 2.0. For a fork, the Apache 2.0 part is yours to use under its terms; keep away from the enterprise directory unless you hold a licence.

Flowise Cloud pricing (as listed)

The site still lists three plans, with no date for their end:

Do not buy a new subscription to a product that is sunsetting.

What to move to

See AI agent frameworks for the code route.

How to migrate

1. Export every flow. Flowise stores flows as JSON; save them in git.
2. Write down each flow in words: trigger, model, tools, knowledge base, output. That description is the portable part.
3. List credentials and where each lives.
4. Rebuild one flow in the new tool and compare answers on a fixed set of test questions.
5. Move the knowledge base. Re-index documents in the new tool rather than copying a vector store between systems.
6. Switch traffic gradually, and keep Flowise running until the new flow passes the tests.
7. Shut down Flowise and rotate its keys.

Rebuilding a typical Flowise flow elsewhere

Most Flowise projects were one of two shapes. Here is how each maps to a maintained tool.

A document chatbot. In Flowise this was a Chatflow: a model, a document loader, a vector store and a chat endpoint. To rebuild it:

1. Choose where the documents will be indexed. A workflow tool such as n8n has retrieval nodes, and a code library such as LlamaIndex is built for it.
2. Re-index the documents in the new store.
3. Put the same system prompt in the new flow, then test against twenty real questions.
4. Replace the embed widget. Flowise offered a customisable chat widget; most platforms have their own, or you can call an API from your own page.

A small agent with tools. In Flowise this was an Agentflow or Assistant with a few tool nodes. To rebuild it:

1. List the tools and what each one does in a sentence.
2. In n8n, Zapier Agents or Make, add each as a step or a tool.
3. If you want to keep the logic in code, use a framework; see agentic AI frameworks.
4. Keep a human approval step on anything that writes data.

MCP gives you some portability here. Flowise had MCP client and server nodes, so tools exposed as MCP servers can be reused in other clients. See what are MCP servers.

If you want to keep using it

Some teams have good reasons to stay for a while: a working internal bot, a customer-facing widget, or a rule against moving things in the middle of a quarter. Be deliberate.

• Put a date on it. Decide when you will migrate and write it in the team calendar.
• Isolate it. Run it in a container with only the network access it needs, behind authentication.
• Limit its keys. Give it provider keys with spend caps and no access to anything else.
• Watch for forks. The maintainer's post encourages community forks. Before adopting one, check who maintains it, how often it releases, and whether it applies security fixes to dependencies.
• Do not add new flows. Every new flow adds migration work.

What to check in any visual builder

Flowise is a useful case study because the signals were visible before the announcement. Next time you evaluate a builder, look for these.

No signal is a guarantee. Together they tell you how much notice you are likely to get when something changes. For the wider platform choice, see AI agent platforms and build vs buy AI agents.

Quick answers

Will my published chatbot keep working? If you self-host, it runs until something around it breaks, such as a model API change. If you use Flowise Cloud, check the sunset page for dates.

Is there a hosted replacement? Zapier Agents and Make are hosted, and n8n offers a cloud plan, but none imports Flowise flows directly.

Should I fork it? Only if you have engineers who will maintain it. The maintainer's post invites forks, but a fork inherits all the upkeep.

What about my vector store? Re-index in the new tool from the original documents. Copying a store between systems rarely works cleanly.

What to tell your team

A short internal note helps. State that Flowise is archived and no longer patched, name the flows that depend on it, give the migration order and the date you will switch the old instance off, and say who owns each step. Add a rule that no new flows are built on it. Keep the note in your repository next to the exported flow files so it survives staff changes.

It also helps to note which flows are customer facing. Those need the earliest migration, because a broken integration there is visible to people outside the company, while an internal helper bot can wait a few weeks. Rank flows by who would notice if they stopped, then work from the top.

Our take

This is an editorial reading of the repository, the maintainer's announcement and the product pages, not a hands-on test.

Flowise was one of the friendliest ways to make a retrieval chatbot or a small agent, and its ending is a warning more than a verdict on the idea. The maintainer's own reasoning, that rigid low-code flows hit a limit and developers are turning to coding agents, is worth taking seriously. It does not mean visual builders are finished. It means a visual builder needs either a business that can keep going or a licence and a community that can carry the code, and Flowise has the licence but not yet the community.

If you have flows in production, do not panic and do not stall. Export, document, and move one flow a week to a maintained tool. If you are starting a new project, skip Flowise. Choose a platform with a long-term owner, and keep your prompts and tool descriptions in git.

Checklist

• Export all flows as JSON into version control
• Document trigger, model, tools and knowledge base for each flow
• Pin the Flowise version and keep it off the public internet
• Choose a replacement per flow type
• Rebuild one flow and compare answers on a fixed test set
• Rotate API keys when you switch off the old instance
• Do not start new subscriptions to Flowise Cloud