Flowise wird eingestellt: Was jetzt? Zeitplan, Risiken und die besten Alternativen 2026

Stand: 15. September 2026

Flowise war in den vergangenen Jahren für viele Unternehmen eine der einfachsten Möglichkeiten, eigene KI-Chatbots, RAG-Systeme und AI-Workflows aufzubauen. Statt eine komplette Anwendung selbst programmieren zu müssen, konnten Entwickler und technisch versierte Anwender Sprachmodelle, Datenbanken, Prompts, APIs und Tools über einen visuellen Node-Editor miteinander verbinden.

Besonders attraktiv war Flowise für Website-Chatbots: Flow erstellen, Modell und Wissensdatenbank anbinden, testen und den fertigen Chat anschließend über einen Embed-Code in die eigene Website integrieren.

Damit ist nun allerdings Schluss: Flowise wird offiziell nicht mehr weiterentwickelt.

Das Flowise-Team hat im Sommer 2026 angekündigt, die Entwicklung einzustellen. Ende August erreichte das Projekt offiziell sein End of Life.

Für Unternehmen, die Flowise bereits produktiv einsetzen, stellt sich deshalb eine wichtige Frage:

Was passiert mit bestehenden Flowise-Chatbots, und auf welche Plattform sollte man jetzt wechseln?

Die gute Nachricht vorweg: Eine selbst gehostete Flowise-Installation hört nicht plötzlich auf zu funktionieren. Trotzdem sollte man das Thema nicht ignorieren. Denn ein nicht mehr gepflegtes System wird mit zunehmender Zeit vor allem zu einem Sicherheits- und Wartungsrisiko.

Dieser Artikel erklärt den Hintergrund, den offiziellen Zeitplan und die wichtigsten Handlungsmöglichkeiten. Außerdem vergleichen wir Langflow, Dify, Botpress, n8n und LangGraph als mögliche Flowise-Alternativen.

Warum wird Flowise eingestellt?

Das Flowise-Team begründet die Entscheidung vor allem mit einer Veränderung bei der Entwicklung von KI-Anwendungen.

Nach Einschätzung der Entwickler werden AI-Modelle und insbesondere Coding Agents immer leistungsfähiger. Entwickler setzen deshalb zunehmend Systeme ein, die selbst Code schreiben, bestehende Anwendungen verändern und komplexe Abläufe programmatisch umsetzen können.

Flowise schreibt in seiner Abschiedserklärung sinngemäß, dass klassische starre Low-Code-Workflows bei steigender Komplexität schnell an Grenzen stoßen und Entwickler deshalb zunehmend Coding Agents verwenden.

Das ist allerdings nicht gleichbedeutend damit, dass visuelle AI-Builder grundsätzlich verschwinden.

Im Gegenteil: Plattformen wie Langflow, Dify und n8n entwickeln ihre visuellen AI-Funktionen weiterhin aktiv weiter. Langflow beispielsweise war Mitte September 2026 bei Version 1.12.x, und sein GitHub-Projekt wurde noch am 14. September aktualisiert.

Die Entscheidung von Flowise ist daher eher als strategische Entscheidung des Flowise-Teams zu verstehen, nicht als allgemeines Ende von Low-Code- oder No-Code-AI-Plattformen.

Der offizielle Flowise-Zeitplan

Das Flowise-Team veröffentlichte drei zentrale Meilensteine für das Ende des Projekts.

Datum	Ereignis	Bedeutung
29. Juli 2026	Announcement und Code Freeze	Die aktive Weiterentwicklung wurde eingestellt. Neue Pull Requests werden nicht mehr geprüft oder übernommen.
10. August 2026	geplante Archivierung	Laut offizieller Sunset-Seite sollte das GitHub-Repository zu diesem Zeitpunkt archiviert werden.
31. August 2026	End of Life	Die offizielle Präsenz des Core-Teams auf GitHub und Discord endet.

Die offizielle Flowise-Sunset-Seite nennt den 10. August als Termin für die Repository-Archivierung. Tatsächlich zeigt GitHub den 13. August 2026 als Archivierungsdatum an. Das Repository ist seitdem read-only.

Die letzte auf GitHub aufgeführte Flowise-Version ist 3.1.4, veröffentlicht am 29. Juli 2026.

Der Quellcode verschwindet jedoch nicht. Flowise bleibt unter der Apache-2.0-Lizenz verfügbar. Unternehmen dürfen das Projekt also weiterhin einsetzen, verändern und auch eigene Forks davon pflegen. Genau dazu ermutigt das Flowise-Team bestehende Anwender ausdrücklich.

Bedeutet das End of Life, dass mein Flowise-Chatbot nicht mehr funktioniert?

Nein.

Wer Flowise selbst hostet, kann die bestehende Installation grundsätzlich weiterhin betreiben.

Eine Docker-Installation, eine VM oder ein eigener Server hört nicht auf zu funktionieren, nur weil das GitHub-Repository archiviert wurde.

Das eigentliche Problem entsteht langfristig.

Es gibt keine reguläre Weiterentwicklung mehr, keine normalen Bugfixes und vor allem keinen verlässlichen zukünftigen Security-Patch-Prozess des ursprünglichen Teams.

Das macht einen entscheidenden Unterschied zwischen:

„Die Software funktioniert noch“

und

„Die Software ist langfristig sicher und wartbar.“

Für einen internen Prototyp kann eine eingefrorene Software noch längere Zeit akzeptabel sein. Bei einem öffentlich erreichbaren Kundenchatbot sieht die Situation anders aus.

Das größte Problem: Sicherheit

Das Thema Sicherheit sollte bei bestehenden Flowise-Installationen besonders ernst genommen werden.

Noch am 29. Juli 2026, also am Tag des Entwicklungsstopps, wurden mehrere Security Advisories veröffentlicht. Darunter befinden sich auch als Critical eingestufte Schwachstellen, einschließlich Remote-Code-Execution-Problemen.

Beispielsweise war eine Sandbox-Escape-Schwachstelle in Flowise bis einschließlich Version 3.1.2 vorhanden. GitHub nennt Version 3.1.3 als gepatchte Version. Eine weitere kritische Schwachstelle betraf die Custom-MCP-Konfiguration und wurde ebenfalls in 3.1.3 behoben.

Das bedeutet nicht, dass Flowise 3.1.4 automatisch unsicher ist.

Das eigentliche Problem ist ein anderes:

Wenn morgen eine neue Schwachstelle in Flowise gefunden wird, gibt es keinen regulären Hersteller mehr, von dem man automatisch einen Patch erwarten kann.

Je länger ein öffentlich erreichbares Flowise-System weiterbetrieben wird, desto größer wird daher die technische Verantwortung des Betreibers.

Was sollten bestehende Flowise-Nutzer jetzt tun?

Panik ist nicht notwendig. Ein strukturierter Übergang ist deutlich sinnvoller als eine überhastete Neuimplementierung.

Wir empfehlen folgende Vorgehensweise:

1. Installation inventarisieren. Dokumentieren Sie Flowise-Version, Hosting, Datenbank, verwendete Modelle, Vector Stores, APIs, Custom Tools, MCP-Verbindungen, Webhooks und Website-Integrationen.

2. Vollständiges Backup erstellen. Sichern Sie Flowise-Datenbank, Storage, Umgebungsvariablen und alle Chatflows bzw. Agentflows. Flowise kann beispielsweise SQLite, PostgreSQL, MySQL oder MariaDB verwenden. Bei der Standardinstallation befindet sich SQLite typischerweise im Flowise-Datenverzeichnis.

3. Alle Flows exportieren. Ein visueller Screenshot allein reicht nicht. Exportieren Sie die Flow-Konfigurationen zusätzlich als JSON. Dokumentieren Sie Credentials separat. Flowise weist selbst bei seinen eigenen Migrationsprozessen darauf hin, dass Zugangsdaten nicht automatisch mit exportiert werden.

4. Flowise-Version überprüfen. Systeme auf älteren Versionen sollten insbesondere auf die veröffentlichten Security Advisories geprüft werden. Wer beispielsweise noch 3.1.2 oder älter verwendet, sollte die kritischen Schwachstellen beachten und nach Backup und Tests ein Update auf eine entsprechend gepatchte Version prüfen. Die letzte veröffentlichte Version ist 3.1.4.

5. Öffentliche Angriffsfläche reduzieren. Das Flowise-Administrationsinterface sollte nicht unnötig offen im Internet stehen. Reverse Proxy, Authentifizierung, restriktive Netzwerkregeln und gegebenenfalls VPN-Zugriff werden jetzt wichtiger.

6. Eine Zielplattform auswählen und parallel aufbauen. Migrieren Sie nicht direkt am offenen Herzen. Der neue Chatbot sollte zunächst parallel zu Flowise aufgebaut werden.

7. Mit realen Fragen testen. Verwenden Sie typische Kundenanfragen und vergleichen Sie alten und neuen Bot hinsichtlich Antwortqualität, Quellen, Retrieval-Qualität, Geschwindigkeit, Kosten und Fehlerverhalten. Erst anschließend sollte die Website auf das neue System umgestellt werden.

Welche Flowise-Alternative ist die beste?

Es gibt keinen universellen Sieger. Welche Plattform am besten passt, hängt davon ab, wofür Flowise bisher eingesetzt wurde.

Für einen klassischen Website-Chatbot mit RAG und Wissensdatenbank sind andere Lösungen sinnvoll als für einen hochkomplexen autonomen Agenten.

Ein erster Überblick:

Plattform	Visueller Builder	RAG	Website-Widget	Self-Hosting	Eignung als direkter Flowise-Ersatz
Langflow	Sehr gut	Sehr gut	Ja	Ja	Sehr hoch
Dify	Sehr gut	Sehr gut	Ja	Ja	Sehr hoch
Botpress	Sehr gut	Gut	Sehr gut	Für neue Installationen nein	Hoch bei Cloud
n8n	Sehr gut	Gut	Ja	Ja	Mittel bis hoch
LangGraph	Nein, codebasiert	Sehr flexibel	Eigenentwicklung	Ja	Für Entwickler

Alternative 1: Langflow, der naheliegendste Flowise-Nachfolger

Wer Flowise mochte, weil man AI-Anwendungen visuell aus Nodes zusammenbauen konnte, sollte sich Langflow zuerst ansehen.

Das Bedienkonzept ist sehr ähnlich. Komponenten werden auf einer visuellen Arbeitsfläche platziert und miteinander verbunden. Modelle, Prompts, Tools, Datenquellen und Vector Stores lassen sich damit zu einem Flow zusammensetzen.

Langflow wird aktuell aktiv entwickelt und steht unter der MIT-Lizenz. Es kann unter anderem per Docker selbst gehostet werden.

Kann Langflow RAG?

Ja, und zwar sehr umfangreich.

Langflow enthält inzwischen sogar ein eigenes Vector Store RAG Template.

Dieses besteht aus einem Datenfluss zum Einlesen, Aufteilen und Einbetten der Dokumente sowie einem Retriever-Flow, der bei Benutzerfragen passende Dokumentabschnitte aus dem Vector Store sucht und an das Sprachmodell weitergibt.

Vector Stores und Embedding-Modelle sind ein fester Bestandteil der Langflow-Architektur. Langflow 1.12 unterstützt außerdem eigene Knowledge Bases sowie zusätzliche Vector-Store-Bundles.

Kann Langflow einen Chatbot in eine Website einbinden?

Auch hier lautet die Antwort: Ja.

Das ist für ehemalige Flowise-Anwender besonders interessant.

Bei einem fertigen Flow kann man in Langflow Share → Embed into site auswählen. Langflow erzeugt anschließend einen fertigen Code-Snippet für die Website.

Das Widget wird als langflow-chat Web Component eingebunden. Unterstützt werden normales HTML, React und Angular.

Damit ist Langflow funktional sehr nah an einem typischen Flowise-Szenario:

Website → Chat-Widget → Langflow → RAG → Vector Store → LLM → Antwort

Vorteile von Langflow

Der größte Vorteil ist die Ähnlichkeit zu Flowise. Teams, die mit Nodes, Chains, Embeddings und Vector Stores bereits vertraut sind, müssen ihre Denkweise nicht komplett ändern.

Hinzu kommen Self-Hosting, eine sehr permissive MIT-Lizenz, ein fertiges RAG-Template, APIs und das vorhandene Website-Widget.

Nachteile von Langflow

Eine automatische 1:1-Migration eines Flowise-JSON-Exports sollte man nicht erwarten. Die logische Architektur kann übernommen werden, die Flows müssen aber normalerweise neu aufgebaut werden.

Außerdem verändert Langflow aktuell Teile seiner Komponenten- und Bundle-Struktur relativ schnell. Das ist bei einem aktiv entwickelten Projekt grundsätzlich positiv, erzeugt bei produktiven Installationen aber zusätzlichen Testaufwand bei Updates.

Unsere Einschätzung: Für Teams, die möglichst wenig von ihrem bisherigen Flowise-Arbeitsmodell verändern möchten, ist Langflow derzeit wahrscheinlich der interessanteste Kandidat.

Alternative 2: Dify, besonders interessant für RAG und Wissensdatenbanken

Dify verfolgt einen etwas anderen Ansatz.

Während Langflow sehr stark an einen visuellen technischen Flow-Builder erinnert, wirkt Dify mehr wie eine komplette Plattform für produktive LLM-Anwendungen.

Dify bietet Workflows, Chatflows, Agents, Modellverwaltung, Knowledge Bases, Plugins und Monitoring.

Gerade bei umfangreichen Wissensdatenbanken ist Dify interessant. Die Plattform besitzt eigene Knowledge- und Knowledge-Pipeline-Funktionen und unterstützt Embeddings, Retrieval und Reranking. Das Plugin-System kann außerdem externe Datenquellen in Knowledge Bases einspeisen.

Website-Chatbot mit Dify

Für einen Flowise-Umsteiger ist besonders wichtig, dass auch Dify fertige Website-Integrationen anbietet.

Eine veröffentlichte Dify-App kann als Chat Bubble, per Iframe oder über weitergehende JavaScript-Steuerung in eine bestehende Website integriert werden. Dify erzeugt dafür einen App-Token und entsprechende Embed-Konfigurationen.

Damit eignet sich Dify sehr gut für Support-Chatbots und RAG-Anwendungen auf Websites.

Self-Hosting

Dify lässt sich selbst hosten. Die offizielle Dokumentation beschreibt eine Docker-Compose-Installation. Die aktuelle Architektur besteht allerdings aus einer ganzen Reihe von Services, darunter API, Worker, Webfrontend, Plugin-Daemon, Datenbank, Redis, Vector Store und Sandbox-Komponenten.

Dify ist damit mächtiger, aber auch infrastrukturell umfangreicher als eine kleine Flowise-Installation.

Lizenz beachten

Hier gibt es einen wichtigen Unterschied zu Flowise und Langflow.

Dify verwendet eine modifizierte Apache-2.0-Lizenz mit zusätzlichen Bedingungen. Unter anderem existieren Einschränkungen beim Betrieb als Multi-Tenant-Service und bei der Entfernung bestimmter Branding- beziehungsweise Copyright-Elemente aus dem Dify-Frontend.

Für einen normalen unternehmenseigenen Chatbot muss das kein Problem sein. Wer Dify jedoch als eigene SaaS-Plattform für Kunden anbieten möchte, sollte die Lizenzbedingungen vorab genau prüfen.

Vorteile und Nachteile

Dify punktet insbesondere mit sehr guten Knowledge- und RAG-Funktionen, einem ausgereiften Web-App-Konzept und einem fertigen Website-Embed.

Dafür ist das Self-Hosting komplexer und die Lizenz weniger frei als die MIT-Lizenz von Langflow.

Unsere Einschätzung: Für wissensbasierte Unternehmens-Chatbots ist Dify eine der interessantesten Flowise-Alternativen.

Alternative 3: Botpress, stark beim fertigen Website-Chat

Wer vor allem einen komfortablen Website-Chatbot sucht und weniger Wert auf vollständiges Self-Hosting legt, sollte sich Botpress ansehen.

Botpress bietet einen sehr ausgereiften Webchat. Ein veröffentlichter Bot kann über wenige Script-Tags in eine Website integriert werden. Darüber hinaus lässt sich das Widget konfigurieren oder in ein bestimmtes HTML-Element einbetten.

Per JavaScript kann die Website den Chat außerdem öffnen, schließen, Nachrichten senden oder eigene Events an den Bot übergeben.

Auch Wissensdatenbanken sind vorhanden. Botpress kann beispielsweise Webseiten, Dokumente und Dateien als Knowledge Sources verwenden.

Der entscheidende Nachteil: Self-Hosting

Hier unterscheidet sich das aktuelle Botpress deutlich vom alten Flowise-Modell.

Die früher selbst hostbare Botpress-v12-Plattform wurde eingestellt. Botpress erklärt ausdrücklich, dass neue Self-Hosted- beziehungsweise lokale Installationen nicht mehr angeboten werden und neue Projekte auf Botpress Cloud umgesetzt werden sollen.

Für Unternehmen mit strikten On-Premise- oder Self-Hosting-Anforderungen ist Botpress deshalb keine direkte Flowise-Alternative.

Unsere Einschätzung: Sehr interessant für Unternehmen, die schnell einen professionellen Website-Chatbot benötigen und mit einer Cloud-Plattform leben können.

Alternative 4: n8n, wenn der Chatbot auch Prozesse ausführen soll

n8n kennt man vor allem als Workflow-Automatisierungsplattform. Inzwischen besitzt n8n jedoch umfangreiche AI-Funktionen.

Dazu gehören AI Agents, verschiedene Sprachmodelle, Memory, Embeddings, Retriever und zahlreiche Vector Stores.

n8n dokumentiert mittlerweile auch vollständige RAG-Workflows. Daten werden dabei in einen Vector Store geladen, mit Embeddings versehen und später entweder direkt oder durch einen AI Agent abgerufen.

Website-Chatbot

Mit dem Chat Trigger kann ein Workflow als Chatbot veröffentlicht werden.

n8n unterscheidet zwischen einem gehosteten Chat und einem Embedded Chat. Beim Embedded-Modus kann das offizielle n8n-Chat-Widget verwendet oder eine eigene Oberfläche entwickelt werden, die den Chat-Webhook aufruft.

Damit kann n8n durchaus einen Flowise-Website-Chatbot ersetzen.

Die Stärke von n8n liegt aber an einer anderen Stelle.

Wenn ein Chatbot nicht nur Fragen beantworten soll, sondern beispielsweise CRM-Daten lesen, Support-Tickets erzeugen, E-Mails versenden, Datenbanken aktualisieren oder andere Geschäftsprozesse auslösen soll, ist n8n ausgesprochen interessant.

Lizenz beachten

n8n ist source available, aber ausdrücklich kein klassisches Open Source im Sinne der OSI.

Es verwendet die Sustainable Use License. Self-Hosting und viele interne Unternehmensanwendungen sind erlaubt. n8n nennt sogar ausdrücklich einen eingebetteten AI-Chatbot mit Unternehmens-Credentials als zulässiges Beispiel. Für bestimmte kommerzielle Embedded- oder White-Label-Szenarien gelten jedoch zusätzliche Lizenzanforderungen.

Unsere Einschätzung: Besonders stark, wenn aus dem Chatbot langfristig ein AI-Assistent werden soll, der viele Unternehmenssysteme miteinander verbindet.

Alternative 5: LangGraph, wenn man Low Code bewusst verlassen möchte

Eine völlig andere Richtung ist LangGraph.

LangGraph ist kein visueller Flowise-Ersatz. Es ist ein Code-Framework zur Orchestrierung von zustandsbehafteten Agents und Workflows.

LangGraph unterscheidet dabei zwischen vorher festgelegten Workflows und dynamisch arbeitenden Agents. Das Framework bietet unter anderem Persistenz, Streaming sowie Mechanismen für komplexe Agentenabläufe.

LangGraph selbst steht unter der MIT-Lizenz.

Der große Vorteil liegt in der Flexibilität.

Statt eine Anwendung innerhalb der Möglichkeiten eines visuellen Builders zu konstruieren, entwickelt man die eigentliche AI-Anwendung als Software.

Der Nachteil ist offensichtlich: Ein fertiger Website-Chatbot oder ein einfaches „Embed into website“ bekommt man nicht automatisch. Frontend, API, Authentication und Deployment müssen entsprechend selbst aufgebaut oder über zusätzliche Produkte gelöst werden.

Unsere Einschätzung: Für größere, geschäftskritische AI-Anwendungen mit eigenem Entwicklungsteam kann LangGraph langfristig die robustere Architektur sein. Für einen einfachen RAG-Website-Chatbot wäre es häufig unnötig komplex.

Langflow oder Dify: Was ist für ehemalige Flowise-Nutzer besser?

Für viele Flowise-Anwender läuft die Entscheidung wahrscheinlich auf Langflow oder Dify hinaus.

Die beiden Systeme überschneiden sich, setzen aber unterschiedliche Schwerpunkte.

Kriterium	Langflow	Dify
Ähnlichkeit zu Flowise	Sehr hoch	Hoch
Visueller Node-Editor	Sehr technisch und flexibel	Sehr gut
RAG	Sehr gut	Sehr gut
Knowledge Management	Gut	Sehr gut
Website Chat Widget	Ja	Ja
JavaScript/HTML Embed	Ja	Ja
Self-Hosting	Ja	Ja
Installationsaufwand	Eher moderat	Höher
Lizenz	MIT	Modifizierte Apache 2.0
Für technische AI-Flows	Sehr gut	Gut
Für fertige Business-Chatbots	Gut	Sehr gut

Wer seinen bisherigen Flowise-Aufbau möglichst ähnlich weiterführen möchte, sollte Langflow zuerst testen.

Wer dagegen viele Dokumente und Knowledge Bases verwalten möchte und eine stärker produktorientierte Chatbot-Plattform sucht, sollte Dify ebenfalls sehr genau ansehen.

Wie aufwendig ist eine Migration von Flowise?

Leider gibt es keinen universellen „Flowise importieren“-Button.

Ein Flowise-Flow sollte deshalb nicht als Datei betrachtet werden, die einfach von Anwendung A nach Anwendung B kopiert wird.

Besser ist es, die Logik des Flows zu migrieren.

Ein typischer Flowise-RAG-Chatbot besteht beispielsweise aus folgenden Konzepten:

Flowise-Komponente	Entsprechendes Konzept bei Langflow/Dify
Chat Input	User Input / Chat Input
Document Loader	File/Data Loader bzw. 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

Dadurch wird eine Migration meist weniger kompliziert, als sie zunächst erscheint.

Die Technologie hinter einem klassischen RAG-System verändert sich nämlich nicht grundsätzlich.

Dokumente werden geladen, in Abschnitte zerlegt, durch ein Embedding-Modell in Vektoren übersetzt und in einer Vector Database gespeichert. Bei einer Frage werden die relevantesten Abschnitte gesucht und zusammen mit der Benutzerfrage an das Sprachmodell übergeben.

Genau diesen Ablauf unterstützen sowohl Langflow als auch Dify. Wie Retrieval und Agenten darüber hinaus zusammenspielen, beschreiben wir in Agentisches RAG.

Müssen auch die Daten aus der Vector Database migriert werden?

Nicht zwingend.

Wenn beispielsweise bereits eine externe Qdrant-, Pinecone-, PostgreSQL/pgvector- oder vergleichbare Datenbank verwendet wird und die neue Plattform dieselbe Datenbank sauber anbinden kann, lässt sich die bestehende Infrastruktur möglicherweise weiterverwenden.

Trotzdem sollte geprüft werden, ob beide Systeme dieselben Embedding-Modelle, Dimensionen, Collections, Metadaten und Retrieval-Verfahren verwenden.

In vielen Fällen kann ein Neuaufbau des Index sinnvoller sein.

Die ursprünglichen Dokumente sollten deshalb unabhängig von Flowise vorhanden und gesichert sein.

Ein Vector Store sollte niemals die einzige Kopie der eigenen Wissensbasis darstellen.

Was ist mit dem bestehenden JavaScript auf der Website?

Auch das ist normalerweise kein großes Problem.

Die Website ist häufig nur die äußerste Schicht.

Heute sieht die Architektur vielleicht so aus:

Website → Flowise Embed → Flowise Chatflow → Vector DB → LLM

Nach einer Migration könnte sie beispielsweise so aussehen:

Website → Langflow Chat → Langflow Flow → Vector DB → LLM

oder:

Website → Dify Chat Widget → Dify Chatflow → Knowledge Base → LLM

Damit muss normalerweise nicht die gesamte Website verändert werden.

Meist wird lediglich der alte Flowise-Embed-Code entfernt und durch den neuen JavaScript- beziehungsweise Web-Component-Code ersetzt.

Langflow erzeugt seinen Embed-Code direkt über Share → Embed into site.

Dify bietet entsprechend einen Chat-Bubble-Embed, Iframe-Integration und JavaScript-Konfiguration.

Für genau diesen Anwendungsfall existieren also gute Nachfolger.

Sollte man Flowise einfach selbst weiterpflegen?

Technisch ist das möglich.

Flowise steht weiterhin unter Apache 2.0, und das Team fordert Unternehmen ausdrücklich dazu auf, bei Bedarf eigene Forks zu erstellen.

Für große Unternehmen mit einem eigenen Software- und Security-Team kann das durchaus eine Option sein.

Man übernimmt damit allerdings faktisch einen Teil der Rolle des ursprünglichen Herstellers.

Neue Abhängigkeiten müssen getestet, Sicherheitslücken analysiert, Patches erstellt, Framework-Versionen aktualisiert und Kompatibilitätsprobleme behoben werden.

Für die meisten kleinen und mittelständischen Unternehmen dürfte eine Migration deshalb langfristig günstiger sein als ein eigener Flowise-Fork.

Vorsicht bei der Suche nach einem Community-Fork

Da Flowise eine große Community hatte, ist es denkbar, dass sich ein oder mehrere Community-Forks etablieren.

Man sollte jedoch nicht allein danach entscheiden, welcher Fork die meisten GitHub-Stars bekommt.

Entscheidender sind kontinuierliche Releases, mehrere aktive Maintainer, nachvollziehbare Security-Prozesse, schnelle Reaktionen auf Schwachstellen und eine erkennbare langfristige Governance.

Bis sich ein klarer und dauerhaft gepflegter Nachfolger etabliert hat, sollte ein Community-Fork nicht automatisch als sicherste Migrationsstrategie betrachtet werden.

Unsere Empfehlung für bestehende Flowise-Chatbots

Wer heute einen funktionierenden Flowise-Chatbot betreibt, muss ihn nicht morgen abschalten.

Man sollte Flowise aber auch nicht mehr als Plattform betrachten, auf der in den nächsten Jahren neue geschäftskritische Funktionen aufgebaut werden.

Für einen typischen RAG-Chatbot auf einer Unternehmenswebsite würden wir aktuell zuerst Langflow und Dify testen.

Wenn die bisherige Flowise-Erfahrung möglichst erhalten bleiben soll, hat Langflow einen großen Vorteil: visueller Node-Editor, RAG, Self-Hosting und ein fertiges Website-Embed sind vorhanden. Das Projekt steht zudem unter MIT und wird aktuell aktiv weiterentwickelt.

Wenn das Management von Dokumenten, Wissensdatenbanken und veröffentlichten Chat-Anwendungen stärker im Vordergrund steht, ist Dify eine sehr interessante Alternative. Dify bringt ebenfalls Self-Hosting, Knowledge Pipelines und fertige Website-Integrationen mit.

Botpress eignet sich vor allem für Unternehmen, die eine komfortable Cloud-Lösung mit gutem Webchat suchen.

n8n wird interessant, wenn der AI-Chatbot gleichzeitig Unternehmensprozesse automatisieren soll.

Und LangGraph ist eine Überlegung wert, wenn aus einem einfachen Chatbot eine langfristig eigenentwickelte AI-Anwendung werden soll.

Ob sich ein Website-Chatbot überhaupt lohnt, und worauf es bei Leitplanken, Retrieval und der Übergabe an Menschen ankommt, diskutieren wir im Beitrag Chatbots auf der eigenen Website.

Fazit: Flowise ist vorbei, die Idee dahinter aber nicht

Das Ende von Flowise ist für bestehende Nutzer ärgerlich, aber kein Grund für hektische Entscheidungen.

Die Kernkonzepte, auf denen Flowise basiert, bleiben bestehen:

LLMs, RAG, Embeddings, Vector Stores, Tools, APIs, Agents und visuelle Workflows.

Und für fast alle dieser Komponenten gibt es inzwischen leistungsfähige Alternativen.

Das Wichtigste ist deshalb, jetzt nicht einfach abzuwarten.

Bestehende Installationen sollten gesichert und dokumentiert werden. Sicherheitsrisiken sollten überprüft werden. Gleichzeitig sollte eine neue Plattform parallel aufgebaut und mit echten Anwendungsfällen getestet werden.

Für klassische Flowise-Nutzer dürfte Langflow aktuell der naheliegendste Nachfolger sein.

Für stärker wissenszentrierte Chatbots ist Dify eine besonders interessante Alternative.

Und wer Flowise hauptsächlich deshalb eingesetzt hat, um einen RAG-Chatbot per JavaScript auf einer Website bereitzustellen, muss dieses Konzept keineswegs aufgeben.

Genau dafür gibt es auch nach Flowise gute Lösungen. Wenn Sie den Wechsel für eine bestehende Installation durchgehen möchten: melden Sie sich.