How to Self-Host Langflow in 2026: Flows, API Access and Persistent State

Treat Langflow as a small system, not a Docker image. The user-facing goal for Langflow is clear: visual LLM workflow builder that exposes flows as APIs; the deployment is acceptable only when you can build a flow with a provider credential, run it in the editor, call its API and verify the response after a service restart.

That distinction catches the failure mode operators meet after local testing: a secret changes after restart or component dependencies are absent. It also makes the backup and upgrade plan specific enough to test.

Define success for Langflow first

Do not let the Langflow image choose production architecture by accident. The image supplies a process on 7860; storage, routing and external requirements still need deliberate lifecycles. The network contract for Langflow is Postgres for durable state plus model-provider credentials. Keep private endpoints on internal DNS, permit only required outbound calls and give Langflow a scoped service credential.

The deployment is ready for deeper testing when it can build a flow with a provider credential, run it in the editor, call its API and verify the response after a service restart. Follow the transaction in logs and watch component execution, model latency, parallel API calls, file parsing and database connection count. Those observations reveal whether the current topology isolates the right component.

Launch Langflow with observable defaults

Keep the initial Langflow invocation reproducible enough to review in a 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

Do not rely on latest after real data exists. Capture the working digest, container user and mount ownership. Follow the application log through a complete test — build a flow with a provider credential, run it in the editor, call its API and verify the response after a service restart — and note any migrations before putting the route behind production traffic.

Test Langflow from outside the server

Treat the external Langflow URL as configuration that survives redeploys. First set the public address used by API clients and authentication callbacks; then route the hostname to port 7860 with the original host and scheme intact.

The deployment reachability checklist can prove that requests enter the container. After that point, the known failure — a secret changes after restart or component dependencies are absent — should be investigated in Langflow, its state or its workload rather than in certificate automation.

Separate replaceable containers from lasting data

A container image can be downloaded again; flows, database, API keys and uploaded files cannot. Mount /app/langflow before bootstrap, write harmless sample data and replace the container to prove that path is actually persistent. Inspect the effective mount instead of trusting a Compose filename, and check that the runtime user can write where Langflow expects.

Choose retention and an off-host destination, then rehearse recovery without touching production. The drill passes only when flows, users, credentials and files return and an existing API client can execute the restored flow. For database-backed state, pair storage snapshots with application-consistent exports as described in point-in-time recovery versus snapshots.

Security decisions specific to Langflow

Do not inherit security assumptions from a local tutorial. Langflow's specific concern is exposing flow-building and stored provider keys without authentication. Production should therefore protect the builder, scope API access and keep model credentials in encrypted server-side storage.

Treat LANGFLOW_SECRET_KEY according to its Langflow role: keep sensitive values out of Git, document rotation effects and never substitute a public example in production. Scope filesystem and network access, protect setup endpoints and define upload, request or execution limits around component execution, model latency, parallel API calls, file parsing and database connection count.

Capacity and upgrade checks

The first useful operational metric for Langflow is whether it can build a flow with a provider credential, run it in the editor, call its API and verify the response after a service restart. Pair that with saturation signals for component execution, model latency, parallel API calls, file parsing and database connection count. A process-only probe should not call expensive dependencies or restart the container because an upstream is briefly unavailable.

Treat upgrades as data changes because component packages, database migrations and serialized flows can change across Langflow releases. Pin versions, rehearse on restored state and keep the previous image available until a rollback remains valid. When a secret changes after restart or component dependencies are absent, preserve logs from before the restart; they usually contain the causal message.

Record a known-good Langflow deployment

Convert the Langflow smoke test into a repeatable release command or short runbook. Its output must demonstrate this outcome: build a flow with a provider credential, run it in the editor, call its API and verify the response after a service restart. Record the application version, container digest, route hostname and test-data identifier with the result.

Run the same check after a routine container swap and after restoring flows, database, API keys and uploaded files elsewhere. The restore has succeeded when flows, users, credentials and files return and an existing API client can execute the restored flow. Compare timing and consumption related to component execution, model latency, parallel API calls, file parsing and database connection count; a large change is worth investigation even when the final action still passes.

Then exercise a safe failure: temporarily deny the test identity access to Postgres for durable state plus model-provider credentials. Confirm that Langflow surfaces the fault and returns to normal without destructive manual edits. Preserve only the necessary, redacted log excerpt. This four-part gate covers startup, persistence, recovery and failure handling.

What Dockup should automate for Langflow

The platform layer for Langflow consists of port 7860, ingress, TLS, runtime configuration, storage and dependency reachability. Dockup can reproduce those pieces for its own infrastructure or a server the customer connects.

Then the operator finishes the product layer: set the public address used by API clients and authentication callbacks; enforce this access rule — protect the builder, scope API access and keep model credentials in encrypted server-side storage; and run “build a flow with a provider credential, run it in the editor, call its API and verify the response after a service restart”. Recording that test alongside the deployment avoids confusing automated provisioning with application readiness.

Frequently asked questions

What does Langflow need for a production deployment?

Route the Langflow container on port 7860 through one HTTPS origin. The supporting network requirement is Postgres for durable state plus model-provider credentials. Do not call Langflow ready until you can build a flow with a provider credential, run it in the editor, call its API and verify the response after a service restart.

Which Langflow data belongs in a backup?

Persist /app/langflow and include flows, database, API keys and uploaded files in the same recovery manifest. A clean Langflow restore passes only when flows, users, credentials and files return and an existing API client can execute the restored flow.

Does Langflow require HTTPS behind a reverse proxy?

Use HTTPS for the public Langflow origin and keep port 7860 on the internal route. Apply the Langflow setting correctly: set the public address used by API clients and authentication callbacks. For Langflow, HTTPS protects credentials or user content in transit and keeps origin-sensitive client behavior consistent.

How should a Langflow upgrade be tested?

Restore current Langflow state into an isolated deployment, apply the candidate version and repeat its acceptance transaction. Pay particular attention because component packages, database migrations and serialized flows can change across Langflow releases. Keep the previous Langflow image until its data-migration and rollback boundary are understood.