Sådan selvhoster du AnythingLLM i 2026: Dokumenter, embeddings og persistence
Selvhost AnythingLLM med korrekte porte, persistent storage, HTTPS, secrets, backups og upgrade-tjek. Lær, hvordan du løser problemet, når storage-mountet mangler.
En AnythingLLM-container kan være grøn, selv om det job, brugerne faktisk har brug for, er gået i stykker. I AnythingLLM skyldes den skjulte fejl typisk, at storage-mountet mangler, eller at embedding-modellen er ændret efter indeksering. Denne guide bruger “indlæs et dokument, vent på embedding, stil et spørgsmål, hvis svar afhænger af dokumentet, og verificér den citerede source chunk” som acceptance test og bygger deploymentet baglæns ud fra dette resultat.
AnythingLLM har en specifik rolle i stacken: document chat og retrieval uden en håndbygget pipeline. Produktionsspørgsmålet er derfor ikke, om port 3001 svarer én gang, men om state, dependencies og den offentlige adresse fortsat stemmer overens efter en restart, update og restore.
Porte, processer og private services
Et nyttigt AnythingLLM-diagram viser den offentlige route, den private port 3001, state-grænsen og alle understøttende krav. Markér, hvilke pile der bærer credentials, og hvilke der er almindelig user traffic. Network contract for AnythingLLM består af en embedding provider, LLM provider og tilstrækkelig storage til dokumenter. Hold private endpoints på intern DNS, tillad kun nødvendige outbound calls, og giv AnythingLLM en scoped service credential.
Bevis diagrammet med én reel handling: indlæs et dokument, vent på embedding, stil et spørgsmål, hvis svar afhænger af dokumentet, og verificér den citerede source chunk. Belastningen kommer sandsynligvis fra document parsing, embedding throughput, vector-store size og den context, der sendes til den valgte model; monitorér denne sti i stedet for at behandle alle HTTP requests ens.
Gør AnythingLLM recovery målbar
Lav en inventory over alle durable artifacts: dokumenter, vector indexes, workspaces og application settings. Mount /app/server/storage før bootstrap, skriv harmløse sample data, og erstat containeren for at bevise, at stien faktisk er persistent. Medtag configuration, der ændrer, hvordan gemte data fortolkes, ikke kun den største mappe.
Fastlæg retention, kopiér backups off-host, og kør en clean-room restore. AnythingLLM-drilløvelsen er gennemført, når dokumenter, embeddings, workspace membership og provider settings gendannes samlet og besvarer det samme evidensbaserede spørgsmål. Hvis snapshots indgår i planen, kan du bruge vejledningen om PITR versus snapshots til at dokumentere, hvad hver mekanisme kan gendanne.
Vælg AnythingLLM's trust boundary
Efter det første login skal du gennemgå, hvad en anonym besøgende, en almindelig bruger og en administrator hver især kan gøre. Den AnythingLLM-fejl, du skal undgå, er at behandle workspace-loginet som en erstatning for at isolere provider keys. Den tilsigtede policy er at begrænse medlemmer til workspaces og opbevare credentials til LLM, embedding og vector database på serveren.
Generér JWT_SECRET som en lang, tilfældig værdi; en rotation ugyldiggør normalt sessions eller tokens, så planlæg bruger- påvirkningen i stedet for at kalde det en encryption migration. Hold dependency accounts adskilt fra human accounts, afvis ubrugt egress, hvor det er praktisk, og begræns arbejde, der påvirkes af document parsing, embedding throughput, vector-store size og den context, der sendes til den valgte model.
Hvad skal bestå, før rigtige AnythingLLM-data ankommer?
AnythingLLM's release record skal indeholde facts, ikke “ser fint ud”. Gem den valgte image digest, configuration checksum, public hostname og et tidsstemplet resultat for: indlæs et dokument, vent på embedding, stil et spørgsmål, hvis svar afhænger af dokumentet, og verificér den citerede source chunk. Brug sample data, der ikke er fra produktion, så kontrollen kan køres efter hver deployment.
Bevis to lifecycle events separat. En container replacement skal bevare normal drift; en clean recovery skal vise, at dokumenter, embeddings, workspace membership og provider settings gendannes samlet og besvarer det samme evidensbaserede spørgsmål. Mens kontrollen kører, skal du måle document parsing, embedding throughput, vector-store size og den context, der sendes til den valgte model, og gemme resultatet som det forventede envelope for denne version.
Test også en afvist eller ugyldig situation: Afvis midlertidigt test-identitetens adgang til en embedding provider, LLM provider og tilstrækkelig storage til dokumenter. AnythingLLM skal fejle på en måde, der kan diagnosticeres, og må ikke overskrive sund state. Genskab den gyldige situation, kør sample-dataene igen, og vedhæft de relevante redacted logs. Disse artifacts giver en fremtidig rollback-beslutning konkret evidens.
Byg en AnythingLLM-container, der kan udskiftes
En minimal kommando er nyttig, når den viser, hvad platformen senere skal administrere.
docker run -d \
--name anythingllm \
--restart unless-stopped \
-p 127.0.0.1:3001:3001 \
-v anythingllm-data:/app/server/storage \
-e JWT_SECRET=replace-with-a-long-random-value \
mintplexlabs/anythingllm:latest
Her forbliver port 3001 privat på hosten, og alle nødvendige stier er eksplicitte. Tilføj de gennemgåede connection settings for en embedding provider, LLM provider og tilstrækkelig storage til dokumenter; brug private navne til private services. Verificér startup med både logs og det applikationsspecifikke proof: indlæs et dokument, vent på embedding, stil et spørgsmål, hvis svar afhænger af dokumentet, og verificér den citerede source chunk. Når det er verificeret, skal du låse image-versionen, så en rutinemæssig udskiftning ikke ændrer adfærden ubemærket.
Test AnythingLLM udefra serveren
Undgå midlertidige og permanente offentlige origins til AnythingLLM. Brug i stedet den eksterne HTTPS-origin til browser- og API-adgang, peg det valgte DNS-navn på platformens route, og proxy kun til port 3001.
Udfør denne handling udefra hosten: indlæs et dokument, vent på embedding, stil et spørgsmål, hvis svar afhænger af dokumentet, og verificér den citerede source chunk. Hvis ingress fejler, gennemgår fejlsøgningsguiden til 502 Bad Gateway fejl i porte og listeners. Hvis AnythingLLM modtager requesten, men storage-mountet mangler, eller embedding-modellen er ændret efter indeksering, peger evidensen nu ud over proxyen.
Failure drills for AnythingLLM
Byg dashboards omkring document parsing, embedding throughput, vector-store size og den context, der sendes til den valgte model. En CPU-graf uden denne workload-kontekst kan ikke forklare, hvorfor AnythingLLM er langsom. Tilføj en syntetisk eller scheduled check, der forsøger at indlæse et dokument, vente på embedding, stille et spørgsmål, hvis svar afhænger af dokumentet, og verificere den citerede source chunk med harmløse testdata.
Før en upgrade skal du tage højde for denne applikationsspecifikke risiko: En ændring af embedding-modellen kan kræve re-indeksering, mens application releases kan migrere workspace- og vector-metadata. Gendan en nylig backup i et isoleret deployment, kør migrations dér, og sammenlign adfærden. Hvis storage-mountet mangler, eller embedding-modellen er ændret efter indeksering, skal du undersøge den relevante boundary — public origin, storage eller dependency — før du ændrer irrelevante settings.
Hvad Dockup bør automatisere for AnythingLLM
For AnythingLLM kan Dockup oprette route og TLS certificate, bevare mounts, levere secrets og placere en embedding provider, LLM provider og tilstrækkelig storage til dokumenter på et privat netværk, mens deploymentet sker enten til Dockup eller til tilknyttede servere.
Release-gaten er stadig den konkrete AnythingLLM-transaktion: indlæs et dokument, vent på embedding, stil et spørgsmål, hvis svar afhænger af dokumentet, og verificér den citerede source chunk. Verificér også restore-betingelsen — dokumenter, embeddings, workspace membership og provider settings gendannes samlet og besvarer det samme evidensbaserede spørgsmål. Disse to kontroller viser, om deploymentet fungerer, og om det kan gendannes.
Ofte stillede spørgsmål
Hvad har AnythingLLM brug for i et production deployment?
Route AnythingLLM-containeren på port 3001 gennem én HTTPS-origin. Det understøttende netværkskrav er en embedding provider, LLM provider og tilstrækkelig storage til dokumenter. Erklær ikke AnythingLLM klar, før du kan indlæse et dokument, vente på embedding, stille et spørgsmål, hvis svar afhænger af dokumentet, og verificere den citerede source chunk.
Hvilke AnythingLLM-data hører hjemme i en backup?
Persist /app/server/storage, og medtag dokumenter, vector indexes, workspaces og application settings i det samme recovery-manifest. En clean AnythingLLM-restore består først, når dokumenter, embeddings, workspace membership og provider settings gendannes samlet og besvarer det samme evidensbaserede spørgsmål.
Kræver AnythingLLM HTTPS bag en reverse proxy?
Brug HTTPS til den offentlige AnythingLLM-origin, og behold port 3001 på den interne route. Anvend AnythingLLM-settingen korrekt: Brug den eksterne HTTPS-origin til browser- og API-adgang. For AnythingLLM beskytter HTTPS credentials eller brugerindhold under transport og sikrer, at origin-sensitive client behavior forbliver konsistent.
Hvordan bør en AnythingLLM-upgrade testes?
Gendan den aktuelle AnythingLLM-state i et isoleret deployment, anvend kandidatversionen, og gentag dens acceptance transaction. Vær særligt opmærksom, fordi en ændring af embedding-modellen kan kræve re-indeksering, mens application releases kan migrere workspace- og vector-metadata. Behold det tidligere AnythingLLM-image, indtil dets data-migration- og rollback-boundary er forstået.
