Så self-hostar du Langflow 2026: Flows, API-åtkomst och persistent state

Se Langflow som ett mindre system, inte som en Docker-avbild. Målet för användaren är tydligt: en visuell LLM-workflowbyggare som exponerar flows som API:er. En deployment är godtagbar först när du kan bygga ett flow med en provider credential, köra det i editorn, anropa dess API och verifiera svaret efter en omstart av tjänsten.

Den skillnaden fångar det fel som driftansvariga stöter på efter lokal testning: en secret ändras efter omstart eller så saknas komponentberoenden. Den gör också planen för backup och uppgraderingar tillräckligt specifik för att kunna testas.

Definiera först vad som räknas som lyckat för Langflow

Låt inte Langflow-avbilden av misstag bestämma produktionsarkitekturen. Avbilden tillhandahåller en process på 7860, men lagring, routing och externa krav behöver fortfarande ha genomtänkta livscykler. Nätverkskontraktet för Langflow är Postgres för persistent state samt credentials till modellprovidern. Håll privata endpoints på intern DNS, tillåt endast nödvändiga utgående anrop och ge Langflow en avgränsad service credential.

Deployen är redo för djupare testning när den kan bygga ett flow med en provider credential, köra det i editorn, anropa dess API och verifiera svaret efter en omstart av tjänsten. Följ transaktionen i loggarna och övervaka komponentkörning, modellfördröjning, parallella API-anrop, filparsning och antalet databasanslutningar. Observationerna visar om den aktuella topologin isolerar rätt komponent.

Starta Langflow med observerbara standardvärden

Håll den första Langflow-starten tillräckligt reproducerbar för att kunna granskas i en pull request.

docker run -d \
  --name langflow \
  --restart unless-stopped \
  -p 127.0.0.1:7860:7860 \
  -v langflow-data:/app/langflow \
  -e LANGFLOW_SECRET_KEY=replace-with-a-long-random-value \
  langflowai/langflow:latest

Förlita dig inte på latest när riktiga data finns. Dokumentera den fungerande digesten, containerns användare och ägarskapet för mounten. Följ applikationsloggen genom ett komplett test — bygg ett flow med en provider credential, kör det i editorn, anropa dess API och verifiera svaret efter en omstart av tjänsten — och notera eventuella migrationer innan du kopplar routen till produktionstrafik.

Testa Langflow utifrån servern

Behandla den externa Langflow-URL:en som konfiguration som ska överleva redeployments. Ange först den publika adress som används av API-klienter och authentication callbacks. Routa sedan hostname till port 7860 med det ursprungliga host-värdet och schemat intakta.

Checklistan för deploymentens nåbarhet kan visa att requests når containern. Därefter bör det kända felet — att en secret ändras efter omstart eller att komponentberoenden saknas — utredas i Langflow, dess state eller dess workload, inte i certifikatautomatiseringen.

Separera utbytbara containers från bestående data

En container-avbild kan laddas ned igen, men flows, databasen, API-nycklar och uppladdade filer kan inte återskapas på samma sätt. Mounta /app/langflow före bootstrap, skriv ofarliga exempeldata och byt ut containern för att bevisa att sökvägen faktiskt är persistent. Kontrollera den effektiva mounten i stället för att lita på ett Compose-filnamn, och verifiera att runtime-användaren kan skriva där Langflow förväntar sig det.

Välj retention och en destination utanför hosten, och öva sedan på återställning utan att röra produktionen. Övningen är godkänd först när flows, användare, credentials och filer är tillbaka och en befintlig API-klient kan köra det återställda flowet. För databaskopplad state kombinerar du storage snapshots med application-consistent exports enligt beskrivningen i point-in-time recovery jämfört med snapshots.

Säkerhetsbeslut som är specifika för Langflow

Ärv inte säkerhetsantaganden från en lokal tutorial. Den specifika risken med Langflow är att exponera flow-byggande och lagrade provider keys utan authentication. I produktion bör du därför skydda buildern, avgränsa API-åtkomsten och lagra modellcredentials i krypterad server-side storage.

Hantera LANGFLOW_SECRET_KEY utifrån dess roll i Langflow: håll känsliga värden borta från Git, dokumentera effekterna av rotation och använd aldrig ett publikt exempelvärde i produktion. Begränsa åtkomsten till filsystem och nätverk, skydda setup-endpoints och definiera gränser för uppladdningar, requests och körningar kring komponentkörning, modellfördröjning, parallella API-anrop, filparsning och antalet databasanslutningar.

Kapacitet och kontroller inför uppgraderingar

Det första användbara driftmåttet för Langflow är om systemet kan bygga ett flow med en provider credential, köra det i editorn, anropa dess API och verifiera svaret efter en omstart av tjänsten. Kombinera det med saturation-signaler för komponentkörning, modellfördröjning, parallella API-anrop, filparsning och antalet databasanslutningar. En probe som bara kontrollerar processen bör inte anropa dyra beroenden eller starta om containern bara för att en upstream-tjänst tillfälligt är otillgänglig.

Behandla uppgraderingar som dataförändringar eftersom komponentpaket, databas-migrationer och serialiserade flows kan ändras mellan Langflow-versioner. Pinna versioner, öva på återställd state och behåll den föregående avbilden till dess att en rollback fortfarande är giltig. När en secret ändras efter omstart eller komponentberoenden saknas ska du spara loggarna från före omstarten. Där finns vanligtvis det orsakande felmeddelandet.

Dokumentera en fungerande Langflow-deployment

Gör Langflows smoke test till ett repeterbart release-kommando eller en kort runbook. Resultatet måste visa följande: bygg ett flow med en provider credential, kör det i editorn, anropa dess API och verifiera svaret efter en omstart av tjänsten. Dokumentera applikationsversion, container digest, route-hostname och identifieraren för testdata tillsammans med resultatet.

Kör samma kontroll efter ett vanligt containerbyte och efter att flows, databasen, API-nycklarna och de uppladdade filerna har återställts någon annanstans. Återställningen är lyckad när flows, användare, credentials och filer är tillbaka och en befintlig API-klient kan köra det återställda flowet. Jämför tidsåtgång och resursförbrukning för komponentkörning, modellfördröjning, parallella API-anrop, filparsning och antalet databasanslutningar. En stor förändring bör utredas även när det slutliga testet fortfarande lyckas.

Testa sedan ett säkert fel: neka tillfälligt testidentiteten åtkomst till Postgres för persistent state samt credentials till modellprovidern. Bekräfta att Langflow visar felet och återgår till normalt läge utan destruktiva manuella ändringar. Spara endast det nödvändiga, redigerade loggutdraget. Den här fyrdelade kontrollen täcker uppstart, persistence, återställning och felhantering.

Vad Dockup bör automatisera för Langflow

Plattformslagret för Langflow består av port 7860, ingress, TLS, runtime-konfiguration, lagring och nåbarhet till beroenden. Dockup kan återskapa dessa delar för den egna infrastrukturen eller för en server som kunden ansluter.

Därefter slutför operatören produktlagret: ange den publika adress som används av API-klienter och authentication callbacks, tillämpa den här åtkomstregeln — skydda buildern, avgränsa API-åtkomsten och lagra modellcredentials i krypterad server-side storage — och kör ”bygg ett flow med en provider credential, kör det i editorn, anropa dess API och verifiera svaret efter en omstart av tjänsten”. Genom att dokumentera testet tillsammans med deploymenten undviker du att blanda ihop automatiserad provisioning med att applikationen är redo.

Vanliga frågor

Vad behöver Langflow för en produktionsdeployment?

Routa Langflow-containern på port 7860 via en HTTPS-origin. Det tillhörande nätverkskravet är Postgres för persistent state samt credentials till modellprovidern. Förklara inte Langflow som redo förrän du kan bygga ett flow med en provider credential, köra det i editorn, anropa dess API och verifiera svaret efter en omstart av tjänsten.

Vilka Langflow-data ska ingå i en backup?

Gör /app/langflow persistent och inkludera flows, databasen, API-nycklar och uppladdade filer i samma recovery manifest. En ren Langflow-återställning är godkänd först när flows, användare, credentials och filer är tillbaka och en befintlig API-klient kan köra det återställda flowet.

Kräver Langflow HTTPS bakom en reverse proxy?

Använd HTTPS för den publika Langflow-originen och behåll port 7860 på den interna routen. Tillämpa Langflow-inställningen korrekt: ange den publika adress som används av API-klienter och authentication callbacks. För Langflow skyddar HTTPS credentials och användarinnehåll under överföring och ser till att origin-känsligt klientbeteende förblir konsekvent.

Hur bör en Langflow-uppgradering testas?

Återställ aktuell Langflow-state till en isolerad deployment, installera kandidatversionen och upprepa acceptanstestet. Var särskilt uppmärksam eftersom komponentpaket, databas-migrationer och serialiserade flows kan ändras mellan Langflow-versioner. Behåll den föregående Langflow-avbilden tills gränserna för datamigrering och rollback är klarlagda.