Flowise is shutting down: what now? Timeline, risks and the best alternatives in 2026

As of 15 September 2026

For several years, Flowise was one of the easiest ways for companies to build their own AI chatbots, RAG systems and AI workflows. Instead of having to program a complete application, developers and technically minded users could connect language models, databases, prompts, APIs and tools in a visual node editor.

Website chatbots were a particularly good fit: create a flow, connect a model and a knowledge base, test it, then drop the finished chat onto the site with an embed snippet.

That route is now closed: Flowise is officially no longer being developed.

The Flowise team announced the shutdown in summer 2026. At the end of August the project officially reached end of life.

Companies that already run Flowise in production therefore face a practical question:

What happens to existing Flowise chatbots, and which platform should you move to now?

The good news first: a self-hosted Flowise installation does not suddenly stop working. The topic should still not be ignored. Software that is no longer maintained becomes, over time, mainly a security and maintenance risk.

This article explains the background, the official timeline and the most important next steps. We also compare Langflow, Dify, Botpress, n8n and LangGraph as possible Flowise alternatives.

Why is Flowise being discontinued?

The Flowise team mainly explains the decision with a shift in how AI applications are built.

In the developers' view, AI models and coding agents in particular are becoming more capable. Developers are therefore increasingly using systems that write code themselves, change existing applications and implement complex processes programmatically.

In its farewell note, Flowise says in essence that classic, rigid low-code workflows quickly hit limits as complexity grows, and that developers are therefore moving towards coding agents.

That does not mean visual AI builders are disappearing in general.

On the contrary: platforms such as Langflow, Dify and n8n are still actively developing their visual AI features. Langflow, for example, was on version 1.12.x in mid-September 2026, and its GitHub project was still updated on 14 September.

Flowise's decision is therefore better read as a strategic choice by the Flowise team, not as the end of low-code or no-code AI platforms as such.

The official Flowise timeline

The Flowise team published three central milestones for the end of the project.

Date	Event	Meaning
29 July 2026	Announcement and code freeze	Active development stopped. New pull requests are no longer reviewed or merged.
10 August 2026	planned archival	According to the official sunset page, the GitHub repository was due to be archived on this date.
31 August 2026	End of life	The core team's official presence on GitHub and Discord ends.

The official Flowise sunset page names 10 August as the date for repository archival. GitHub actually shows 13 August 2026 as the archival date. The repository has been read-only since then.

The last Flowise version listed on GitHub is 3.1.4, released on 29 July 2026.

The source code is not disappearing. Flowise remains available under the Apache 2.0 license. Companies may still use the project, modify it and maintain their own forks. The Flowise team explicitly encourages existing users to do exactly that.

Does end of life mean my Flowise chatbot stops working?

No.

If you host Flowise yourself, you can generally keep running the existing installation.

A Docker setup, a VM or your own server does not stop working just because the GitHub repository has been archived.

The real problem appears over the longer term.

There is no regular further development, no normal bugfixes and, above all, no reliable future security-patch process from the original team.

That is a decisive difference between:

"The software still works"

and

"The software is secure and maintainable in the long run."

For an internal prototype, frozen software can still be acceptable for quite a while. For a publicly reachable customer chatbot, the situation looks different.

The biggest problem: security

Security should be taken especially seriously on existing Flowise installations.

On 29 July 2026, the same day development stopped, several security advisories were published. They include issues rated critical, including remote-code-execution problems.

A sandbox-escape vulnerability, for example, was present in Flowise up to and including version 3.1.2. GitHub names version 3.1.3 as the patched release. Another critical issue affected the custom MCP configuration and was also fixed in 3.1.3.

That does not mean Flowise 3.1.4 is automatically unsafe.

The real issue is a different one:

If a new vulnerability is found in Flowise tomorrow, there is no regular vendor left from whom you can automatically expect a patch.

The longer a publicly reachable Flowise system stays in production, the greater the operator's technical responsibility therefore becomes.

What should existing Flowise users do now?

There is no need to panic. A structured transition is much more useful than a rushed reimplementation.

We recommend the following approach:

1. Inventory the installation. Document the Flowise version, hosting, database, models in use, vector stores, APIs, custom tools, MCP connections, webhooks and website integrations.

2. Take a full backup. Back up the Flowise database, storage, environment variables and all chatflows or agentflows. Flowise can use SQLite, PostgreSQL, MySQL or MariaDB, for example. In the default setup, SQLite typically lives in the Flowise data directory.

3. Export every flow. A screenshot of the canvas is not enough. Also export the flow configurations as JSON. Document credentials separately. Flowise itself notes in its own migration processes that access data are not exported automatically.

4. Check the Flowise version. Systems on older versions should be reviewed against the published security advisories. Anyone still on 3.1.2 or older should take the critical issues seriously and, after a backup and tests, consider updating to a patched version. The last published release is 3.1.4.

5. Reduce the public attack surface. The Flowise admin interface should not sit unnecessarily open on the internet. A reverse proxy, authentication, tight network rules and, where useful, VPN access now matter more.

6. Pick a target platform and build it in parallel. Do not migrate on the open heart. The new chatbot should first be built alongside Flowise.

7. Test with real questions. Use typical customer queries and compare the old and new bot on answer quality, sources, retrieval quality, speed, cost and error behaviour. Only then should the website be switched to the new system.

Which Flowise alternative is the best?

There is no universal winner. The best platform depends on what Flowise was used for.

A classic website chatbot with RAG and a knowledge base calls for different tools than a highly complex autonomous agent.

A first overview:

Platform	Visual builder	RAG	Website widget	Self-hosting	Fit as a direct Flowise replacement
Langflow	Very good	Very good	Yes	Yes	Very high
Dify	Very good	Very good	Yes	Yes	Very high
Botpress	Very good	Good	Very good	Not for new installs	High in the cloud
n8n	Very good	Good	Yes	Yes	Medium to high
LangGraph	No, code-based	Very flexible	Build your own	Yes	For developers

Alternative 1: Langflow, the most obvious Flowise successor

If you liked Flowise because you could assemble AI applications visually from nodes, look at Langflow first.

The interaction model is very similar. Components are placed on a visual canvas and connected. Models, prompts, tools, data sources and vector stores can be composed into a flow that way.

Langflow is currently under active development and is released under the MIT license. It can be self-hosted, including via Docker.

Can Langflow do RAG?

Yes, and quite extensively.

Langflow now even ships its own Vector Store RAG template.

It consists of a data flow for loading, splitting and embedding documents, plus a retriever flow that, for user questions, finds matching passages in the vector store and passes them to the language model.

Vector stores and embedding models are a built-in part of the Langflow architecture. Langflow 1.12 also supports its own knowledge bases and additional vector-store bundles.

Can Langflow embed a chatbot on a website?

Here too the answer is yes.

That is especially relevant for former Flowise users.

On a finished flow you can choose Share → Embed into site in Langflow. Langflow then generates a ready-made snippet for the website.

The widget is embedded as a langflow-chat web component. Plain HTML, React and Angular are supported.

Functionally, Langflow is therefore very close to a typical Flowise setup:

Website → chat widget → Langflow → RAG → vector store → LLM → answer

Advantages of Langflow

The biggest advantage is the similarity to Flowise. Teams already used to nodes, chains, embeddings and vector stores do not have to change how they think.

On top of that come self-hosting, a very permissive MIT license, a ready-made RAG template, APIs and the existing website widget.

Drawbacks of Langflow

You should not expect an automatic one-to-one migration of a Flowise JSON export. The logical architecture can be reused, but the flows usually have to be rebuilt.

Langflow is also currently changing parts of its component and bundle structure quite quickly. That is basically a plus for an actively developed project, but it creates extra test work on production installs when you update.

Our take: For teams that want to change as little as possible about their existing Flowise working model, Langflow is currently probably the most interesting candidate.

Alternative 2: Dify, especially interesting for RAG and knowledge bases

Dify takes a slightly different approach.

While Langflow feels a lot like a visual, technical flow builder, Dify feels more like a complete platform for production LLM applications.

Dify offers workflows, chatflows, agents, model management, knowledge bases, plugins and monitoring.

It is particularly interesting for large knowledge bases. The platform has its own knowledge and knowledge-pipeline features and supports embeddings, retrieval and reranking. The plugin system can also feed external data sources into knowledge bases.

A website chatbot with Dify

For someone leaving Flowise, it matters that Dify also offers ready-made website integrations.

A published Dify app can be added to an existing site as a chat bubble, via an iframe, or with more advanced JavaScript control. Dify generates an app token and the corresponding embed configuration for that.

That makes Dify a strong fit for support chatbots and RAG applications on websites.

Self-hosting

Dify can be self-hosted. The official documentation describes a Docker Compose setup. The current architecture, though, consists of a whole set of services, including API, worker, web frontend, plugin daemon, database, Redis, vector store and sandbox components.

Dify is therefore more powerful, but also heavier on infrastructure, than a small Flowise install.

Check the license

There is an important difference from Flowise and Langflow here.

Dify uses a modified Apache 2.0 license with extra conditions. Among other things there are restrictions on running it as a multi-tenant service and on removing certain branding or copyright elements from the Dify frontend.

For a normal in-house company chatbot that need not be a problem. Anyone who wants to offer Dify as their own SaaS platform for customers should read the license terms carefully first.

Advantages and drawbacks

Dify scores especially well on knowledge and RAG features, a mature web-app model and a ready-made website embed.

In return, self-hosting is more complex and the license is less free than Langflow's MIT license.

Our take: For knowledge-based company chatbots, Dify is one of the most interesting Flowise alternatives.

Alternative 3: Botpress, strong on the finished website chat

If you mainly want a comfortable website chatbot and care less about full self-hosting, look at Botpress.

Botpress offers a very mature web chat. A published bot can be added to a site with a few script tags. The widget can also be configured or embedded into a specific HTML element.

Via JavaScript the site can also open or close the chat, send messages or pass custom events to the bot.

Knowledge bases are available as well. Botpress can use web pages, documents and files as knowledge sources, for example.

The decisive drawback: self-hosting

This is where current Botpress differs clearly from the old Flowise model.

The previously self-hostable Botpress v12 platform has been discontinued. Botpress states explicitly that new self-hosted or local installations are no longer offered and that new projects should be built on Botpress Cloud.

For companies with strict on-premise or self-hosting requirements, Botpress is therefore not a direct Flowise alternative.

Our take: Very interesting for companies that need a professional website chatbot quickly and can live with a cloud platform.

Alternative 4: n8n, when the chatbot should also run processes

n8n is known mainly as a workflow automation platform. By now, though, n8n also has extensive AI features.

These include AI agents, various language models, memory, embeddings, retrievers and many vector stores.

n8n now also documents complete RAG workflows. Data are loaded into a vector store, turned into embeddings and later retrieved either directly or through an AI agent.

Website chatbot

With the Chat Trigger, a workflow can be published as a chatbot.

n8n distinguishes between a hosted chat and an embedded chat. In embedded mode you can use the official n8n chat widget or build your own interface that calls the chat webhook.

So n8n can replace a Flowise website chatbot.

Its real strength sits somewhere else, though.

If a chatbot should not only answer questions but also, for example, read CRM data, create support tickets, send emails, update databases or trigger other business processes, n8n becomes very interesting.

Check the license

n8n is source available, but explicitly not classic open source in the OSI sense.

It uses the Sustainable Use License. Self-hosting and many internal company uses are allowed. n8n even names an embedded AI chatbot with company credentials as a permitted example. Certain commercial embedded or white-label scenarios, however, come with extra license requirements.

Our take: Especially strong if the chatbot is meant to become an AI assistant that connects many company systems.

Alternative 5: LangGraph, if you want to leave low code on purpose

A completely different direction is LangGraph.

LangGraph is not a visual Flowise replacement. It is a code framework for orchestrating stateful agents and workflows.

LangGraph distinguishes between predefined workflows and agents that work dynamically. The framework offers persistence, streaming and mechanisms for complex agent flows, among other things.

LangGraph itself is released under the MIT license.

The big advantage is flexibility.

Instead of constructing an application inside the limits of a visual builder, you develop the actual AI application as software.

The drawback is obvious: you do not automatically get a finished website chatbot or a simple "embed into website". Frontend, API, authentication and deployment have to be built by you or solved with extra products.

Our take: For larger, business-critical AI applications with an in-house development team, LangGraph can be the more robust architecture in the long run. For a simple RAG website chatbot it would often be unnecessarily complex.

Langflow or Dify: which is better for former Flowise users?

For many Flowise users the decision will probably come down to Langflow or Dify.

The two systems overlap, but they put the emphasis in different places.

Criterion	Langflow	Dify
Similarity to Flowise	Very high	High
Visual node editor	Very technical and flexible	Very good
RAG	Very good	Very good
Knowledge management	Good	Very good
Website chat widget	Yes	Yes
JavaScript/HTML embed	Yes	Yes
Self-hosting	Yes	Yes
Setup effort	Rather moderate	Higher
License	MIT	Modified Apache 2.0
For technical AI flows	Very good	Good
For finished business chatbots	Good	Very good

If you want to continue your existing Flowise setup in as similar a way as possible, try Langflow first.

If you instead need to manage many documents and knowledge bases and want a more product-shaped chatbot platform, you should look at Dify just as closely.

How much work is a migration from Flowise?

Unfortunately there is no universal "import Flowise" button.

A Flowise flow should therefore not be treated as a file that you simply copy from application A to application B.

It is better to migrate the logic of the flow.

A typical Flowise RAG chatbot, for example, is made of the following concepts:

Flowise component	Matching concept in Langflow/Dify
Chat Input	User input / chat input
Document Loader	File/data loader or knowledge source
Text Splitter	Chunking
Embeddings	Embedding model
Pinecone/Qdrant/Chroma etc.	Vector store
Retriever	Retriever / knowledge retrieval
Prompt Template	Prompt
Chat Model	LLM
Memory	Conversation memory
Custom Tool	Tool/API/plugin
Chat Output	Chat output
Flowise Embed	Langflow/Dify website embed

That usually makes a migration less complicated than it first appears.

The technology behind a classic RAG system does not change in principle.

Documents are loaded, split into passages, turned into vectors by an embedding model and stored in a vector database. When a question arrives, the most relevant passages are retrieved and passed to the language model together with the user question.

Both Langflow and Dify support exactly that flow. How retrieval and agents go further than a single search is covered in Agentic RAG.

Do the data in the vector database have to be migrated as well?

Not necessarily.

If you already use an external Qdrant, Pinecone, PostgreSQL/pgvector or similar database, and the new platform can connect to that same database cleanly, you may be able to keep the existing infrastructure.

You should still check whether both systems use the same embedding models, dimensions, collections, metadata and retrieval methods.

In many cases, rebuilding the index is the cleaner option.

The original documents should therefore exist and be backed up independently of Flowise.

A vector store should never be the only copy of your knowledge base.

What about the existing JavaScript on the website?

That is usually not a big problem either.

The website is often only the outermost layer.

Today the architecture may look like this:

Website → Flowise embed → Flowise chatflow → vector DB → LLM

After a migration it could look like this, for example:

Website → Langflow chat → Langflow flow → vector DB → LLM

or:

Website → Dify chat widget → Dify chatflow → knowledge base → LLM

You therefore do not normally have to change the whole website.

In most cases you only remove the old Flowise embed snippet and replace it with the new JavaScript or web-component code.

Langflow generates its embed code directly via Share → Embed into site.

Dify offers a chat-bubble embed, iframe integration and JavaScript configuration.

So there are good successors for exactly this use case.

Should you just keep maintaining Flowise yourself?

Technically that is possible.

Flowise remains under Apache 2.0, and the team explicitly asks companies to create their own forks if they need to.

For large companies with their own software and security team, that can be a real option.

You then effectively take on part of the original vendor's role, though.

New dependencies have to be tested, vulnerabilities analysed, patches written, framework versions updated and compatibility issues fixed.

For most small and mid-sized companies, a migration is therefore likely to be cheaper in the long run than maintaining their own Flowise fork.

Be careful when looking for a community fork

Because Flowise had a large community, one or more community forks may emerge.

You should not decide solely by which fork has the most GitHub stars.

What matters more are continuous releases, several active maintainers, understandable security processes, fast reactions to vulnerabilities and recognisable long-term governance.

Until a clear, lastingly maintained successor has established itself, a community fork should not automatically be treated as the safest migration strategy.

Our recommendation for existing Flowise chatbots

If you run a working Flowise chatbot today, you do not have to switch it off tomorrow.

You should also no longer treat Flowise as a platform on which to build new business-critical features over the next few years.

For a typical RAG chatbot on a company website, we would currently try Langflow and Dify first.

If you want to keep as much of the existing Flowise experience as possible, Langflow has a big advantage: a visual node editor, RAG, self-hosting and a ready-made website embed are all there. The project is also under MIT and is currently being developed actively.

If managing documents, knowledge bases and published chat applications sits more in the foreground, Dify is a very interesting alternative. Dify also comes with self-hosting, knowledge pipelines and ready-made website integrations.

Botpress is mainly a fit for companies that want a comfortable cloud product with a strong web chat.

n8n becomes interesting if the AI chatbot should automate company processes at the same time.

And LangGraph is worth considering if a simple chatbot is meant to become a long-term, in-house AI application.

Whether a website chatbot is worth it at all, and what matters for guardrails, retrieval and handing over to a human, is the subject of Chatbots on your own website.

Conclusion: Flowise is over, the idea behind it is not

The end of Flowise is annoying for existing users, but it is not a reason for rushed decisions.

The core concepts Flowise was built on remain:

LLMs, RAG, embeddings, vector stores, tools, APIs, agents and visual workflows.

And for almost all of these components there are capable alternatives by now.

The most important thing is therefore not to wait this out.

Existing installations should be backed up and documented. Security risks should be reviewed. At the same time, a new platform should be built in parallel and tested with real use cases.

For classic Flowise users, Langflow is currently the most obvious successor.

For more knowledge-centric chatbots, Dify is a particularly interesting alternative.

And if you mainly used Flowise to put a RAG chatbot on a website via JavaScript, you do not have to give that idea up.

There are good solutions for that after Flowise as well. If you want to work through the move for an existing install, get in touch.