Slik egenhoster du Langflow i 2026: Flows, API-tilgang og persistent tilstand

Behandle Langflow som et lite system, ikke som et Docker-image. Målet for brukeren er tydelig: en visuell LLM-workflowbygger som eksponerer flows som API-er. Distribusjonen er først godkjent når du kan bygge en flow med en provider credential, kjøre den i editoren, kalle API-et og verifisere svaret etter en omstart av tjenesten.

Dette skillet avdekker feilen operatører ofte møter etter lokal testing: en secret endres etter omstart, eller komponentavhengigheter mangler. Det gjør også planen for sikkerhetskopiering og oppgradering konkret nok til å testes.

Definer hva som er vellykket for Langflow først

Ikke la Langflow-imaget velge produksjonsarkitekturen ved et uhell. Imaget leverer en prosess på port 7860, mens lagring, routing og eksterne avhengigheter fortsatt trenger bevisste livssykluser. Nettverkskontrakten for Langflow er Postgres for persistent tilstand, samt credentials for model providers. Hold private endepunkter på intern DNS, tillat bare nødvendige utgående kall og gi Langflow en avgrenset service credential.

Distribusjonen er klar for grundigere testing når den kan bygge en flow med en provider credential, kjøre den i editoren, kalle API-et og verifisere svaret etter en omstart av tjenesten. Følg transaksjonen i loggene og følg med på komponentkjøring, modell-latens, parallelle API-kall, filparsing og antall databaseforbindelser. Disse observasjonene viser om den aktuelle topologien isolerer riktig komponent.

Start Langflow med observerbare standardinnstillinger

Sørg for at den første oppstarten av Langflow er reproduserbar nok til å gjennomgås 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

Ikke stol på latest etter at det finnes reelle data. Ta vare på den fungerende digest-en, container-brukeren og eierskapet til mounten. Følg applikasjonsloggen gjennom en komplett test — bygg en flow med en provider credential, kjør den i editoren, kall API-et og verifiser svaret etter en omstart av tjenesten — og noter eventuelle migreringer før du legger routen bak produksjonstrafikk.

Test Langflow utenfra serveren

Behandle den eksterne Langflow-URL-en som konfigurasjon som skal overleve redeployments. Angi først den offentlige adressen som brukes av API-klienter og autentiserings-callbacks. Rout deretter hostnavnet til port 7860, og behold den opprinnelige hosten og scheme intakt.

Checklisten for tilgjengelighet etter deployment kan bekrefte at forespørsler kommer inn i containeren. Etter dette bør den kjente feilen — at en secret endres etter omstart, eller at komponentavhengigheter mangler — undersøkes i Langflow, tilstanden eller arbeidsbelastningen, ikke i sertifikatautomatiseringen.

Skill mellom containere som kan byttes ut, og varige data

Et container-image kan lastes ned på nytt; flows, databasen, API-nøkler og opplastede filer kan ikke det. Mount /app/langflow før bootstrap, skriv noen ufarlige eksempeldata og bytt ut containeren for å bevise at banen faktisk er persistent. Inspiser den effektive mounten i stedet for å stole på et Compose-filnavn, og kontroller at runtime-brukeren kan skrive der Langflow forventer det.

Velg retention og en destinasjon utenfor hosten, og øv på gjenoppretting uten å berøre produksjon. Øvelsen er bare godkjent når flows, brukere, credentials og filer er tilbake, og en eksisterende API-klient kan kjøre den gjenopprettede flowen. For databasebasert tilstand bør du kombinere storage snapshots med applikasjonskonsistente exporter, som beskrevet i point-in-time recovery versus snapshots.

Sikkerhetsvalg som er spesifikke for Langflow

Ikke arve sikkerhetsantakelser fra en lokal tutorial. Langflows spesifikke utfordring er å eksponere flow-bygging og lagrede provider keys uten autentisering. Produksjon bør derfor beskytte builderen, avgrense API-tilgang og oppbevare model credentials i kryptert lagring på serversiden.

Behandle LANGFLOW_SECRET_KEY ut fra rollen den har i Langflow: hold sensitive verdier ute av Git, dokumenter effekten av rotasjon og bruk aldri et offentlig eksempel i produksjon. Avgrens filsystem- og nettverkstilgang, beskytt setup-endepunkter og definer grenser for opplastinger, forespørsler eller kjøring rundt komponentkjøring, modell-latens, parallelle API-kall, filparsing og antall databaseforbindelser.

Kapasitet og oppgraderingssjekker

Det første nyttige driftsmålet for Langflow er om den kan bygge en flow med en provider credential, kjøre den i editoren, kalle API-et og verifisere svaret etter en omstart av tjenesten. Kombiner dette med metningssignaler for komponentkjøring, modell-latens, parallelle API-kall, filparsing og antall databaseforbindelser. En probe som bare sjekker prosessen, bør ikke kalle kostbare avhengigheter eller starte containeren på nytt fordi en upstream-tjeneste er midlertidig utilgjengelig.

Behandle oppgraderinger som dataendringer, fordi komponentpakker, databasemigreringer og serialiserte flows kan endres mellom Langflow-releaser. Lås versjoner, øv på gjenoppretting på gjenopprettet tilstand og behold det forrige imaget tilgjengelig til en rollback fortsatt er gyldig. Når en secret endres etter omstart, eller komponentavhengigheter mangler, bør du ta vare på loggene fra før omstarten. De inneholder vanligvis den utløsende meldingen.

Dokumenter en Langflow-distribusjon som fungerer

Gjør Langflow-smoketesten om til en repeterbar release-kommando eller en kort runbook. Resultatet må dokumentere dette: bygg en flow med en provider credential, kjør den i editoren, kall API-et og verifiser svaret etter en omstart av tjenesten. Registrer applikasjonsversjonen, container-digest-en, route-hostnavnet og identifikatoren for testdataene sammen med resultatet.

Kjør den samme kontrollen etter et vanlig containerbytte og etter at flows, databasen, API-nøklene og de opplastede filene er gjenopprettet et annet sted. Gjenopprettingen er vellykket når flows, brukere, credentials og filer er tilbake, og en eksisterende API-klient kan kjøre den gjenopprettede flowen. Sammenlign tidsbruk og forbruk knyttet til komponentkjøring, modell-latens, parallelle API-kall, filparsing og antall databaseforbindelser. En stor endring bør undersøkes, selv når den endelige handlingen fortsatt lykkes.

Test deretter en kontrollert feil: nekt midlertidig testidentiteten tilgang til Postgres for persistent tilstand og credentials for model providers. Bekreft at Langflow viser feilen og går tilbake til normal drift uten destruktive manuelle endringer. Ta bare vare på det nødvendige, redigerte loggutdraget. Denne kontrollen i fire deler dekker oppstart, persistens, gjenoppretting og feilhåndtering.

Hva Dockup bør automatisere for Langflow

Plattformlaget for Langflow består av port 7860, ingress, TLS, runtime-konfigurasjon, lagring og tilgjengelighet til avhengigheter. Dockup kan gjenskape disse delene for sin egen infrastruktur eller for en server kunden kobler til.

Deretter fullfører operatøren produktlaget: angi den offentlige adressen som brukes av API-klienter og autentiserings-callbacks; håndhev denne tilgangsregelen — beskytt builderen, avgrens API-tilgang og oppbevar model credentials i kryptert lagring på serversiden — og kjør «bygg en flow med en provider credential, kjør den i editoren, kall API-et og verifiser svaret etter en omstart av tjenesten». Når testen registreres sammen med deploymenten, unngår man å forveksle automatisert klargjøring med at applikasjonen er klar.

Ofte stilte spørsmål

Hva trenger Langflow for en produksjonsdistribusjon?

Rout Langflow-containeren på port 7860 gjennom én HTTPS-origin. Det støttende nettverkskravet er Postgres for persistent tilstand, samt credentials for model providers. Ikke erklær Langflow klar før du kan bygge en flow med en provider credential, kjøre den i editoren, kalle API-et og verifisere svaret etter en omstart av tjenesten.

Hvilke Langflow-data bør inngå i en sikkerhetskopi?

Gjør /app/langflow persistent, og inkluder flows, databasen, API-nøkler og opplastede filer i det samme gjenopprettingsmanifestet. En ren Langflow-gjenoppretting er bare vellykket når flows, brukere, credentials og filer er tilbake, og en eksisterende API-klient kan kjøre den gjenopprettede flowen.

Krever Langflow HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige Langflow-originen, og behold port 7860 på den interne routen. Bruk Langflow-innstillingen riktig: angi den offentlige adressen som brukes av API-klienter og autentiserings-callbacks. For Langflow beskytter HTTPS credentials eller brukerinnhold under overføring og sørger for konsistent klientadferd som er avhengig av origin.

Hvordan bør en Langflow-oppgradering testes?

Gjenopprett den aktuelle Langflow-tilstanden i en isolert deployment, bruk kandidatversjonen og gjenta godkjenningstesten. Vær spesielt oppmerksom, fordi komponentpakker, databasemigreringer og serialiserte flows kan endres mellom Langflow-releaser. Behold det forrige Langflow-imaget til grensene for datamigrering og rollback er forstått.