Sådan selvhoster du Flowise i 2026: Credentials, storage og offentlige URL'er

Den korteste Flowise-demo beviser, at en proces lytter på port 3000. Produktion kræver stærkere dokumentation. Den skal bestå dette scenarie, selv efter at containeren er blevet udskiftet: Opret et lille chatflow, gem en provider credential, kald prediction-endpointet, og fortsæt den samme session efter en containerudskiftning.

Flowise bliver deployed med et klart formål: en visuel builder til LLM chains og callable agents. Den mest almindelige deployment-fælde er, at encryption secret ændres, eller at den mountede datamappe tilhører et andet UID, så håndtering af offentlige URL'er og persistent state skal have samme opmærksomhed som opstart af imaget.

Flowises produktionsarkitektur

Adskil fire områder for Flowise: ingress, lytteren på port 3000, persistent state samt understøttende services eller lokal kapacitet. Flowises netværkskrav er en supported database, når der er behov for mere end en midlertidig single-node-opsætning. Hold private endpoints på intern DNS, tillad kun de nødvendige udgående kald, og giv Flowise en afgrænset service credential.

Kør den kendte transaktion — opret et lille chatflow, gem en provider credential, kald prediction-endpointet, og fortsæt den samme session efter en containerudskiftning — før du betragter denne adskillelse som komplet. Mål parallelle flow-kørsler, document loaders, vector-store-kald og den hukommelse, som custom nodes bruger, og gem resultatet sammen med deployment-recorden. Det giver både et acceptkriterium og det første kapacitetsbaseline.

Tag backup af den state, Flowise ikke kan genskabe

Kortlæg alle persistente artefakter: Flowise-databasen, credentials og uploadede dokumenter. Mount /root/.flowise før bootstrap, skriv harmløse eksempeldata, og udskift containeren for at bevise, at stien rent faktisk er persistent. Medtag konfiguration, der ændrer, hvordan gemte data fortolkes, ikke kun den største mappe.

Fastlæg retention, kopiér backups væk fra hosten, og kør en clean-room-restore. Flowise-øvelsen er gennemført, når flows, credentials og uploadet viden er tilbage, og en eksisterende API-klient kan køre et gendannet flow. Hvis snapshots indgår i planen, kan du bruge vejledningen om PITR kontra snapshots til at dokumentere, hvad hver mekanisme kan gendanne.

Giv ikke Flowise hele hosten

Luk bootstrap-vinduet, så snart den første betroede administrator findes. Flowises konkrete fælde er at lade standardadgang være åben, mens flows indeholder provider secrets; den sikrere grænse er at beskytte den visuelle builder strengere end prediction endpoints og aldrig eksponere provider credentials for browserklienter.

Generér FLOWISE_SECRETKEY_OVERWRITE én gang, hold den ude af Git, og bevar den sammen med recovery-manifestet, fordi en ændring kan ugyldiggøre krypteret eller signeret application state. Privat netværk bør transportere dependency credentials, og roller i Flowise bør kun give den mindst mulige nyttige handling. Hold følsomme request bodies og provider-svar ude af almindelige logs.

Flowises release-gate

Opret en lille, midlertidig Flowise-fixture, og behold den til hver release. Fixturen skal teste det virkelige workflow: Opret et lille chatflow, gem en provider credential, kald prediction-endpointet, og fortsæt den samme session efter en containerudskiftning. Registrér image digest, ekstern hostname, dependency address og det forventede resultat, så en senere operator kan gentage testen uden at skulle fortolke denne guide.

Kør fixturen tre gange. Brug først den friske deployment. Udskift derefter containeren uden at ændre persistent state. Gendan til sidst backup'et i et tomt miljø. Den tredje kørsel består kun, når flows, credentials og uploadet viden er tilbage, og en eksisterende API-klient kan køre et gendannet flow. Under hver kørsel skal du registrere latency og ressourceforbrug omkring parallelle flow-kørsler, document loaders, vector-store-kald og den hukommelse, som custom nodes bruger; det bliver baseline for alerts i stedet for en vilkårlig CPU-procent.

Test til sidst den negative sti med vilje: Afvis midlertidigt testidentitetens adgang til en supported database, når der er behov for mere end en midlertidig single-node-opsætning. Bekræft, at Flowise fejler synligt uden at ødelægge state, genskab den korrekte betingelse, og gentag den vellykkede transaktion. En release-record med disse fire resultater er stærkere dokumentation end screenshots af et dashboard eller et enkelt curl-svar.

Start Flowise med observerbare standarder

Den første container skal være nem at slette og oprette igen. Hold data væk fra det skrivbare layer, bind kun port 3000 dér, hvor proxyen kan nå den, og giv konfigurationen ved runtime.

docker run -d \
  --name flowise \
  --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  -v flowise-data:/root/.flowise \
  -e FLOWISE_SECRETKEY_OVERWRITE=replace-with-a-long-random-value \
  flowiseai/flowise:latest

Pin imaget efter den indledende test. Læs den tidligste startup-fejl i stedet for den sidste restart-meddelelse, verificér hvert mount med docker inspect, og følg logs, mens du opretter et lille chatflow, gemmer en provider credential, kalder prediction-endpointet og fortsætter den samme session efter en containerudskiftning. Denne sekvens skelner mellem en forkert image-kommando og et dependency- eller permission-problem.

Gør den offentlige origin entydig

Browseren, API-klienten og Flowise skal være enige om én origin. For at sikre det skal du angive den application URL, der bruges af callbacks og embedded clients. Bevar den oprindelige host og protokol, men sørg for, at port 3000 ikke er tilgængelig som en konkurrerende offentlig adresse.

Guiden til fejlfinding, når sitet er nede hjælper med at skelne mellem en utilgængelig route og en application, der svarer. Denne forskel er vigtig her: encryption secret ændres, eller den mountede datamappe tilhører et andet UID. Kun det første problem løses med ingress-ændringer; det andet kræver inspektion af Flowise-logs, state eller workload.

Fejløvelser for Flowise

Brug opret et lille chatflow, gem en provider credential, kald prediction-endpointet, og fortsæt den samme session efter en containerudskiftning som Flowises smoke test efter hver deployment. De tilhørende metrics er parallelle flow-kørsler, document loaders, vector-store-kald og den hukommelse, som custom nodes bruger; opret alerts dér, hvor disse ressourcer nærmer sig et niveau, der forringer brugerhandlingen.

Den største ændringsrisiko er, at component packages, database migrations og encrypted credentials kan gå i stykker, når Flowise skifter mellem releases. En sikker release starter fra et restorebart snapshot og validerer alle irreversible state-ændringer, før trafikken flyttes. Når encryption secret ændres, eller den mountede datamappe tilhører et andet UID, skal du beholde den fejlede container længe nok til at læse dens konfiguration og første fejl.

Hvor Dockup fjerner arbejde for Flowise

For Flowise er Dockup mest nyttig ved grænsen mellem et image og en persistent service. Den holder routen til 3000, TLS, secret-værdier og storage tilknyttet på tværs af containerudskiftninger, uanset om compute kører på Dockup eller på din tilknyttede server.

Afslut med application knowledge: Angiv den application URL, der bruges af callbacks og embedded clients; forbind til og test en supported database, når der er behov for mere end en midlertidig single-node-opsætning; og kør denne verifikation: Opret et lille chatflow, gem en provider credential, kald prediction-endpointet, og fortsæt den samme session efter en containerudskiftning. Gem resultatet som et deployment-check, så den næste image-opdatering vurderes ud fra funktionalitet og ikke containerstatus.

Ofte stillede spørgsmål

Hvad kræver Flowise til en produktionsdeployment?

Route Flowise-containeren på port 3000 gennem én HTTPS-origin. Det understøttende netværkskrav er en supported database, når der er behov for mere end en midlertidig single-node-opsætning. Erklær ikke Flowise klar, før du kan oprette et lille chatflow, gemme en provider credential, kalde prediction-endpointet og fortsætte den samme session efter en containerudskiftning.

Hvilke Flowise-data skal med i en backup?

Gør /root/.flowise persistent, og medtag Flowise-databasen, credentials og uploadede dokumenter i det samme recovery-manifest. En clean Flowise-restore består kun, når flows, credentials og uploadet viden er tilbage, og en eksisterende API-klient kan køre et gendannet flow.

Kræver Flowise HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige Flowise-origin, og hold port 3000 på den interne route. Anvend Flowise-indstillingen korrekt: Angiv den application URL, der bruges af callbacks og embedded clients. For Flowise beskytter HTTPS credentials eller brugerindhold under transport og sikrer ensartet origin-følsom klientadfærd.

Hvordan bør en Flowise-opgradering testes?

Gendan den aktuelle Flowise-state i en isoleret deployment, anvend kandidatversionen, og gentag dens accepttransaktion. Vær særligt opmærksom, fordi component packages, database migrations og encrypted credentials kan gå i stykker, når Flowise skifter mellem releases. Behold det tidligere Flowise-image, indtil grænsen for data migration og rollback er forstået.