Sådan self-hoster du Langflow i 2026: Flows, API-adgang og persistent state

Betragt Langflow som et lille system, ikke som et Docker-image. Det brugerrettede mål med Langflow er klart: en visuel LLM-workflowbuilder, der eksponerer flows som API'er. Deploymentet er kun acceptabelt, når du kan bygge et flow med en provider credential, køre det i editoren, kalde dets API og verificere svaret efter en genstart af en service.

Den skelnen fanger den fejltilstand, operatører møder efter lokal test: en secret ændres efter en genstart, eller component dependencies mangler. Den gør også backup- og upgrade-planen tilstrækkeligt specifik til, at den kan testes.

Definér først, hvad succes betyder for Langflow

Lad ikke Langflow-imaget tilfældigt bestemme produktionsarkitekturen. Imaget leverer en proces på port 7860, men storage, routing og eksterne krav har stadig brug for bevidste livscyklusser. Netværkskontrakten for Langflow er Postgres til persistent state samt model-provider credentials. Hold private endpoints på intern DNS, tillad kun de nødvendige outbound-kald, og giv Langflow en afgrænset service credential.

Deploymentet er klar til mere grundig test, når det kan bygge et flow med en provider credential, køre det i editoren, kalde dets API og verificere svaret efter en genstart af en service. Følg transaktionen i logs, og hold øje med component execution, model latency, parallelle API-kald, file parsing og antallet af databaseforbindelser. Disse observationer viser, om den aktuelle topologi isolerer den rigtige komponent.

Start Langflow med defaults, der kan observeres

Hold den første Langflow-invocation tilstrækkeligt reproducerbar til, at den kan gennemgås i et 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

Stol ikke på latest, når der først findes rigtige data. Gem det fungerende digest, container-brugeren og ejerskabet af mountet. Følg application-loggen gennem en komplet test — byg et flow med en provider credential, kør det i editoren, kald dets API, og verificer svaret efter en genstart af en service — og notér eventuelle migrations, før du lægger routen bag produktions-trafik.

Test Langflow udefra serveren

Betragt den eksterne Langflow-URL som konfiguration, der skal overleve redeployments. Angiv først den offentlige adresse, som API-klienter og authentication callbacks bruger. Rout derefter hostnavnet til port 7860, mens den oprindelige host og scheme bevares.

Tjeklisten for deployment reachability kan dokumentere, at requests når ind i containeren. Derefter bør den kendte fejl — at en secret ændres efter en genstart, eller at component dependencies mangler — undersøges i Langflow, dets state eller dets workload, ikke i certificate automation.

Adskil udskiftelige containere fra permanente data

Et container-image kan downloades igen; flows, database, API keys og uploadede filer kan ikke. Mount /app/langflow før bootstrap, skriv harmløse eksempeldata, og udskift containeren for at bevise, at stien faktisk er persistent. Kontrollér det effektive mount i stedet for at stole på et Compose-filnavn, og tjek, at runtime-brugeren kan skrive dér, hvor Langflow forventer det.

Vælg retention og en destination uden for hosten, og øv recovery uden at røre produktionen. Øvelsen er kun bestået, når flows, brugere, credentials og filer er tilbage, og en eksisterende API-klient kan køre det gendannede flow. For database-backed state skal storage snapshots kombineres med application-consistent exports som beskrevet i point-in-time recovery versus snapshots.

Sikkerhedsbeslutninger, der er specifikke for Langflow

Overtag ikke sikkerhedsantagelser fra en lokal tutorial. Langflows specifikke problem er at eksponere flow-building og gemte provider keys uden authentication. Produktion bør derfor beskytte builderen, begrænse API-adgang og opbevare model credentials i krypteret server-side storage.

Behandl LANGFLOW_SECRET_KEY i overensstemmelse med dets rolle i Langflow: Hold sensitive værdier ude af Git, dokumentér konsekvenserne af rotation, og brug aldrig et offentligt eksempel i produktion. Begræns filesystem- og netværksadgang, beskyt setup endpoints, og definér grænser for upload, requests eller execution omkring component execution, model latency, parallelle API-kald, file parsing og antallet af databaseforbindelser.

Kapacitet og upgrade checks

Den første nyttige operationelle metric for Langflow er, om det kan bygge et flow med en provider credential, køre det i editoren, kalde dets API og verificere svaret efter en genstart af en service. Kombinér det med saturation-signaler for component execution, model latency, parallelle API-kald, file parsing og antallet af databaseforbindelser. En process-only probe bør ikke kalde dyre dependencies eller genstarte containeren, fordi en upstream-service kortvarigt er utilgængelig.

Betragt upgrades som dataændringer, fordi component packages, database migrations og serialiserede flows kan ændre sig mellem Langflow-releases. Pin versioner, øv dig på restored state, og behold det tidligere image tilgængeligt, indtil en rollback stadig er gyldig. Når en secret ændres efter en genstart, eller component dependencies mangler, skal du gemme logs fra før genstarten. De indeholder som regel den kausale besked.

Dokumentér et Langflow-deployment, der er kendt for at virke

Gør Langflow-smoketesten til en reproducerbar release-kommando eller en kort runbook. Outputtet skal dokumentere dette resultat: byg et flow med en provider credential, kør det i editoren, kald dets API, og verificer svaret efter en genstart af en service. Registrér application-versionen, container-digestet, route-hostnavnet og testdataets identifier sammen med resultatet.

Kør den samme kontrol efter en almindelig containerudskiftning og efter en gendannelse af flows, database, API keys og uploadede filer et andet sted. Restore er lykkedes, når flows, brugere, credentials og filer er tilbage, og en eksisterende API-klient kan køre det gendannede flow. Sammenlign timing og forbrug relateret til component execution, model latency, parallelle API-kald, file parsing og antallet af databaseforbindelser. En stor ændring bør undersøges, selv når den afsluttende handling stadig består.

Udfør derefter en sikker fejltest: Afvis midlertidigt testidentitetens adgang til Postgres til persistent state samt model-provider credentials. Bekræft, at Langflow viser fejlen og vender tilbage til normal drift uden destruktive manuelle ændringer. Gem kun det nødvendige, redigerede logudsnit. Denne gate i fire dele dækker startup, persistence, recovery og fejlhåndtering.

Hvad Dockup bør automatisere for Langflow

Platformlaget for Langflow består af port 7860, ingress, TLS, runtime-konfiguration, storage og dependency reachability. Dockup kan reproducere disse dele for sin egen infrastruktur eller på en server, kunden tilslutter.

Derefter færdiggør operatøren produktlaget: Angiv den offentlige adresse, som API-klienter og authentication callbacks bruger; håndhæv denne adgangsregel — beskyt builderen, begræns API-adgang, og opbevar model credentials i krypteret server-side storage — og kør “byg et flow med en provider credential, kør det i editoren, kald dets API, og verificer svaret efter en genstart af en service”. Når testen registreres sammen med deploymentet, undgår man at forveksle automatiseret provisioning med application readiness.

Ofte stillede spørgsmål

Hvad skal Langflow bruge til et produktionsdeployment?

Rout Langflow-containeren på port 7860 gennem én HTTPS-origin. Det understøttende netværkskrav er Postgres til persistent state samt model-provider credentials. Kald ikke Langflow klar, før du kan bygge et flow med en provider credential, køre det i editoren, kalde dets API og verificere svaret efter en genstart af en service.

Hvilke Langflow-data hører hjemme i en backup?

Gør /app/langflow persistent, og medtag flows, database, API keys og uploadede filer i det samme recovery-manifest. En ren Langflow-restore er kun bestået, når flows, brugere, credentials og filer er tilbage, og en eksisterende API-klient kan køre det gendannede flow.

Kræver Langflow HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige Langflow-origin, og behold port 7860 på den interne route. Anvend Langflow-indstillingen korrekt: Angiv den offentlige adresse, som API-klienter og authentication callbacks bruger. For Langflow beskytter HTTPS credentials eller brugerindhold under transport og sikrer ensartet origin-sensitive client behavior.

Hvordan bør en Langflow-upgrade testes?

Gendan den aktuelle Langflow-state i et isoleret deployment, anvend kandidatversionen, og gentag den tilhørende acceptance transaction. Vær særligt opmærksom, fordi component packages, database migrations og serialiserede flows kan ændre sig mellem Langflow-releases. Behold det tidligere Langflow-image, indtil dets data-migration- og rollback-grænse er forstået.