Wer in einem deutschen Unternehmen firmeninterne Dokumente von einer KI durchsuchen lassen will, stößt schnell auf ein Problem: ChatGPT, Claude und Gemini laufen in der Cloud, und sensible Verträge oder Kundendaten sollen dort oft nicht landen. AnythingLLM schließt genau diese Lücke. Das Open-Source-Projekt von Mintplex Labs läuft komplett auf eigener Hardware, verbindet sich mit lokalen Sprachmodellen über Ollama und baut daraus einen firmeninternen Chat-Assistenten mit Dokumentensuche per RAG (Retrieval-Augmented Generation).

Das Projekt steht auf GitHub unter MIT-Lizenz und kommt zum Zeitpunkt dieses Artikels (2. September 2026) auf 65.520 Sterne und 7.245 Forks. Die aktuelle Version trägt die Nummer v1.16.1 und wurde am 27. August 2026 veröffentlicht. In diesem Tutorial richten wir AnythingLLM per Docker ein, verbinden es mit einem lokalen Modell über Ollama, bauen einen dokumentenbasierten Workspace auf und sichern die Installation für den Produktivbetrieb ab. Zwölf Schritte, rund 45 bis 60 Minuten Zeitaufwand, ein funktionierendes Setup am Ende.

Am Ende dieses Tutorials steht nicht nur eine laufende Installation, sondern ein komplettes Beispielprojekt: ein interner Support-Bot, der Handbücher und FAQ-Dokumente durchsucht und Fragen dazu beantwortet, inklusive Quellenangabe. Zusätzlich zeigen wir, wie sich AnythingLLM über seine REST-API in eigene Anwendungen einbinden lässt, welche Fehler in der Praxis am häufigsten auftreten und wie ein Vergleich zu den zwei relevantesten Alternativen ausfällt. Wer lieber sofort loslegt, kann direkt zu den zwölf Schritten springen, alle anderen Abschnitte liefern den nötigen Hintergrund für eine Entscheidung im Team.

Was ist AnythingLLM und warum lohnt sich Self-Hosting 2026?

AnythingLLM bündelt drei Dinge in einer Anwendung: eine Chat-Oberfläche, eine RAG-Engine pro Workspace und einen No-Code-Agenten-Builder. Statt Dokumente in einen externen Cloud-Dienst hochzuladen, bleibt bei AnythingLLM jede Datei, jeder Embedding-Vektor und jeder Chat-Verlauf auf dem eigenen Server. Das Projekt selbst bewirbt sich als lokaler KI-Assistent ohne Zwang zu Nutzerkonten, ohne externe API-Schlüssel und ohne künstliche Token-Limits, sofern man ein lokales Modell anbindet.

Technisch verbindet sich AnythingLLM sowohl mit lokalen Modell-Runtimes wie Ollama oder LM Studio als auch mit OpenAI-kompatiblen APIs. Damit lassen sich aktuelle offene Modelle wie DeepSeek-V4, Qwen3, Llama- oder GLM-Varianten genauso einbinden wie gehostete Anbieter, falls ein Team hybrid arbeiten will. Jeder Workspace bekommt seinen eigenen Dokumentenindex, sodass Vertrieb, Recht und Entwicklung mit getrennten Wissensbasen arbeiten können, ohne dass sich Daten vermischen.

Das Vergleichsportal Opsily zählt AnythingLLM neben LibreChat, GPT4All, Jan.ai und LocalAI zu den wenigen vollständig freizügig lizenzierten selbstgehosteten KI-Oberflächen, die ohne Einschränkung kommerziell genutzt werden dürfen. Für europäische Teams zählt laut einer Analyse von Datavlab neben der Lizenz vor allem die Datensouveränität. Der Entscheidungsrahmen für europäische Teams nennt DeepSeek-V4 als eine der kosteneffizientesten Optionen für lokale Inferenz, ein Modell, das sich direkt über Ollama in AnythingLLM laden lässt. Genau diese Kombination aus MIT-Lizenz, lokaler Inferenz und DSGVO-freundlichem Betrieb macht das Projekt für den DACH-Raum interessant.

Der Zeitpunkt für den Einstieg ist günstig. Offene Modelle haben in den vergangenen Monaten spürbar aufgeholt: Neue Generationen wie GLM-5.2 oder Kimi K3 erreichen auf Standard-Benchmarks Werte, die vor einem Jahr noch geschlossenen Cloud-Modellen vorbehalten waren, laufen aber vollständig auf eigener Hardware. Für ein IT-Team bedeutet das, dass sich ein selbstgehosteter Assistent nicht mehr wie ein Kompromiss anfühlt, sondern für viele interne Anwendungsfälle wie Dokumentensuche, Onboarding-Hilfen oder Support-Wissensdatenbanken tatsächlich ausreicht. Die Einstiegshürde liegt heute eher bei der sauberen Konfiguration als bei der reinen Modellqualität, und genau da setzt dieses Tutorial an.

Voraussetzungen: Hardware, Software und Versionen

Bevor es losgeht, ein Überblick über das, was wirklich gebraucht wird. AnythingLLM läuft auch auf bescheidener Hardware, aber ein lokales Sprachmodell braucht spürbar mehr Ressourcen als die reine Chat-Oberfläche. Die folgende Tabelle zeigt Minimum und Empfehlung für ein produktives Setup mit einem 7B- bis 13B-Parameter-Modell.

KomponenteMindestanforderungEmpfehlung für 2026
BetriebssystemLinux, macOS oder Windows mit WSL2Ubuntu 24.04 LTS oder neuer
Arbeitsspeicher8 GB RAM16–32 GB RAM
Speicherplatz10 GB frei50+ GB (Modelle, Dokumente, Vektorindex)
Docker EngineVersion 24 oder neuerDocker Engine mit Compose v5.5.0
GPU (optional)keine, CPU-Inferenz möglichNVIDIA-GPU mit 8+ GB VRAM
OllamaVersion 0.30 oder neuerv0.33.2 (aktuelle Version, Stand 27.08.2026)
AnythingLLMDocker-Image “latest”v1.16.1 (aktuelle Version, Stand 27.08.2026)

Wer nur die Dokumentensuche über kleinere Modelle testen will, kommt mit 8 GB RAM und reiner CPU-Inferenz aus, muss dann aber mit spürbar langsameren Antwortzeiten rechnen. Für den echten Produktivbetrieb mit mehreren gleichzeitigen Nutzern empfiehlt sich eine GPU, da Embedding und Inferenz sonst zum Flaschenhals werden. Als grobe Faustregel für die Modellgröße gilt: Ein 7B-Modell in quantisierter Form läuft flüssig ab etwa 8 GB RAM oder VRAM, ein 13B-Modell braucht eher 16 GB, und größere Modelle jenseits von 30B Parametern werden ohne dedizierte GPU mit mehr als 16 GB VRAM in der Praxis zu langsam für einen interaktiven Chat. Docker und Docker Compose sind Pflicht, da AnythingLLM offiziell als Container-Image ausgeliefert wird und die manuelle Installation ohne Container deutlich fehleranfälliger ist.

Ein Punkt, der in vielen Anleitungen zu kurz kommt: die Netzwerkplanung. Läuft AnythingLLM nur auf dem eigenen Laptop, reicht die Standardkonfiguration ohne weitere Anpassung. Soll die Instanz dagegen im Firmennetz erreichbar sein, sollte vorab geklärt sein, welcher interne DNS-Name genutzt wird, ob eine Firewall den Zugriff auf Port 3001 einschränkt und wer Zugriff auf das Docker-Host-System selbst hat. Diese Entscheidungen lassen sich zwar auch nachträglich treffen, sparen aber deutlich Zeit, wenn sie schon vor dem ersten docker compose up feststehen.

Schritt 1 bis 3: AnythingLLM mit Docker installieren

Schritt 1: Docker und Docker Compose prüfen. Auf den meisten aktuellen Linux-Distributionen ist Docker Compose bereits als Plugin integriert. Ein kurzer Check reicht, um Version und Verfügbarkeit zu bestätigen.

docker --version
docker compose version
# Erwartete Ausgabe (Beispiel):
# Docker version 27.3.1, build ce12230
# Docker Compose version v5.5.0

Schritt 2: Projektverzeichnis und Compose-Datei anlegen. AnythingLLM speichert Konfiguration, Embeddings und Chat-Verläufe in einem persistenten Volume. Dieses Volume muss zwingend außerhalb des Containers liegen, sonst gehen bei jedem Neustart Daten verloren.

mkdir -p ~/anythingllm/storage
cd ~/anythingllm
cat > docker-compose.yml << 'EOF'
services:
  anythingllm:
    image: mintplexlabs/anythingllm:latest
    container_name: anythingllm
    ports:
      - "3001:3001"
    environment:
      - STORAGE_DIR=/app/server/storage
      - JWT_SECRET=bitte-hier-einen-eigenen-zufallswert-eintragen
    volumes:
      - ./storage:/app/server/storage
    restart: unless-stopped
EOF

Schritt 3: Container starten und Health-Check ausführen. Nach dem Start dauert es einige Sekunden, bis der interne Server auf Port 3001 antwortet.

docker compose up -d
sleep 10
curl -s -o /dev/null -w "%{http_code}\n" http://localhost:3001
# Erwartete Ausgabe: 200

Erscheint der Code 200, läuft der Container korrekt und die Weboberfläche ist unter http://localhost:3001 erreichbar. Bei einer Fehlermeldung lohnt der Blick in die Logs mit docker compose logs -f anythingllm, meist liegt die Ursache an einem bereits belegten Port oder an fehlenden Schreibrechten im Storage-Verzeichnis.

Schritt 4 und 5: Admin-Konto anlegen und lokales LLM verbinden

Schritt 4: Ersteinrichtung im Browser. Beim ersten Aufruf von http://localhost:3001 führt ein Einrichtungsassistent durch die Basis-Konfiguration: Name der Instanz, Sprache der Oberfläche und Anlage des ersten Admin-Kontos mit Benutzername und Passwort. Dieses Konto erhält automatisch volle Rechte und sollte ein starkes, einzigartiges Passwort bekommen, da die Instanz sonst offen für jeden ist, der Zugriff auf den Port hat.

Schritt 5: Ollama installieren und ein Modell laden. Für lokale Inferenz ohne Cloud-Anbindung bietet sich Ollama an, ein separates Open-Source-Projekt mit MIT-Lizenz und aktuell rund 180.000 GitHub-Sternen. Die Installation läuft über ein offizielles Skript, danach wird ein Modell heruntergeladen.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
# Beispielausgabe: ollama version 0.33.2

ollama pull deepseek-r1:7b
ollama list
# NAME              ID              SIZE      MODIFIED
# deepseek-r1:7b     a1b2c3d4e5f6   4.7 GB    vor 2 Minuten

Läuft Ollama in einem separaten Container oder auf dem Host-System, muss AnythingLLM darauf zugreifen können. Unter Einstellungen > LLM-Anbieter wählt man "Ollama" aus und trägt die Basis-URL ein, bei einer Installation auf dem Host meist http://host.docker.internal:11434, bei Ollama im selben Docker-Netzwerk der Container-Name. Nach dem Speichern erscheint das geladene Modell in der Dropdown-Liste und kann sofort als Standardmodell für neue Workspaces gesetzt werden.

Schritt 6 und 7: Workspace erstellen und Dokumente per RAG einbinden

Schritt 6: Workspace anlegen. Ein Workspace in AnythingLLM ist eine isolierte Einheit aus Dokumenten, Einstellungen und Chat-Verlauf. Über den Button "New Workspace" lässt sich pro Abteilung, Projekt oder Kunde ein eigener Container anlegen. Wichtig ist die Wahl des Embedding-Modells direkt zu Beginn: Wird es später gewechselt, muss der komplette Dokumentenindex neu aufgebaut werden, da unterschiedliche Embedding-Modelle nicht kompatible Vektorräume erzeugen.

Schritt 7: Dokumente hochladen und einbetten. AnythingLLM akzeptiert unter anderem PDF, DOCX, TXT, CSV und Markdown sowie ganze Webseiten per URL. Nach dem Upload klickt man auf "Move to Workspace" und danach auf "Save and Embed", damit die Dokumente in Chunks zerlegt, mit dem gewählten Embedding-Modell in Vektoren umgewandelt und in der Vektordatenbank gespeichert werden.

  • PDF-Verträge, Handbücher und interne Wikis lassen sich direkt hochladen
  • Webseiten werden per URL gescraped und automatisch eingebettet
  • Der Chat-Modus "Query" beantwortet nur aus den Dokumenten, "Chat" nutzt zusätzlich das Weltwissen des Modells
  • Jede Antwort zeigt die Quell-Chunks an, aus denen sie generiert wurde

Sobald der Embedding-Vorgang abgeschlossen ist, lässt sich im Chat-Fenster direkt eine Frage zum Dokumentinhalt stellen. Die Antwort erscheint zusammen mit den zitierten Textstellen, was die Nachvollziehbarkeit gegenüber einem reinen Cloud-Chatbot deutlich erhöht.

Praxisbeispiel: Ein interner Support-Bot in 15 Minuten

Um die Schritte 6 und 7 greifbarer zu machen, folgt hier ein durchgängiges Beispiel: ein Support-Bot für die IT-Abteilung eines mittelständischen Unternehmens. Ziel ist es, dass Mitarbeitende Fragen zu internen Handbüchern stellen können, statt Tickets für triviale Fragen zu öffnen. Das Beispiel lässt sich eins zu eins auf andere Abteilungen wie Personal oder Vertrieb übertragen.

  • Workspace anlegen mit dem Namen "IT-Support-Wiki"
  • Vier PDF-Handbücher hochladen: VPN-Einrichtung, Passwort-Reset, Drucker-Konfiguration, Software-Bestellprozess
  • Chat-Modus auf "Query" stellen, damit ausschließlich aus den Dokumenten geantwortet wird und keine erfundenen Antworten entstehen
  • System-Prompt anpassen: "Du bist der interne IT-Support-Assistent. Antworte ausschließlich auf Basis der hochgeladenen Dokumente. Wenn die Antwort nicht in den Dokumenten steht, sage das explizit."

Nach dem Embedding-Vorgang, der bei vier PDF-Dokumenten mit insgesamt rund 40 Seiten auf einer Mittelklasse-CPU etwa zwei bis drei Minuten dauert, lässt sich der Bot direkt testen. Eine typische Chat-Interaktion sieht so aus:

Frage: Wie setze ich mein VPN-Passwort zurück?

Antwort: Um Ihr VPN-Passwort zurückzusetzen, öffnen Sie das
Self-Service-Portal unter Punkt 3.2 des VPN-Handbuchs. Dort
wählen Sie "Passwort zurücksetzen" und bestätigen die Anfrage
über die im Firmenverzeichnis hinterlegte E-Mail-Adresse. Der
neue Zugang ist laut Dokument innerhalb von 10 Minuten aktiv.

Quelle: VPN-Einrichtung.pdf, Abschnitt 3.2

Der Bot zitiert dabei nicht nur die Antwort, sondern auch die genaue Fundstelle im Ursprungsdokument, was Nachfragen und Vertrauensaufbau im Team erheblich erleichtert. Fragt jemand nach etwas, das in keinem der vier Dokumente steht, etwa nach der Konfiguration eines Firmenhandys, antwortet der Bot dank des angepassten System-Prompts korrekt mit einem Hinweis, dass dazu keine Information vorliegt, statt eine plausibel klingende, aber falsche Antwort zu erfinden. Dieses Verhalten lässt sich über den Chat-Modus "Query" gezielt erzwingen und ist für produktive Support-Anwendungen der sicherere Standard gegenüber dem freieren Modus "Chat".

Ein zweites typisches Beispiel aus demselben Workspace zeigt, wie der Bot mit mehrdeutigen Fragen umgeht:

Frage: Der Drucker im dritten Stock druckt nicht mehr.

Antwort: Laut Drucker-Konfiguration.pdf sollten Sie zunächst
prüfen, ob der Drucker im Netzwerk sichtbar ist (Abschnitt 2.1).
Ist das der Fall, hilft meist ein Neustart des Druckdienstes auf
dem Client laut Abschnitt 2.4. Bleibt das Problem bestehen, ist
laut Dokument der zuständige IT-Kontakt für Hardwaredefekte
unter der internen Rufnummer aus Abschnitt 4 zu erreichen.

Quelle: Drucker-Konfiguration.pdf, Abschnitt 2.1, 2.4, 4

Bemerkenswert an diesem Beispiel ist, dass der Bot Informationen aus drei unterschiedlichen Abschnitten desselben Dokuments kombiniert, statt nur den ersten Treffer zurückzugeben. Möglich wird das durch die Einstellung "Top-N-Chunks" aus Schritt 8, die festlegt, wie viele Textabschnitte pro Anfrage in den Kontext des Modells geladen werden. Ein höherer Wert liefert vollständigere Antworten bei komplexeren Fragen, kostet aber mehr Rechenzeit pro Anfrage, ein klassischer Trade-off, den jedes Team für den eigenen Dokumentenbestand einmal austesten sollte.

AnythingLLM per REST-API ansteuern

Für Entwicklerteams, die den Support-Bot aus dem Beispiel oben in ein internes Intranet, einen Slack-Kanal oder ein Ticketsystem einbinden wollen, bringt AnythingLLM eine dokumentierte REST-API mit. Ein API-Schlüssel lässt sich unter Einstellungen > API-Schlüssel generieren, danach kann jede Anfrage programmatisch an einen Workspace gestellt werden.

curl -X POST http://localhost:3001/api/v1/workspace/it-support-wiki/chat \
  -H "Authorization: Bearer IHR_API_SCHLUESSEL" \
  -H "Content-Type: application/json" \
  -d '{
    "message": "Wie bestelle ich neue Software?",
    "mode": "query"
  }'

# Beispielantwort (gekürzt):
# {
#   "id": "chat-9f2a",
#   "textResponse": "Neue Software bestellen Sie über das
#     interne Ticketsystem unter der Kategorie 'Software-
#     Anfrage'. Die Freigabe erfolgt laut Prozessdokument
#     durch die zuständige Teamleitung.",
#   "sources": [{"title": "Software-Bestellprozess.pdf"}]
# }

Über dieselbe API lassen sich auch neue Dokumente hochladen, Workspaces verwalten und Chat-Verläufe auslesen, wodurch sich AnythingLLM als Backend für eigene Frontends nutzen lässt, etwa ein schlankes internes Widget statt der Standard-Weboberfläche. Für Teams ohne eigene Entwicklungskapazität reicht die mitgelieferte Weboberfläche aus den vorherigen Schritten in der Regel vollkommen aus, die API lohnt sich vor allem, sobald der Assistent in bestehende Tools wie Microsoft Teams oder ein Ticketsystem eingebettet werden soll.

Beim Umgang mit dem API-Schlüssel gilt dieselbe Vorsicht wie bei jedem anderen Zugangstoken: Er gehört niemals in Frontend-Code, der im Browser ausgeführt wird, sondern ausschließlich in eine serverseitige Anwendung, die die Anfragen im Namen der Nutzer weiterleitet. Für unterschiedliche Integrationen (Slack-Bot, Intranet-Widget, Ticketsystem) empfiehlt sich jeweils ein eigener API-Schlüssel, damit sich im Fall eines Missbrauchs einzelne Schlüssel gezielt widerrufen lassen, ohne gleich alle Integrationen lahmzulegen.

Schritt 8: Vector-Datenbank und Chat-Einstellungen anpassen

Standardmäßig bringt AnythingLLM eine eingebettete Vektordatenbank mit, die ohne zusätzliche Konfiguration läuft und für die meisten Einzel- oder Teaminstallationen ausreicht. Wachsen Dokumentenmenge oder Nutzerzahl deutlich, lässt sich unter Einstellungen > Vector Database auf einen externen Dienst wie Chroma, Qdrant, Weaviate, Milvus oder Pinecone umstellen, was vor allem bei verteilten Teams mit mehreren AnythingLLM-Instanzen Sinn ergibt, die sich einen gemeinsamen Index teilen sollen.

Neben der Datenbank lassen sich pro Workspace auch Chat-Parameter feinjustieren: die Temperatur steuert, wie kreativ oder wie deterministisch das Modell antwortet, die Anzahl der abgerufenen Chunks (Top-N) bestimmt, wie viel Kontext aus den Dokumenten in jede Anfrage einfließt, und ein eigener System-Prompt kann Tonalität und Rolle des Assistenten festlegen. Für eine interne Rechtsabteilung empfiehlt sich eine niedrige Temperatur um 0,1 bis 0,3, um Halluzinationen zu minimieren, während ein Brainstorming-Workspace von einer höheren Temperatur profitiert.

Schritt 9: Multi-User-Zugriff und Rollen einrichten

Wird AnythingLLM nicht nur von einer Person, sondern von einem Team genutzt, sollte der Multi-User-Modus aktiviert werden. Unter Einstellungen > Security lässt sich der Multi-User-Modus einschalten, danach können weitere Konten mit drei Rollen angelegt werden: Admin mit vollem Zugriff auf alle Einstellungen, Manager mit Verwaltungsrechten über zugewiesene Workspaces, und Default für reine Chat-Nutzer ohne Konfigurationszugriff.

Jeder Workspace kann gezielt einzelnen Nutzern oder Gruppen zugewiesen werden, sodass die Buchhaltung nicht versehentlich Zugriff auf den Workspace der Personalabteilung erhält. Das ist besonders für kleine und mittlere Unternehmen relevant, die eine interne Alternative zu ChatGPT anbieten wollen, ohne dass sensible Abteilungsdaten quer durchs Unternehmen sichtbar werden.

In der Praxis hat es sich bewährt, pro Abteilung einen eigenen Manager statt eines zentralen Admin-Kontos für alles zu benennen. Die IT-Abteilung bleibt dann für die technische Infrastruktur zuständig, während die inhaltliche Pflege der Dokumente (neue PDFs hochladen, veraltete entfernen) direkt bei der jeweiligen Fachabteilung liegt. Das verhindert einen Flaschenhals bei der IT und sorgt gleichzeitig dafür, dass Inhalte aktuell bleiben, weil die Personen, die die Dokumente am besten kennen, auch für deren Pflege verantwortlich sind.

Schritt 10: Agenten und No-Code-Workflows aktivieren

Über die reine Chat- und RAG-Funktion hinaus bringt AnythingLLM einen integrierten Agent-Builder mit, der sich per Drag-and-drop bedienen lässt. Damit lassen sich wiederkehrende Abläufe wie Web-Recherche, Dokumentzusammenfassungen oder mehrstufige Rechercheketten als Workflow definieren, ohne eine Zeile Code zu schreiben. Die offizielle Dokumentation zeigt das Prinzip am Beispiel eines Agenten, der aktuelle Hacker-News-Artikel abruft und zusammenfasst, ein Muster, das sich leicht auf interne Anwendungsfälle wie tägliche Reports übertragen lässt.

Agenten lassen sich pro Workspace aktivieren und erhalten dort gezielt Zugriff auf einzelne Fähigkeiten wie Websuche, Datei-Lesen oder externe API-Aufrufe. Wichtig für den produktiven Einsatz: Jede aktivierte Fähigkeit vergrößert die Angriffsfläche, weshalb nur die tatsächlich benötigten Skills pro Workspace freigeschaltet werden sollten, statt pauschal alle Agent-Skills für jede Rolle zu aktivieren.

Ein realistisches Beispiel aus der Praxis: Ein Marketing-Team richtet einen Agenten ein, der einmal pro Woche automatisch aktuelle Branchennews zu einem festgelegten Thema sucht, die relevantesten drei Artikel zusammenfasst und das Ergebnis als Dokument im eigenen Workspace ablegt. Der Rest des Teams kann diese Zusammenfassung dann ganz normal über den Chat abfragen, ohne selbst Rechercheaufwand zu betreiben. Solche Workflows lassen sich im Agent-Builder per Drag-and-drop aus vorgefertigten Bausteinen zusammenstellen, ganz ohne Python- oder JavaScript-Kenntnisse.

Schritt 11: Reverse Proxy und HTTPS für den Fernzugriff

Läuft AnythingLLM nicht nur lokal, sondern soll aus dem Firmennetz oder von unterwegs erreichbar sein, führt kein Weg an einem Reverse Proxy mit HTTPS vorbei. Port 3001 unverschlüsselt ins Internet zu öffnen, ist ein klassischer Anfängerfehler und ein direktes Sicherheitsrisiko. Ein einfacher Nginx-Server-Block reicht als Ausgangspunkt.

server {
    listen 443 ssl http2;
    server_name ki.beispielfirma.de;

    ssl_certificate     /etc/letsencrypt/live/ki.beispielfirma.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ki.beispielfirma.de/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_http_version 1.1;
        proxy_read_timeout 300s;
    }
}

server {
    listen 80;
    server_name ki.beispielfirma.de;
    return 301 https://$host$request_uri;
}

Für das Zertifikat eignet sich Let's Encrypt über Certbot, das kostenlos ist und sich automatisch erneuert. Nach der Einrichtung von Nginx und Certbot bleibt Port 3001 ausschließlich auf 127.0.0.1 gebunden und ist von außen nicht mehr direkt erreichbar, der gesamte Traffic läuft verschlüsselt über Port 443.

Für den internen Einsatz im Firmennetz reicht oft ein interner DNS-Eintrag statt einer öffentlichen Domain, wichtig ist nur, dass das TLS-Zertifikat zum verwendeten Hostnamen passt. Wer keinen öffentlich erreichbaren Server betreiben will, kann statt eines öffentlichen Let's-Encrypt-Zertifikats auch eine interne Zertifizierungsstelle nutzen und das entsprechende Root-Zertifikat auf den Firmenrechnern verteilen. In beiden Fällen bleibt der Grundsatz gleich: unverschlüsseltes HTTP nur für die automatische Weiterleitung auf HTTPS, niemals für den eigentlichen Zugriff auf die Weboberfläche.

Schritt 12: Backup, Updates und Wartung

Da sämtliche Daten im gemounteten storage-Verzeichnis liegen, reicht für ein vollständiges Backup ein einfaches Archiv dieses Ordners, idealerweise bei gestopptem Container, um Inkonsistenzen zu vermeiden.

cd ~/anythingllm
docker compose stop anythingllm
tar -czf backup-anythingllm-$(date +%Y%m%d).tar.gz storage/
docker compose start anythingllm

# Update auf die neueste Version:
docker compose pull
docker compose up -d

Vor jedem Update lohnt sich ein Blick in die Release Notes auf GitHub, da größere Versionssprünge gelegentlich Migrationsschritte für die Vektordatenbank erfordern. Ein Backup direkt vor dem Update ist Pflicht, nicht optional, denn ein fehlgeschlagenes Update ohne Sicherung bedeutet im schlimmsten Fall den Verlust aller Workspaces und Chat-Verläufe.

Häufige Fehler beim Einrichten von AnythingLLM

Diese sechs Fehler tauchen in Praxis-Setups immer wieder auf und lassen sich mit etwas Vorbereitung vollständig vermeiden.

  • Falsches Volume-Mapping: Wird das Storage-Verzeichnis nicht korrekt gemountet, gehen bei jedem Container-Neustart Konfiguration und Dokumente verloren.
  • Zu kleines Modell-Hardware-Budget: Ein 70B-Modell auf einer 8-GB-RAM-Maschine führt zu Timeouts oder Abstürzen statt zu brauchbaren Antworten.
  • Offener Port ohne Reverse Proxy: Port 3001 direkt ins Internet zu routen, macht die Installation angreifbar, gerade wenn Multi-User noch nicht aktiv ist.
  • Embedding-Modell nachträglich gewechselt: Ohne kompletten Re-Embed aller Dokumente liefert die Suche danach inkonsistente oder gar keine Treffer mehr.
  • Kein Backup vor Updates: Ein missglücktes Update ohne vorherige Sicherung kann Workspaces unwiederbringlich beschädigen.
  • Multi-User-Modus in Produktivumgebungen übersprungen: Ein einzelnes geteiltes Admin-Konto für ein ganzes Team verhindert jede Nachvollziehbarkeit, wer welche Änderung vorgenommen hat.

Auffällig an dieser Liste: Die meisten Probleme entstehen nicht durch AnythingLLM selbst, sondern durch übersprungene Grundlagen aus der klassischen Server-Administration. Wer Docker-Volumes, Backups und Netzwerksicherheit schon aus anderen selbstgehosteten Anwendungen kennt, wird bei AnythingLLM kaum überrascht. Für Teams, die zum ersten Mal einen eigenen Dienst selbst hosten, lohnt sich ein zweiter Blick auf genau diese sechs Punkte, bevor die Instanz für mehr als eine Testperson freigegeben wird.

Troubleshooting: 8 typische Probleme und Lösungen

Auch bei sorgfältiger Einrichtung tauchen im Alltag Fehlermeldungen auf. Die folgende Tabelle deckt die häufigsten Fälle ab. Als erste generelle Anlaufstelle bei jedem der genannten Probleme gilt derselbe Grundsatz: zuerst docker compose logs -f anythingllm prüfen, danach die Ollama-Logs mit journalctl -u ollama -f oder dem entsprechenden Container-Log kontrollieren. In den meisten Fällen steht die eigentliche Fehlerursache bereits in einer der beiden Log-Ausgaben, bevor man in der Weboberfläche selbst nach der Ursache sucht.

ProblemWahrscheinliche UrsacheLösung
Container startet nichtPort 3001 bereits belegtAnderen Host-Port in docker-compose.yml mappen oder blockierenden Prozess beenden
"Failed to connect to Ollama"Ollama läuft nicht oder falsche Basis-URLOllama-Dienst prüfen, korrekten Host-Alias in den LLM-Einstellungen eintragen
Sehr langsame AntwortenModell zu groß für vorhandene HardwareKleineres quantisiertes Modell laden oder GPU-Beschleunigung aktivieren
Dokumente werden im Chat nicht gefundenEmbedding-Vorgang fehlgeschlagen oder abgebrochenRe-Embed über die Workspace-Dokumentenverwaltung erneut anstoßen
"Out of memory" beim EinbettenZu viele Dokumente gleichzeitig verarbeitetBatch-Größe reduzieren oder Dokumente in kleineren Gruppen hochladen
Login nach Update nicht mehr möglichSessions durch Versionswechsel invalidiertBrowser-Cache und Cookies leeren, danach neu anmelden
HTTPS-Zertifikat abgelaufenAutomatische Erneuerung durch Certbot nicht aktivCronjob oder Systemd-Timer für "certbot renew" einrichten und testen
Agent-Workflow bricht abFehlende Berechtigung für benötigten Agent-SkillAgent-Skills im betroffenen Workspace unter Einstellungen erneut freischalten

Erweiterte Tipps für den produktiven Einsatz

Wer AnythingLLM über die Testphase hinaus im Alltag nutzen will, profitiert von ein paar zusätzlichen Handgriffen. Quantisierte Modellvarianten (etwa mit der Endung Q4 oder Q5) reduzieren den Speicherbedarf erheblich und sind für die meisten Dokumenten-Chat-Anwendungsfälle ausreichend genau, ohne dass eine teure GPU nötig wird.

Bei der Modellwahl lohnt sich ein Blick auf aktuelle Rankings: Eine Analyse von Taskade von August 2026 nennt GLM-5.2 als neuen Spitzenreiter unter den offenen Modellen, mit rund 1 Million Token Kontextlänge und einem Wert von 91,2 Prozent auf dem GPQA-Diamond-Benchmark, während Kimi K3 vor allem für agentische Coding-Aufgaben empfohlen wird. Beide Modelle lassen sich, sofern die Hardware mitspielt, über Ollama in AnythingLLM einbinden und bieten spürbar bessere Ergebnisse als ältere Generationen bei ähnlichem Ressourcenbedarf.

Weitere Praxistipps: Getrennte Workspaces pro Abteilung verhindern, dass sich Dokumentenkontexte vermischen und die Trefferqualität sinkt. Ein regelmäßiger Blick auf die Ressourcenauslastung des Docker-Hosts (RAM, VRAM, Festplatte) verhindert böse Überraschungen, wenn mehrere Nutzer gleichzeitig große Anfragen stellen. Für dieses Monitoring reicht in kleinen Setups bereits ein einfaches docker stats im Terminal, größere Installationen profitieren von einem dedizierten Monitoring-Stack wie Prometheus mit einem Grafana-Dashboard, das Auslastung, Antwortzeiten und Fehlerraten über die Zeit sichtbar macht und frühzeitig warnt, bevor der Server bei Lastspitzen tatsächlich überlastet ist. Und wer mehrere AnythingLLM-Instanzen für verschiedene Standorte betreibt, sollte frühzeitig auf eine externe Vektordatenbank wie Qdrant umsteigen, um Indizes zentral zu synchronisieren.

Ein weiterer Tipp betrifft die Chunk-Größe beim Einbetten von Dokumenten: Sehr lange technische Handbücher liefern bessere Suchergebnisse, wenn die Standard-Chunk-Größe unter Einstellungen > Dokumentenverarbeitung etwas reduziert wird, da kürzere Textabschnitte präzisere Treffer erzeugen. Bei sehr kurzen FAQ-Einträgen gilt eher das Gegenteil, hier verhindert eine größere Chunk-Größe, dass zusammengehörige Frage-Antwort-Paare auseinandergerissen werden. Ein kurzer Testlauf mit typischen Nutzerfragen nach dem ersten Embedding zeigt schnell, ob die Standardwerte für den eigenen Dokumentenbestand passen oder nachjustiert werden sollten.

AnythingLLM vs. Open WebUI vs. LibreChat im Vergleich

AnythingLLM steht nicht allein im Feld der selbstgehosteten KI-Oberflächen. Open WebUI und LibreChat sind die zwei am häufigsten genannten Alternativen, unterscheiden sich aber im Funktionsschwerpunkt deutlich.

KriteriumAnythingLLMOpen WebUILibreChat
GitHub-Sterne (Stand 02.09.2026)65.520150.72842.736
LizenzMITIndividuelle Lizenz (nicht MIT)MIT
SchwerpunktRAG-Workspaces plus Agent-BuilderChat-Oberfläche primär für OllamaMulti-Provider-Chat-Oberfläche
Workspace-IsolationJa, pro Workspace getrenntEingeschränktEingeschränkt
No-Code-Agent-BuilderJa, integriertNein (Plugins/Funktionen)Teilweise über Plugins
Multi-User mit RollenJa (Admin, Manager, Default)JaJa

Open WebUI hat die größere Community und punktet mit einer sehr ausgereiften reinen Chat-Oberfläche für Ollama-Modelle, verzichtet aber auf den integrierten Agent-Builder und die strikte Workspace-Trennung von AnythingLLM. LibreChat wiederum glänzt durch die Anbindung besonders vieler verschiedener Modell-Anbieter gleichzeitig, bringt aber von Haus aus kein vergleichbares RAG-Workspace-Konzept mit. Für Teams, die gezielt Dokumente durchsuchbar machen und dabei getrennte Wissensräume pro Abteilung wollen, bleibt AnythingLLM aktuell die naheliegendste Wahl unter den drei Optionen.

Die Entscheidung hängt letztlich vom Ausgangspunkt im Team ab. Wer bereits Ollama produktiv nutzt und nur eine schlanke Oberfläche darüberlegen will, findet in Open WebUI eine ausgereifte Lösung mit großer Community und entsprechend vielen Tutorials und Erweiterungen im Netz. Wer dagegen von Anfang an mit mehreren Modell-Anbietern gleichzeitig arbeiten will, etwa um lokale und Cloud-Modelle im selben Werkzeug zu vergleichen, profitiert von der breiten Provider-Anbindung in LibreChat. Für den in diesem Tutorial beschriebenen Anwendungsfall, eine dokumentenbasierte, abteilungsweise getrennte Wissensdatenbank mit Rollenverwaltung und optionalen Agenten, deckt AnythingLLM die meisten Anforderungen ab, ohne dass zusätzliche Erweiterungen von Drittanbietern nötig wären.

Datenschutz und DSGVO: Was Self-Hosting in Deutschland bedeutet

Der Hauptgrund, warum deutsche Unternehmen und Behörden verstärkt auf selbstgehostete KI-Lösungen schauen, ist nicht primär Kostenersparnis, sondern Datenkontrolle. Läuft das Sprachmodell lokal und verlässt kein Dokument den eigenen Server, entfällt die Frage, ob ein US-Cloud-Anbieter Trainingsdaten mitschneidet oder ob eine Auftragsverarbeitungsvereinbarung nach Artikel 28 DSGVO überhaupt in der gewünschten Form abschließbar ist.

Wichtig für die Praxis: Self-Hosting allein ersetzt keine DSGVO-Bewertung. Wer personenbezogene Daten in Workspaces einbettet, muss weiterhin ein Verzeichnis von Verarbeitungstätigkeiten führen, Zugriffsrechte über den Multi-User-Modus sauber vergeben und die in diesem Tutorial beschriebene HTTPS-Absicherung tatsächlich umsetzen, bevor die Instanz produktiv genutzt wird. Die europäische Priorität auf Datensouveränität, Lizenzfreiheit und Hardware-Effizienz, die Datavlab in ihrer Analyse für europäische Teams beschreibt, deckt sich damit genau mit den Anforderungen, die deutsche Compliance- und Datenschutzabteilungen an interne KI-Werkzeuge stellen.

Für den Betrieb in regulierten Branchen wie Finanzdienstleistungen oder dem Gesundheitswesen empfiehlt sich zusätzlich eine Festplattenverschlüsselung auf dem Docker-Host, ein separates VLAN für die KI-Instanz und ein Log-Konzept, das nachvollzieht, wer wann auf welchen Workspace zugegriffen hat. Keiner dieser Punkte ist AnythingLLM-spezifisch, sie gelten für jede selbstgehostete Anwendung mit sensiblen Inhalten, werden aber in der Praxis gerade bei schnell aufgesetzten KI-Pilotprojekten häufig übersprungen und später nachgerüstet, wenn eine interne Prüfung oder ein Datenschutzbeauftragter danach fragt.

Ein Sonderfall ist die hybride Nutzung, bei der ein Team zwar überwiegend lokal arbeitet, für einzelne Workspaces aber doch ein gehostetes Cloud-Modell über eine OpenAI-kompatible API einbindet. In diesem Fall gelten für den betroffenen Workspace dieselben Regeln wie für jede andere Cloud-KI-Nutzung: Ein Auftragsverarbeitungsvertrag mit dem Anbieter ist Pflicht, und es sollte klar dokumentiert sein, welche Workspaces lokal bleiben und welche Daten an Dritte weitergegeben werden. Eine sinnvolle Praxis ist, cloud-angebundene Workspaces optisch klar zu kennzeichnen, etwa durch ein Präfix im Namen, damit Nutzer im Alltag sofort erkennen, wo welche Regeln gelten.

Fazit: Lohnt sich der Aufwand?

Für Teams, die Dokumente durchsuchbar machen wollen, ohne Daten an einen externen Anbieter zu schicken, liefert AnythingLLM einen der derzeit ausgereiftesten Wege dorthin. Die Kombination aus Docker-Installation, Ollama-Anbindung und workspace-basierter Rechteverwaltung deckt die meisten Anforderungen kleiner und mittlerer Unternehmen ab, ohne dass ein eigenes Entwicklerteam nötig wäre. Der Zeitaufwand für das Grundsetup aus diesem Tutorial liegt bei unter einer Stunde, die Feinjustierung von Embedding-Modell, Chunk-Größe und Rollen braucht danach noch etwas Erfahrung im laufenden Betrieb.

Am wichtigsten für den langfristigen Erfolg ist selten die Technik selbst, sondern die Pflege der Dokumente. Ein Support-Bot, der auf veralteten Handbüchern sitzt, liefert schnell falsche Antworten und verliert das Vertrauen der Nutzer, ganz unabhängig davon, wie gut das zugrunde liegende Modell eigentlich ist. Wer AnythingLLM produktiv einsetzt, sollte deshalb von Anfang an einen festen Rhythmus einplanen, in dem Fachabteilungen ihre Dokumente prüfen und aktualisieren, genauso wie sie es mit einem internen Wiki auch tun würden.

Wer bereits eine reine Chat-Oberfläche für Ollama sucht und auf Workspace-Trennung sowie Agent-Builder verzichten kann, ist mit Open WebUI unter Umständen schneller am Ziel. Für dokumentenlastige, abteilungsübergreifende Anwendungsfälle mit klarem Bedarf an Nachvollziehbarkeit bleibt AnythingLLM aber die naheliegendere Wahl im DACH-Raum.

Der wichtigste Rat zum Schluss: klein anfangen. Ein einzelner Workspace mit einer Handvoll Dokumenten und einem kleinen, schnellen Modell zeigt innerhalb weniger Tage, ob der Ansatz für die eigene Abteilung funktioniert, bevor Zeit in eine unternehmensweite Ausrollung investiert wird. Aus diesem ersten Pilot-Workspace lassen sich danach Erfahrungswerte für Chunk-Größe, passende Modellgröße und sinnvolle System-Prompts gewinnen, die sich anschließend auf weitere Abteilungen übertragen lassen, ohne dieselben Anfängerfehler mehrfach zu wiederholen.

Häufig gestellte Fragen

Ist AnythingLLM wirklich kostenlos?

Ja, das Kernprodukt steht unter MIT-Lizenz auf GitHub und lässt sich ohne Lizenzgebühren selbst hosten und auch kommerziell einsetzen. Kosten entstehen lediglich für die eigene Server-Hardware oder, falls gewünscht, für die Anbindung kostenpflichtiger Cloud-Modelle.

Brauche ich zwingend eine GPU?

Nein. AnythingLLM und Ollama laufen auch auf reiner CPU-Inferenz, allerdings deutlich langsamer. Für den Einzelnutzer mit kleineren Modellen reicht ein moderner Mehrkern-Prozessor mit 16 GB RAM, für mehrere gleichzeitige Nutzer wird eine GPU mit ausreichend VRAM aber schnell zum spürbaren Vorteil.

Welches lokale Modell eignet sich am besten für den Einstieg?

Für den Einstieg auf durchschnittlicher Hardware bieten sich 7B- bis 8B-Parameter-Modelle wie DeepSeek-R1 in der 7B-Variante an. Wer stärkere Reasoning-Fähigkeiten braucht und über ausreichend Hardware verfügt, sollte laut aktuellen Rankings von August 2026 einen Blick auf GLM-5.2 werfen.

Kann ich AnythingLLM ohne Docker installieren?

Grundsätzlich ist auch eine manuelle Installation aus dem Quellcode möglich, wird aber offiziell seltener gepflegt als das Docker-Image und bringt deutlich mehr Fehlerquellen mit sich. Für produktive Setups ist die Docker-Variante aus diesem Tutorial der empfohlene Weg.

Wie unterscheidet sich AnythingLLM von Open WebUI?

Open WebUI konzentriert sich stärker auf eine reine, sehr ausgereifte Chat-Oberfläche für Ollama-Modelle. AnythingLLM legt den Schwerpunkt zusätzlich auf strikt getrennte RAG-Workspaces und einen integrierten No-Code-Agenten-Builder, was es für dokumentenlastige Anwendungsfälle in Unternehmen oft passender macht.

Ist AnythingLLM DSGVO-konform?

Die Software selbst sendet bei rein lokalem Betrieb keine Daten an Dritte, was die DSGVO-Bewertung erheblich vereinfacht. Eine vollständige Konformität hängt aber zusätzlich von der eigenen Serverabsicherung, der Zugriffsverwaltung über den Multi-User-Modus und der jeweiligen Datenschutz-Folgenabschätzung des Unternehmens ab.

Wie oft sollte ich AnythingLLM aktualisieren?

Ein Update alle vier bis acht Wochen ist ein guter Rhythmus, um von Sicherheits- und Funktionsupdates zu profitieren, ohne bei jedem kleineren Release neu zu deployen. Vor jedem Update sollte, wie in Schritt 12 beschrieben, ein Backup des Storage-Verzeichnisses stehen.

Kann ich mehrere Sprachmodelle gleichzeitig nutzen?

Ja. AnythingLLM erlaubt es, pro Workspace ein eigenes LLM einzustellen. So kann etwa der Support-Workspace ein kleines, schnelles Modell nutzen, während ein Recherche-Workspace auf ein größeres, leistungsfähigeres Modell wie GLM-5.2 zugreift. Voraussetzung ist, dass Ollama alle gewünschten Modelle lokal vorhält, was entsprechend mehr Festplattenspeicher benötigt.

Was passiert mit den Daten, wenn ich den Container lösche?

Solange das Storage-Verzeichnis wie in Schritt 2 beschrieben als Volume außerhalb des Containers gemountet ist, bleiben alle Dokumente, Embeddings und Chat-Verläufe beim Löschen oder Neustart des Containers erhalten. Nur wenn zusätzlich das gemountete Verzeichnis selbst gelöscht wird, gehen die Daten unwiderruflich verloren, weshalb ein regelmäßiges Backup wie in Schritt 12 beschrieben trotzdem sinnvoll bleibt.

Wie viele Nutzer verträgt eine AnythingLLM-Instanz gleichzeitig?

Eine feste Obergrenze gibt es nicht, die tatsächliche Kapazität hängt fast vollständig von der zugrunde liegenden Hardware und dem gewählten Modell ab. Auf einer Maschine mit einer einzelnen GPU und einem mittelgroßen Modell lassen sich erfahrungsgemäß einige gleichzeitige Chat-Anfragen ohne spürbare Wartezeit verarbeiten, bei deutlich mehr parallelen Nutzern lohnt sich der Wechsel auf ein kleineres, schnelleres Modell oder eine leistungsfähigere GPU, um Warteschlangen zu vermeiden.