Dify oder Flowise: 1,5 GB Leerlauf beim Self-Hosting

Für ein neues Self-Hosting-Projekt mit mehreren Beteiligten ist Dify meist die tragfähigere Wahl: Die Plattform bündelt Anwendungen, Wissensbasen und Verwaltung, verlangt dafür aber mehr Serverkapazität. Ein Hostingvergleich eines Drittanbieters nennt rund 1,5 GB RAM im Leerlauf für Dify und etwa 200 MB für Flowise. Die Seite legt den Messaufbau für dieses Zahlenpaar nicht offen; die Werte sind deshalb eine Orientierung für den Platzbedarf, keine Zusage für den Betrieb unter Last.

Flowise bleibt für kleine, klar abgegrenzte Abläufe interessant, wenn wenig Speicher verfügbar ist und Entwickler den Betrieb selbst übernehmen. Bei einem neuen langfristigen Projekt kommt jedoch ein weiterer Faktor hinzu: Das Flowise-Team stellte die aktive Entwicklung ein, archivierte das Repository im August 2026 und beendete seine offizielle Präsenz Ende desselben Monats. Der Quellcode bleibt verfügbar, doch für künftige Anpassungen kann das betreibende Team nicht mit neuen Änderungen des bisherigen Kernteams planen.

Leerlaufverbrauch und Servergröße sind verschiedene Werte

Die veröffentlichten Leerlaufzahlen beschreiben den Speicherverbrauch einer ruhenden Installation. Für die Wahl eines Hosts zählt zusätzlich, was Dokumentenverarbeitung, Datenhaltung, gleichzeitige Anfragen und weitere Dienste benötigen. Ein lokal betriebenes Sprachmodell würde ebenfalls Ressourcen beanspruchen; bei einem externen Modellanbieter fällt dessen Rechenlast dagegen außerhalb des eigenen Servers an. Aus einem Leerlaufwert lässt sich daher weder eine Nutzerzahl noch eine Antwortzeit ableiten.

Das Dify-Projekt nennt für seine Installation mindestens zwei CPU-Kerne und 4 GiB RAM und beschreibt Docker Compose als einfachen Startweg. Das ist eine Anforderung an den Host, während die 1,5 GB aus dem Vergleich dessen angegebenen Verbrauch im Leerlauf bezeichnen. Der Abstand ist für kleine Server entscheidend: Wer nur den Leerlaufwert einplant, reserviert keinen Platz für die übrigen Prozesse und Lastspitzen.

Auch beim Drittanbieter selbst gibt es eine andere veröffentlichte Messreihe: Auf einem Hetzner CX32 mit vier vCPU und 8 GB RAM nennt sie etwa 1,8 GB für Dify und 300 MB für Flowise im Leerlauf. Für das erste Zahlenpaar fehlen entsprechende Angaben zur Konfiguration. Die Wertepaare sollten deshalb nicht als Wiederholung desselben Tests gelesen werden; beide zeigen lediglich dieselbe Richtung beim Betriebsgewicht.

Was Dify als Plattform zusammenführt

Dify verbindet den visuellen Aufbau eines Workflows mit Funktionen für dessen spätere Nutzung. Zum dokumentierten Umfang gehören die Aufnahme von Dokumenten für RAG, Modellanbindung, Agenten, Protokolle und APIs. Ein Team kann damit eine Anwendung entwickeln, mit eigenen Inhalten versorgen und in ein anderes Produkt einbinden, ohne für jeden dieser Schritte einen getrennten Builder einzuführen.

Diese Bündelung erklärt einen Teil der praktischen Abwägung beim Self-Hosting. Die zusätzliche Kapazität bezahlt nicht automatisch bessere Antworten des Sprachmodells; sie hält vielmehr eine umfassendere Anwendungsumgebung bereit. Relevant wird das, wenn Inhalte regelmäßig gepflegt, Anwendungen gemeinsam verwaltet und ihre Nutzung beobachtet werden sollen. Bei einem einzelnen, selten veränderten Ablauf können solche Funktionen mehr Betriebsaufwand schaffen, als das Projekt benötigt.

Flowise organisiert die Arbeit stärker um den visuellen Ablauf. Die Flowise-Dokumentation beschreibt Assistant, Chatflow und Agentflow sowie API, SDK, CLI und einen einbettbaren Chatbot. Flowise ist damit nicht auf eine lokale Demo oder eine einzige Form der Veröffentlichung beschränkt. Die Wahl zwischen beiden Produkten lautet auch nicht „API oder keine API“, sondern wie viel Anwendungsverwaltung neben dem Editor gebraucht wird.

RAG: Wissenspflege oder frei kombinierbare Bausteine

Bei RAG liegt der Unterschied vor allem im Arbeitsablauf. Dify behandelt die Wissensbasis als eigenen Teil der Plattform: Dokumente werden aufgenommen und für die Suche aufbereitet, bevor eine Anwendung sie für Antworten nutzt. Das ist hilfreich, wenn Fachleute Inhalte aktualisieren und Entwickler den Anwendungsablauf getrennt davon betreuen. Entscheidend ist dann, wer Quellen austauschen, Suchergebnisse beurteilen und Änderungen an den Inhalten freigeben darf.

Flowise bietet ebenfalls RAG-Funktionen und ist nicht auf eine einfache Ähnlichkeitssuche festgelegt. Seine dokumentierten Chatflows unterstützen unter anderem Retriever, Reranker und Graph RAG; Komponenten lassen sich zu einem gezielten Suchablauf verbinden. Das gibt Entwicklern Spielraum bei der Verarbeitung und Abfrage, verlagert aber die Verantwortung für die Zusammensetzung des Ablaufs stärker in das Projekt. Die bloße Anzahl der Bausteine entscheidet noch nicht über die Qualität einer Antwort: Dokumente, Aufteilung, Suchstrategie und Modell müssen zum tatsächlichen Datenbestand passen.

Rollen und Veröffentlichung im Team

Für eine kleine Gruppe sind gemeinsame Arbeitsbereiche oft wichtiger als eine lange Funktionsliste. Dify sieht Mitgliederverwaltung und Anwendungen innerhalb eines Workspace vor. Bei der Planung sollte das Team dennoch zwischen solcher Zusammenarbeit und erweiterten Unternehmensrechten unterscheiden: SSO und rollenbasierte Sicherheitsfunktionen führt Dify im Enterprise-Angebot. Aus dem Vorhandensein eines Workspace folgt nicht, dass jede gewünschte Berechtigung in der selbst betriebenen Community Edition enthalten ist.

Auch Flowise führt Teams, Workspaces und Sicherheitsfunktionen auf. Die konkrete Verfügbarkeit hängt von der eingesetzten Edition und Bereitstellung ab. Wer Entwicklung, Pflege der Wissensquellen und laufenden Betrieb verschiedenen Personen zuweisen muss, sollte diese Aufgaben gegen die tatsächlich nutzbaren Rechte abgleichen. Für die Veröffentlichung bieten beide Produkte Schnittstellen und einbettbare Chats; Integrationen in ein bestehendes Produkt sind daher kein Alleinstellungsmerkmal von Dify.

Der spätere Wechsel ist Handarbeit

Die Entscheidung bindet ein Projekt stärker, als der visuelle Editor vermuten lässt. Der Hostingvergleich beschreibt keinen automatischen Migrationspfad zwischen Dify und Flowise, weil sich Workflow-Formate und Datenmodelle unterscheiden. Bei einem Wechsel müssen Abläufe deshalb neu aufgebaut und ihre Ergebnisse erneut geprüft werden. Hinzu kommen je nach Nutzung Modellzugänge, Wissensquellen, Berechtigungen und die Stellen im eigenen Produkt, die eine API aufrufen.

Bei Flowise verändert die Archivierung außerdem die Wartungsrechnung. Eine bestehende Installation kann weiterlaufen, und der verfügbare Quellcode lässt sich selbst pflegen oder in einem Fork weiterentwickeln. Das verlangt aber Zuständigkeit für Fehlerbehebungen, Abhängigkeiten und die Anpassung eigener Abläufe. Der geringere Speicherbedarf senkt die technische Einstiegshürde; er ersetzt diese Arbeit nicht. Wie groß ein späterer Umstieg wird, hängt von den tatsächlich genutzten Komponenten ab und lässt sich aus den Leerlaufwerten nicht seriös beziffern.

Welche Wahl trägt das Vorhaben?

Dify passt zu neuen Teamprojekten, wenn eine dauerhaft gepflegte Wissensbasis, gemeinsame Anwendungsverwaltung und Veröffentlichung wichtiger sind als ein möglichst kleiner Host. Die dokumentierte Mindestgröße des Servers gehört dann früh in die Planung. Für ein Projekt mit besonders feinen Zugriffsrechten muss zusätzlich klar sein, welche Edition diese Rechte bereitstellt.

Flowise passt zu begrenzten oder bereits laufenden Abläufen, deren Entwickler den visuellen Builder und den niedrigeren Speicherbedarf bewusst nutzen. Für ein neues Vorhaben mit langer Laufzeit wiegt die Verantwortung für ein archiviertes Projekt schwerer als die Leerlaufdifferenz allein. Wer diese Pflege übernehmen kann und keine umfassende Plattform braucht, erhält weiterhin einen brauchbaren Baukasten; wer sie nicht übernehmen kann, sollte den niedrigeren RAM-Wert nicht zum einzigen Auswahlkriterium machen.

Lesen Sie auch: