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

Why host LangFlow on a VPS

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.

What you gain with a self-hosted instance

Visual pipeline interface — drag LLM, retriever, memory, and prompt components onto a canvas, connect them, and test without code.
Multiple LLM connectors — OpenAI, Anthropic, Ollama (local), Hugging Face, and any OpenAI-compatible provider.
Built-in RAG — load PDF or text documents, with chunking, embedding and vector search in the same flow.
Automatic API per flow — each pipeline becomes a REST endpoint callable from any application.
Encrypted global variables — your API keys are stored server-side, never exposed in the client code.
Custom Python components — extend LangFlow with your own business logic without forking the project.
Flow version control — export as JSON and version in Git, independently of the database state.

Prerequisites before you start

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.

Install LangFlow with Docker Compose and PostgreSQL

Create the working directory

mkdir -p /opt/langflow && cd /opt/langflow

Write the docker-compose.yml file

Create a docker-compose.yml file with two services — postgres and langflow — and authentication environment variables:

services:
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_USER: langflow
      POSTGRES_PASSWORD: strong-password
      POSTGRES_DB: langflow
    volumes:
      - pgdata:/var/lib/postgresql/data

  langflow:
    image: langflowai/langflow:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:7860:7860"
    environment:
      LANGFLOW_DATABASE_URL: postgresql://langflow:strong-password@postgres:5432/langflow
      LANGFLOW_SECRET_KEY: change-this-to-a-random-string
      LANGFLOW_AUTO_LOGIN: "false"
      LANGFLOW_SUPERUSER: admin
      LANGFLOW_SUPERUSER_PASSWORD: strong-admin-password
    depends_on:
      - postgres

volumes:
  pgdata:

Note that port 7860 is bound to 127.0.0.1: LangFlow is not reachable from the outside without going through the proxy.

Start the stack

Start both containers in the background:

docker compose up -d

Follow LangFlow logs during the first initialization (schema creation in the database, roughly 30 seconds to 1 minute):

docker compose logs -f langflow

Wait for the line indicating that the server is listening on port 7860 before continuing.

Verify the interface responds

From your VPS, test that LangFlow responds locally before setting up the proxy:

curl -s http://127.0.0.1:7860/health

The expected response is {"status":"ok"}. If you get a connection refused error, the startup logs contain the cause.

Configure the nginx reverse proxy with HTTPS

Install nginx and certbot if not already done, then create a configuration file:

server {
    listen 80;
    server_name langflow.your-domain.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name langflow.your-domain.com;

    ssl_certificate /etc/letsencrypt/live/langflow.your-domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/langflow.your-domain.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:7860;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

The Upgrade and Connection headers are essential for WebSocket support, used by the interactive canvas. Obtain the certificate with certbot:

certbot --nginx -d langflow.your-domain.com

Log in and create your first flow

Open https://langflow.your-domain.com in your browser. Log in with the credentials set in LANGFLOW_SUPERUSER and LANGFLOW_SUPERUSER_PASSWORD. In the interface, click New Flow, choose a template or start from an empty canvas. Add an LLM component, a prompt and an output component, connect them, then click Run to test the pipeline.

Store API keys in global variables

Rather than entering your API keys in each component, use Global Variables (icon at the top right): the key is encrypted in the database and reusable across all your flows. From the API menu of a flow, you retrieve the curl or Python call code to integrate this pipeline into an external application.

Back up flows and the database

Schedule a daily pg_dump of the database from the host:

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

Also export your flows as JSON from the Export menu of each flow: it is a versionable safety net in Git, independent of the database state.

Advanced configuration: useful environment variables

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.

Security: do not expose LangFlow directly to the internet

LangFlow has no built-in rate limiting on its API endpoints. Without additional measures, a publicly exposed flow can be called without limit by anyone who knows the URL. Two approaches complement each other.

First, keep LANGFLOW_AUTO_LOGIN=false permanently and create distinct user accounts for each team member. Second, if your flows should only be called by your own applications (rather than by direct users), add an auth_basic nginx block in front of the management interface and expose only the /api/v1/run/<flow-id> endpoints with token authentication to your applications.

Never leave LangFlow in production with SQLite: the database corrupts under concurrent access and you lose your flows without an explicit error message.

Troubleshooting common errors

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.

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.

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 depends_on in docker-compose.yml waits for the Postgres container to start, but not necessarily for PostgreSQL to be ready to accept connections. Add a healthcheck on the postgres service to force the wait.

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.

Next steps: extending your LangFlow instance

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 document RAG, add a Chroma or Qdrant component — two open source vector databases you can deploy in a neighboring container. Import your PDF documents into a LangFlow flow, chunking and embedding included, and query them from a chatbot or an API.

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.