How to host LangFlow on a VPS: complete Docker and HTTPS guide

LangFlow addresses a specific use case: designing AI pipelines by dragging and dropping components — LLM models, retrievers, prompts, memory, agents — then testing them without writing a single line of code. It is the visual alternative to code-only LangChain, suited to teams that want to iterate quickly before committing logic to Python.

On a VPS, you get a stable and persistent instance accessible to the whole team, unlike a local setup that disappears on reboot. Your flows often encode sensitive business logic — prompt chains, API keys, connectors to your databases. This data should not pass through a SaaS whose data retention policy you do not control.

LangFlow relies on FastAPI on the server side and exposes each flow as a REST endpoint: your applications can call your AI pipelines directly, with no intermediary code. It is this combination — visual interface for design, API for integration — that makes it a serious prototyping tool for use cases such as document RAG, support chatbots, multi-step agents, or classification pipelines.

LangFlow is more memory-intensive than a typical web application: its execution engine loads models and embeddings into RAM. Plan for at least 2 vCPU and 4 GB of RAM for comfortable use. If you connect a local Ollama model for inference on the same VPS, move to 8 GB minimum.

On the software side, you need Docker (version 24 or later) and Docker Compose v2, installed and running. Port 7860 must be accessible locally (LangFlow listens on this port by default). You do not expose this port directly to the internet: the nginx reverse proxy handles that.

Prepare a subdomain pointing to your VPS IP — for example langflow.your-domain.com — with DNS records already propagated before running certbot. Finally, a PostgreSQL database is strongly recommended for production: the default SQLite corrupts under concurrent load and does not support simultaneous access by multiple users.

Each LangFlow flow is accessible via the /api/v1/run/<flow-id> endpoint. You find the flow identifier in the editor URL or in the flow's API menu. Two concrete examples.

With curl:

curl -s -X POST \
  https://langflow.your-domain.com/api/v1/run/YOUR-FLOW-ID \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR-API-KEY" \
  -d '{
    "input_value": "What is the capital of France?",
    "input_type": "chat",
    "output_type": "chat"
  }'

With Python (requests library):

import requests

FLOW_ID = "YOUR-FLOW-ID"
BASE_URL = "https://langflow.your-domain.com"
API_KEY = "YOUR-API-KEY"

response = requests.post(
    f"{BASE_URL}/api/v1/run/{FLOW_ID}",
    headers={
        "Content-Type": "application/json",
        "x-api-key": API_KEY,
    },
    json={
        "input_value": "What is the capital of France?",
        "input_type": "chat",
        "output_type": "chat",
    },
    timeout=60,
)

result = response.json()
print(result["outputs"][0]["outputs"][0]["results"]["message"]["text"])

The API key is generated in Settings → API Keys in the LangFlow interface. It authenticates each call and can be revoked at any time without touching the flow.

RAG (Retrieval-Augmented Generation) is the central use case of LangFlow: you load documents (PDF, text, Markdown), split them into chunks, embed them into a vector database, then an LLM answers questions by drawing on this context.

Which VectorStore on a VPS? On a server with limited resources, Chroma (ChromaDB) is the lightest choice: it runs in-process in the same LangFlow container, requires no additional service, and persists its data in a local directory. Qdrant is suitable if you have more RAM and want a dedicated service in a neighboring container.

Building the indexing pipeline in LangFlow:

In the editor, assemble the following chain by dragging components:

1. File (or Directory) → loads the PDF or document folder.
2. Split Text → splits into chunks (recommended size: 500 to 800 tokens, overlap 50).
3. OpenAI Embeddings (or Ollama Embeddings to stay fully local) → transforms each chunk into a vector.
4. Chroma DB → stores the vectors. Point the Persist Directory field to a Docker-mounted volume so the index survives restarts.

For the Chroma volume, add to your docker-compose.yml:

  langflow:
    volumes:
      - chromadb:/data/chroma

volumes:
  pgdata:
  chromadb:

Then define the LangFlow global variable CHROMA_PERSIST_DIR with the value /data/chroma.

Query pipeline:

Once the index is populated, create a second flow: Text Input → Chroma DB (in search mode, same directory) → Prompt (inject retrieved chunks) → LLM → Chat Output. Each question triggers a vector search, retrieves the closest passages, and submits them to the model with context.

LangFlow lets you create custom Python components without forking the project. A component is a class that inherits from Component and declares its inputs, outputs, and logic.

Minimal example — a component that cleans and uppercases received text:

from langflow.custom import Component
from langflow.io import MessageTextInput, Output
from langflow.schema import Data

class UpperCaseComponent(Component):
    display_name = "Uppercase Text"
    description = "Converts text to uppercase."

    inputs = [
        MessageTextInput(
            name="input_text",
            display_name="Input Text",
        )
    ]

    outputs = [
        Output(
            display_name="Processed Text",
            name="output_text",
            method="process_text",
        )
    ]

    def process_text(self) -> Data:
        result = self.input_text.strip().upper()
        return Data(text=result)

To add this component to your instance: in the LangFlow interface, go to Settings → Custom Components, paste the code and save. The component immediately appears in the sidebar, ready to be dragged into any flow.

LangFlow releases updates regularly (the 1.x branch is the active stable branch as of October 2026). Before any update, systematically back up the database:

docker exec langflow-postgres-1 pg_dump -U langflow langflow \
  > /opt/backups/langflow-before-update-$(date +%F).sql

Then update the image and restart the stack:

cd /opt/langflow
docker compose pull
docker compose up -d

Follow the logs to detect any automatic schema migrations:

docker compose logs -f langflow

Watch out for breaking changes in v1.x. Some components are renamed or refactored between minor versions. Export your flows as JSON before upgrading — it is the fastest way to restore them to a known state if a migration causes issues.

To pin a specific version (recommended in production), replace latest with the desired tag in your docker-compose.yml:

image: langflowai/langflow:1.12.4

LangFlow exposes several environment variables to adapt the instance to your context. LANGFLOW_SECRET_KEY encrypts sensitive data stored in the database — change the default value before first startup, as a later rotation invalidates existing encrypted data. LANGFLOW_AUTO_LOGIN set to false always requires an explicit login, even from localhost. LANGFLOW_WORKERS controls the number of Uvicorn processes: the default value (1) is suitable for moderate use, increase to 2 or 4 if multiple users execute flows simultaneously.

For flows that call local models via Ollama, define OLLAMA_BASE_URL in LangFlow's global variables rather than in the Docker environment: the value is then managed by the interface and can be changed without a restart.

If you update LangFlow, always do a pg_dump before docker compose pull && docker compose up -d: some version upgrades touch the database schema.

OOM error (Out of Memory). If the LangFlow container restarts spontaneously, check docker compose logs langflow and look for Killed. The cause is insufficient RAM. Reduce LANGFLOW_WORKERS to 1 and, if the problem persists, increase the VPS RAM or avoid running heavy flows simultaneously.

RuntimeError: CUDA out of memory. This error occurs when a component attempts to use a GPU (via PyTorch or a Hugging Face model) but the VPS has none, or GPU memory is insufficient. Force CPU execution by adding the environment variable CUDA_VISIBLE_DEVICES="" to the langflow service in docker-compose.yml. If the error comes from a Hugging Face model, select a CPU variant (suffix -cpu or gguf) in the component.

Port 7860 already in use. If docker compose up -d fails with address already in use, another process is listening on that port. Identify it with ss -tlnp | grep 7860 and stop it, or change the host port in docker-compose.yml (for example "127.0.0.1:7861:7860") and update the nginx configuration accordingly.

ImportError: No module named 'torch' or missing dependency. Some advanced components (Hugging Face embeddings, local models) require heavy libraries not included in the base image. Create a derived Dockerfile that installs missing dependencies, or use the langflowai/langflow-backend image with the required extras.

Connection refused to Ollama. If LangFlow cannot reach Ollama running on the same VPS, check that Ollama listens on 0.0.0.0 and not only on 127.0.0.1. In docker-compose.yml, add extra_hosts: ["host-gateway:host-gateway"] to the LangFlow service and use the address http://host-gateway:11434 in LangFlow's Ollama components.

Blank canvas or disconnected WebSocket. Check that the Upgrade and Connection headers are properly forwarded by nginx. An intermediate proxy (Cloudflare in Full Strict mode, load balancer) may intercept WebSockets: ensure the WebSocket protocol is properly configured in the proxy.

Missing or incomplete flow logs. LangFlow stores execution logs in the database. If the PostgreSQL database was not ready when LangFlow started, the first requests fail silently. The healthcheck in the docker-compose.yml example above resolves this problem.

Once LangFlow is running, several integrations expand its scope.

If you want a fully local LLM model (without any external API call), install Ollama on the same VPS and connect it to LangFlow via the Ollama component: your pipelines no longer send data outside your infrastructure. Ollama exposes an OpenAI-compatible API on port 11434.

For more robust document RAG, move from Chroma to Qdrant — an open source vector database you deploy in a neighboring container with better performance on large corpora.

Finally, if multiple teams use the instance, consider isolating flows by workspace (feature available depending on the version) or deploying one LangFlow instance per project with the ServOrbit template, which automatically configures Docker Compose, PostgreSQL and the reverse proxy.