2026 Dify 1.18.0: Lässt sich KnowledgeFS selbst hosten? Erst prüfen, ob die Aktivierung sinnvoll ist

Am 23.10.2026 veröffentlichte Dify Version 1.18.0 und kennzeichnete die Agent Knowledge Base als Beta; laut offiziellen Versionshinweisen ist KnowledgeFS eine optionale Integration mit eigenständigem Dienst und eigener Datenbank. Empfehlung für diese Woche: Bestehende, stabile Classic-Knowledge-Abläufe nicht vorsorglich migrieren. Teams mit der Community Edition sollten zuerst offizielle Unterstützung, verfügbare Images und die Aktivierungsbedingungen prüfen und KnowledgeFS höchstens isoliert testen.

Dieser Beitrag richtet sich an Entwickler, die Dify Community Edition selbst betreiben und ein Upgrade planen.
Technische Verantwortliche für Unternehmenswissen können die zusätzlichen Dienst- und Datengrenzen bewerten.
Teams in der Infrastrukturplanung erhalten eine Entscheidungshilfe, um Plattform, Wissensdienste und Modellinferenz getrennt zu betrachten.

Zuletzt aktualisiert am 26.10.2026. Geprüft anhand der Dify-Versionshinweise, der Docker-Bereitstellungsinformationen und des Community-Issues zu Images und Support. Letzteres dokumentiert eine Nutzerfrage, keine offizielle Aussage zur Produktunterstützung.

Entscheidung nach Einsatzszenario

Die wichtigste Unterscheidung ist nicht „alt gegen neu“, sondern „bestehender Bedarf gegen zusätzlich benötigte Funktion“. KnowledgeFS sollte nur dann in die Produktionsplanung aufgenommen werden, wenn ein Team einen konkreten Anwendungsfall für die Agent Knowledge Base hat und die damit verbundenen Betriebsbedingungen erfüllen kann.

• Classic Knowledge läuft stabil: Bestehende Wissensdatenbanken und RAG-Abläufe können zunächst unverändert bleiben. Ein Upgrade auf Dify 1.18.0 ist für sich genommen kein Grund, Daten zu migrieren. Vor einer Änderung sollte das Team den derzeitigen Ablauf dokumentieren: Datenquelle, Verarbeitung, Abruf, Berechtigungen und betroffene Anwendungen.
• Agenten benötigen einen eigenen Wissensraum: KnowledgeFS kann für ein solches Szenario relevant sein. Zuerst ist zu prüfen, ob die benötigte Funktion in der Beta tatsächlich vorhanden ist und ob sie sich in den eigenen Agenten- und Workflow-Ablauf integrieren lässt.
• Es gibt keinen konkreten Funktionsbedarf: Bleiben Sie bei der vorhandenen Lösung. Ein zusätzlich betriebener Dienst schafft Konfigurations-, Überwachungs- und Wiederherstellungsaufwand, ohne automatisch den Nutzen einer bestehenden Wissensdatenbank zu erhöhen.
• Produktive Daten sollen sofort umgestellt werden: Verschieben Sie diese Entscheidung, bis Version, Edition, Image-Bezug, Berechtigungen und Rückweg nachvollziehbar geklärt sind.

Die Diskussion zur Veröffentlichung von Dify 1.18.0 ergänzt die Versionsinformationen um den Veröffentlichungskontext. Für den Funktionsumfang und den Status der Beta sollten jedoch die offiziellen Versionshinweise und die zur Installation passenden Konfigurationsdateien maßgeblich bleiben.

Classic Knowledge und Agent Knowledge Base

Classic Knowledge und die neue Agent Knowledge Base erfüllen verwandte, aber nicht automatisch identische Aufgaben. Wer beide als austauschbare Namen für dieselbe Funktion behandelt, riskiert eine unnötige Migration oder plant eine Funktion ein, die im eigenen Ablauf noch nicht zuverlässig verfügbar ist.

Classic Knowledge ist die bestehende Wissensdatenbank, auf der bereits eingerichtete RAG-Abläufe aufbauen können. Wenn Dokumente verarbeitet, relevante Inhalte abgerufen und Antworten in der Anwendung korrekt erzeugt werden, sollten diese Ergebnisse zuerst als Vergleichsbasis festgehalten werden. Dazu zählen beispielsweise die verwendeten Quellen, der Abrufpfad, die Zugriffsregeln und die Reaktion auf nicht gefundene Inhalte.

Agent Knowledge Base bezeichnet die in Dify 1.18.0 als Beta ausgewiesene Erweiterung für Wissensräume im Agent-Kontext. Die Funktion ist nicht als pauschaler Ersatz für jede bestehende Wissensdatenbank zu verstehen. Vor dem Einsatz sollten Teams konkret festlegen, was sie damit erreichen wollen: etwa getrennte Wissensbereiche für Agenten, nachvollziehbare Abrufvorgänge oder eine andere Form der Zuordnung von Wissen zu Abläufen. Die tatsächliche Verfügbarkeit der benötigten Funktion muss anhand der offiziellen Dokumentation der eingesetzten Version überprüft werden.

Für die Entscheidung empfiehlt sich eine kurze Funktionsprüfung:

• Welche Nutzer, Anwendungen oder Agenten sollen auf welche Wissensbestände zugreifen?
• Muss das Team Zugriffe voneinander abgrenzen, oder reicht die bestehende Berechtigungsstruktur?
• Welche Abruf- und Verarbeitungsschritte müssen nachvollziehbar sein?
• Wird eine Funktion benötigt, die Classic Knowledge im bestehenden Ablauf nicht abdeckt?
• Lässt sich das erwartete Ergebnis mit nicht produktiven Daten zuverlässig testen?

Ein Ergebnis wie „die neue Funktion ist neuer“ reicht als Begründung nicht aus. Ein Wechsel ist erst dann sinnvoll, wenn eine konkrete Anforderung feststeht und sich in einem Test mit dem bestehenden Ablauf vergleichen lässt.

Voraussetzungen für das Selbsthosting

Die offiziellen Informationen zu Version 1.18.0 beschreiben KnowledgeFS als optionale Integration mit eigenständigem Dienst und eigener Datenbank. Damit erweitert sich der Betrieb über den Dify-Kern hinaus. Die Docker-Compose-Konfiguration und das KnowledgeFS-Beispiel für Umgebungsvariablen sind wichtige Prüfstellen für die tatsächliche Einrichtung. Maßgeblich bleibt die Konfiguration, die zur eingesetzten Version passt.

Nach der offiziellen Beschreibung ist KnowledgeFS in der Standard-Compose-Konfiguration nicht einfach standardmäßig eingeschaltet; beim lokalen Einsatz der Community Edition ist eine ausdrückliche Aktivierung über eine Entwicklungsoption vorgesehen. Das sollte nicht als Aufforderung verstanden werden, eine Beta ohne weitere Prüfung in die Produktion zu übernehmen. Es bedeutet vielmehr: Die vorhandene Dify-Bereitstellung muss auf zusätzliche Dienste, Konfigurationswerte und persistente Daten geprüft werden.

Eine Besonderheit ist der Unterschied zwischen technischer Aktivierbarkeit und offiziell dokumentiertem Support. Ein Container-Image, ein Compose-Eintrag oder eine Beispielkonfiguration allein beantworten nicht, ob der Betrieb für eine bestimmte Edition, Architektur und Produktionsumgebung unterstützt wird. Diese Punkte sind einzeln zu verifizieren.

Am 24.10.2026 fragte ein Community-Nutzer im GitHub-Issue zu Image-Verfügbarkeit und Supportpfad nach der Bereitstellung für die Community Edition. Das ist ein Hinweis auf eine offene praktische Frage aus der Nutzercommunity. Es ist kein Beleg dafür, dass ein Image nicht verfügbar ist, dass Dify die Funktion nicht unterstützt oder dass ein bestimmter Supportstatus gilt. Die offizielle Antwort und die zugehörigen Bereitstellungsunterlagen sind entscheidend.

Für eine sichere Prüfung sollten Sie außerdem diese Punkte voneinander trennen:

• Edition: Welche Funktionen und Bereitstellungsschritte gelten für die tatsächlich verwendete Edition? Community Edition, Enterprise und ein gehosteter Dienst können unterschiedliche Wege haben.
• Image: Ist das benötigte Image für die vorgesehene Version verfügbar, aus einer nachvollziehbaren Quelle abrufbar und für die vorgesehene Architektur geeignet?
• Konfiguration: Welche Umgebungsvariablen, Netzwerkverbindungen und Abhängigkeiten sind erforderlich? Ein Beispiel für Variablen ist keine vollständige Betriebsanleitung.
• Persistenz: Welche Daten müssen dauerhaft gespeichert werden und wie werden sie gesichert?
• Wiederherstellung: Kann das Team nach einem fehlgeschlagenen Test auf den vorherigen Stand zurückkehren, ohne die bestehende Wissensdatenbank oder ihre Anwendungen zu beschädigen?

Die offizielle Dify-README kann beim Überblick über den Einstieg helfen. Für konkrete Betriebsentscheidungen sollte sie mit der versionsbezogenen Dokumentation und der eingesetzten Compose-Datei abgeglichen werden.

Getrennte Zuständigkeiten für Plattform, Wissen und Modelle

Bei einer Ressourcenplanung für Dify sollten drei Bereiche getrennt betrachtet werden: die Dify-Plattform, der Wissensdienst samt Datenbank und die Modellinferenz. Diese Trennung verhindert, dass Anforderungen eines Sprachmodells irrtümlich dem Dify-Anwendungsbetrieb zugeschlagen werden.

Dify-Plattform: Dazu gehören die Anwendungskomponenten, die Workflows ausführen und die Verbindung zu weiteren Diensten herstellen. Für die Planung zählen die tatsächlich aktivierten Dienste, die Anzahl der Anwendungen und die Abläufe, die gleichzeitig betrieben werden. Ohne eine belastbare Lastmessung sollte daraus keine feste Arbeitsspeicher- oder Prozessorgrenze abgeleitet werden.

KnowledgeFS und Datenbank: Bei einer Aktivierung kommen zusätzliche Dienst- und Datenbankabhängigkeiten hinzu. Zu planen sind nicht nur deren Laufzeit, sondern auch dauerhafte Speicherung, Sicherung, Überwachung und der Ablauf für Wiederherstellungen. Die genaue Aufteilung muss sich aus der zur Version passenden offiziellen Konfiguration ergeben. Aus dem Beta-Status allein lässt sich keine allgemeingültige Mindestgröße für einen Server ableiten.

Modellinferenz: Ein extern angebundener Modellanbieter verschiebt die Inferenzlast aus der Dify-Serverplanung heraus. Dify und KnowledgeFS müssen dann nicht so kalkuliert werden, als würden sie selbst das Modell berechnen. Dennoch bleiben Fragen zu Datenschutz, Datenübertragung, Protokollierung und den Inhalten bestehen, die an den externen Dienst übermittelt werden. Für Dokumente mit Anforderungen an Vertraulichkeit und Datenschutz ist vorab zu prüfen, welche Daten die eigene Umgebung verlassen dürfen.

Bei einer lokalen CPU-Inferenz gilt eine andere Planung: Modellgröße, Quantisierung, Kontextlänge und Speicherbedarf müssen getrennt vom Dify-Plattformbedarf ermittelt und getestet werden. Eine Näherung für die reine Modellgewichtsspeicherung lautet:

Parameterzahl × Quantisierungsbits ÷ 8

Das Ergebnis ist keine vollständige Speicheranforderung. Es berücksichtigt beispielsweise nicht automatisch Kontextspeicher, Laufzeit, Zwischenspeicher oder zusätzliche Dienste. Es darf daher nicht als garantierte Mindestkonfiguration verwendet werden. Trainingsläufe und hoch ausgelastete Inferenz großer Modelle sind nicht der Gegenstand dieser Serverplanung; ohne geeignete GPU lässt sich daraus keine GPU-Leistung ableiten.

Prüfliste vor Test und Produktivbetrieb

Die folgende Liste führt von der fachlichen Anforderung bis zur Wiederherstellung. Wenn ein entscheidender Prüfpunkt offenbleibt, sollte KnowledgeFS nicht an produktive Wissensdaten angeschlossen werden.

• [ ] Bedarf beschreiben: Benennen Sie die Funktion, die im bestehenden Classic-Knowledge-Ablauf fehlt. Legen Sie fest, welche Nutzer, Agenten oder Workflows davon profitieren sollen.
• [ ] Edition und Version bestätigen: Prüfen Sie, ob die offizielle Dokumentation die geplante Nutzung für Ihre konkrete Edition und Version beschreibt. Übertragen Sie nicht ungeprüft die Bedingungen der Community Edition auf Enterprise oder einen gehosteten Dienst.
• [ ] Supportstatus und Image-Bezug prüfen: Bestätigen Sie, welche Images verfügbar sind, woher sie stammen und welche Architektur sie unterstützen. Behandeln Sie Community-Fragen als Hinweise auf Prüfbedarf, nicht als Produktentscheidung.
• [ ] Dienste und Datenbank erfassen: Gleichen Sie Compose-Datei und Umgebungsvariablen mit der Version ab. Dokumentieren Sie Abhängigkeiten, Netzverbindungen, persistente Verzeichnisse und Zuständigkeiten.
• [ ] Test isolieren: Verwenden Sie zunächst nicht produktive Daten und einen getrennten Testablauf. Halten Sie die Ergebnisse des bestehenden Classic-Knowledge-Verfahrens als Vergleich fest.
• [ ] Berechtigungen und Datenschutz prüfen: Testen Sie mit unterschiedlichen Rollen, welche Wissensbestände sichtbar und abrufbar sind. Klären Sie zugleich, ob Inhalte an externe Modell-APIs übertragen werden.
• [ ] Fehler und Rückweg erproben: Prüfen Sie, wie sich ein fehlgeschlagener Abruf, ein nicht verfügbarer Dienst und eine Wiederherstellung aus einer Sicherung auswirken. Legen Sie fest, wie die Anwendung auf den vorherigen Ablauf zurückgesetzt wird.
• [ ] Produktionsfreigabe dokumentieren: Aktivieren Sie die Funktion erst, wenn Testergebnis, Supportstatus, Sicherung und Zuständigkeiten nachvollziehbar bestätigt sind.

Diese Reihenfolge verhindert zwei häufige Fehlentscheidungen: eine Migration ohne nachgewiesenen Funktionsgewinn und eine Produktivaktivierung, bevor Image, Datenhaltung und Rückweg geprüft wurden. Für ein kleines Team ist ein isolierter Test meist leichter zu überblicken als ein paralleler Umbau der bestehenden Wissensabläufe.

Ressourcenplanung ohne falsche Mindestwerte

Eine allgemeingültige Konfiguration für Dify 1.18.0 samt KnowledgeFS lässt sich aus der Veröffentlichung der Beta nicht ableiten. Die benötigten Ressourcen hängen von den aktivierten Diensten, der Datenmenge, den parallelen Abläufen und der Modellanbindung ab. Ohne dokumentierte Messung oder eine offizielle Mindestanforderung wären konkrete Arbeitsspeicher- oder Prozessorwerte irreführend.

Erstellen Sie stattdessen eine Ressourcenliste für die tatsächlich geplante Architektur:

• Plattformdienste: Welche Dify-Komponenten laufen dauerhaft, und welche müssen im Test zusätzlich aktiviert werden?
• KnowledgeFS und Datenbank: Welche Daten werden gespeichert, wie schnell wachsen sie voraussichtlich, und welche Sicherungsstrategie gilt?
• Dokumentverarbeitung: Welche Aufgaben werden innerhalb der eigenen Umgebung ausgeführt und welche an externe Dienste übergeben?
• Modellzugriff: Wird eine API verwendet oder soll ein Modell lokal auf der CPU laufen? Diese Wahl verändert die Lastverteilung deutlich.
• Betrieb und Wiederherstellung: Welche Reserven werden für Wartung, Sicherungen und Wiederanlauf benötigt?

Für eine reale Planung sollte die Auslastung des isolierten Tests protokolliert werden: Arbeitsspeicher, CPU-Nutzung, Speicherverbrauch und Reaktionsverhalten der einzelnen Dienste. Vergleichen Sie die Messwerte nicht mit einer vermeintlich universellen Dify-Mindestgröße, sondern mit dem eigenen Nutzungsszenario und den offiziellen Anforderungen der eingesetzten Version.

Wer eine dauerhafte, getrennte Laufzeit für Plattform und zusätzliche Dienste plant, kann anschließend die Mietoptionen und verfügbaren Servermerkmale auf der NodeKVM-Preisseite mit dem eigenen Lastprofil abgleichen. Daraus folgt jedoch weder eine Vorinstallation von KnowledgeFS noch eine bestätigte Kompatibilität. Diese Punkte müssen unabhängig anhand der Dify-Dokumentation geprüft werden. Bei offenen Fragen zu den Angebotsbedingungen steht außerdem die NodeKVM-Hilfeseite zur Verfügung.

Häufige Fragen

Kann KnowledgeFS mit der Community Edition selbst betrieben werden?

Ein lokaler Betrieb ist nicht automatisch durch die Standard-Compose-Konfiguration aktiviert. Laut den Angaben zu Dify 1.18.0 muss die Community Edition lokal ausdrücklich für KnowledgeFS konfiguriert werden. Prüfen Sie vor dem Test die offizielle Dokumentation, den Image-Bezug und die Unterstützung Ihrer Edition. Eine Community-Frage zu Images ist kein offizieller Nachweis für fehlende Unterstützung.

Worin unterscheidet sich die Agent Knowledge Base von Classic Knowledge?

Classic Knowledge ist der vorhandene Wissensdatenbank-Ansatz, den bestehende Anwendungen und RAG-Abläufe weiter nutzen können. Die Agent Knowledge Base ergänzt eine Wissensumgebung für Agenten und verwandte Abläufe. Sie ist in Dify 1.18.0 als Beta ausgewiesen. Prüfen Sie daher Funktionen, Berechtigungen und Integrationen, statt sie als verpflichtenden Ersatz zu behandeln.

Benötigt KnowledgeFS einen eigenen Dienst und eine eigene Datenbank?

Ja. Die offiziellen Informationen zu Version 1.18.0 beschreiben KnowledgeFS als optionale Integration mit eigenständigem Dienst und eigener Datenbank. Das erweitert die Betriebsgrenzen: Konfiguration, Persistenz, Überwachung und Wiederherstellung dieser Komponenten müssen eingeplant werden. Prüfen Sie die Abhängigkeiten anhand der Dokumentation, die zur tatsächlich eingesetzten Version gehört.

Müssen bestehende Dify-Wissensdatenbanken nach dem Upgrade migriert werden?

Nein, nicht allein deshalb, weil Dify 1.18.0 verfügbar ist. Wenn Classic Knowledge und die dazugehörigen RAG-Abläufe stabil funktionieren, können sie zunächst bestehen bleiben. Planen Sie einen getrennten KnowledgeFS-Test erst bei einem konkreten Bedarf und nachdem Support, Images und Rückweg geklärt sind.

Wenn Classic Knowledge die Anforderungen bereits erfüllt, ist der sicherste nächste Schritt, den laufenden Ablauf zu dokumentieren und KnowledgeFS vorerst nicht produktiv zu aktivieren. Besteht ein klarer Bedarf an den neuen Agent-Wissensräumen, sollte zunächst ein isolierter Test folgen, der Supportstatus, Image-Verfügbarkeit, Berechtigungen und Wiederherstellung abdeckt. Für langfristig getrennt betriebene Dienste kann ein dedizierter AMD-Server sinnvoller sein als eine gemeinsam genutzte virtuelle Umgebung, in der Ressourcen mit anderen Mietern geteilt werden. Vergleichen Sie dafür die aktuellen Angaben auf der NodeKVM-Preisseite; eine bestimmte Dify- oder KnowledgeFS-Kompatibilität wird damit nicht zugesagt.

Fragen

1. Q
   Kann ich KnowledgeFS mit der Community Edition selbst betreiben?

   Ein lokaler Betrieb ist nicht automatisch mit der Standard-Compose-Konfiguration aktiviert. Laut den Angaben zu Dify 1.18.0 muss die Community Edition lokal ausdrücklich für KnowledgeFS konfiguriert werden. Prüfen Sie vor dem Test die offizielle Dokumentation, den verfügbaren Image-Bezug und die konkrete Unterstützung Ihrer Edition. Eine Community-Frage zu Images ist kein offizieller Nachweis für fehlende Unterstützung.

2. Q
   Was unterscheidet die Agent Knowledge Base von Classic Knowledge?

   Classic Knowledge ist der bestehende Wissensdatenbank-Ansatz, den vorhandene Anwendungen und RAG-Abläufe weiter nutzen können. Die Agent Knowledge Base ergänzt eine Wissensumgebung für Agenten und damit verbundene Abläufe. Sie ist in Version 1.18.0 als Beta ausgewiesen. Prüfen Sie daher die benötigten Funktionen, Berechtigungen und Integrationen, statt die neue Funktion als verpflichtenden Ersatz zu behandeln.

3. Q
   Braucht KnowledgeFS einen eigenen Dienst und eine eigene Datenbank?

   Ja. Die offiziellen Informationen zu Version 1.18.0 beschreiben KnowledgeFS als optionale Integration mit eigenständigem Dienst und Datenbank. Das erweitert die Betriebsgrenzen: Neben der Dify-Plattform müssen auch Konfiguration, Persistenz, Überwachung und Wiederherstellung dieser Komponenten geplant werden. Vor der Aktivierung sollten Sie die Abhängigkeiten anhand der zur eingesetzten Version gehörenden Dokumentation prüfen.

4. Q
   Muss ich bestehende Dify-Wissensdatenbanken nach dem Upgrade migrieren?

   Nein, eine Migration ist nicht allein deshalb erforderlich, weil Dify 1.18.0 verfügbar ist. Wenn Classic Knowledge und die dazugehörigen RAG-Abläufe stabil funktionieren, können sie zunächst bestehen bleiben. Planen Sie einen getrennten KnowledgeFS-Test erst dann, wenn ein konkreter Bedarf an Agent-Wissensräumen oder den neuen Funktionen besteht und Support, Images sowie Rückweg geklärt sind.