Deploy Langflow with multiple workers

import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem';

By default, Langflow runs with a single worker process and stores build job state in memory.

A single-worker process is fine for development, but it doesn't scale when you run more than one worker. A flow build started on worker A cannot be polled or streamed from worker B because the in-memory job queue is per-process.

A multi-worker deployment runs more than one worker process on the same host. Concurrency can be increased by increasing the number of LANGFLOW_WORKERS, but each process keeps its own in-memory build queue unless you add a shared store.

A Redis-backed job queue stores build events in Redis Streams, so any worker can pick up and serve any job's events. To configure a multi-worker Langflow process, follow the steps to enable the Redis job queue.

After the Redis job queue is configured, you can optionally follow recommended Gunicorn settings to reduce memory use and keep workers healthy. This tuning applies to Linux production hosts only. On Windows and macOS, langflow run uses a single Uvicorn process.

Prerequisites

• Redis 6 or later, reachable from all Langflow worker processes.
• All workers configured with the same LANGFLOW_JOB_QUEUE_TYPE. Mixed-mode deployments (some workers using asyncio, others using redis) are not supported.
• A dedicated Redis database index for the job queue. The cache uses DB 0 by default; the job queue defaults to DB 1. Using the same index for both will cause key collisions.

Enable the Redis job queue

To enable the Redis job queue, set the following environment variables on all workers:

LANGFLOW_WORKERS=3  # any value > 1
LANGFLOW_JOB_QUEUE_TYPE=redis
LANGFLOW_REDIS_QUEUE_URL=redis://your-redis-host:6379/1

Redis authentication and TLS are only supported through LANGFLOW_REDIS_QUEUE_URL. The individual host/port settings LANGFLOW_REDIS_QUEUE_HOST and LANGFLOW_REDIS_QUEUE_PORT create a plain, unauthenticated connection. If you use a managed Redis service with auth or TLS, you must use LANGFLOW_REDIS_QUEUE_URL.

Example: multi-worker Docker Compose

This example runs three Langflow workers sharing a Redis job queue and a PostgreSQL database.

To run this example you need:

• Docker and Docker Compose (or Podman Desktop)
• At least 4 GB of memory and 2 CPUs available to the container runtime

:::tip If you are using Podman Desktop, the default machine might not have enough resources to run this stack. Before starting, increase the machine's CPU and memory allocation:

podman machine stop
podman machine set --cpus 4 --memory 4096
podman machine start

:::

1. Paste the following example into a Docker Compose file named docker-compose.yml:

   yamlCopy

   services:
     langflow:
       image: langflowai/langflow:1.10.0
       pull_policy: always
       ports:
         - "7860:7860"
       depends_on:
         redis:
           condition: service_healthy
         postgres:
           condition: service_started
       environment:
         - LANGFLOW_DATABASE_URL=postgresql://langflow:langflow@postgres:5432/langflow
         - LANGFLOW_CONFIG_DIR=/app/langflow
         - LANGFLOW_WORKERS=3  # any value > 1
         - LANGFLOW_GUNICORN_PRELOAD=true
         - LANGFLOW_JOB_QUEUE_TYPE=redis
         - LANGFLOW_REDIS_QUEUE_URL=redis://redis:6379/1
         - LANGFLOW_SUPERUSER=admin
         - LANGFLOW_SUPERUSER_PASSWORD=changeme
         - LANGFLOW_AUTO_LOGIN=False
       volumes:
         - langflow-data:/app/langflow
   
     redis:
       image: redis:7-alpine
       healthcheck:
         test: ["CMD", "redis-cli", "ping"]
         interval: 5s
         timeout: 3s
         retries: 5
   
     postgres:
       image: postgres:16-trixie
       environment:
         POSTGRES_USER: langflow
         POSTGRES_PASSWORD: langflow
         POSTGRES_DB: langflow
       volumes:
         - langflow-postgres:/var/lib/postgresql/data
   
   volumes:
     langflow-postgres:
     langflow-data:
   

2. Start the services:

   bashCopy

   docker compose up -d
   

3. Watch the logs until Langflow is ready:

   bashCopy

   docker compose logs -f langflow
   

   These lines confirm a successful multi-worker boot:

   Copy

   [preload] initializing services in master
   [preload] master preload complete; workers will inherit shared state via COW
   ✓ Launching Langflow...
   

4. Create a superuser token using the username and password set in the Docker Compose file:

   bashCopy

   TOKEN=$(curl -s -X POST http://localhost:7860/api/v1/login \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -d "username=admin&password=changeme" \
     | python3 -c "import sys,json; print(json.load(sys.stdin)['access_token'])")
   

5. In the same terminal session, verify the Redis queue is active:

   bashCopy

   curl -s -H "Authorization: Bearer $TOKEN" \
     http://localhost:7860/api/v1/monitor/job_queue | python3 -m json.tool
   

   A response looks like the following:

   jsonCopy

   {
     "backend": "redis",
     "active_jobs": 0,
     "bridge_count": 0,
     "consumer_wrapper_count": 0,
     "background_task_count": 0,
     "cancel_dispatcher_running": true,
     "cancel_stats": {
       "published": 0,
       "marker_hit": 0,
       "dispatched_owned": 0,
       "dispatched_foreign": 0,
       "publish_errors": 0,
       "dispatcher_reconnects": 0,
       "dispatcher_internal_errors": 0,
       "polling_watchdog_kills": 0,
       "activity_touch_errors": 0,
       "activity_get_errors": 0,
       "activity_parse_errors": 0
     }
   }
   

   backend: redis confirms the queue is using Redis, and cancel_dispatcher_running: true confirms the cross-worker cancel channel is active.

6. In the same terminal session, poll the monitor/job_queue endpoint:

   bashCopy

   while true; do
     clear
     curl -s -H "Authorization: Bearer $TOKEN" \
       http://localhost:7860/api/v1/monitor/job_queue | python3 -m json.tool
     sleep 1
   done
   

7. Open the Langflow UI and build a flow by sending a message to the flow in the Playground. The number of active_jobs reported by the monitor/job_queue endpoint increases, confirming your Redis queue is working.

Verify cross-worker cancellation

To verify that cancellation works across workers, trigger a build with the API to capture the job_id and then cancel it.

1. Use the API to build a flow by its flow_id:

   bashCopy

   curl -s -X POST "http://localhost:7860/api/v1/build/af7dc029-279e-4742-8419-1ac23898afdd/flow" \
     -H "Authorization: Bearer $TOKEN" \
     -H "Content-Type: application/json" \
     -d '{"inputs": {"input_value": "hello"}, "stream": false}' | python3 -m json.tool
   

   Response:

   jsonCopy

   {
       "job_id": "1af960e9-12d5-48ec-9860-8a90a16f0b55"
   }
   

   The returned job_id can be used to cancel build jobs in the queue.

2. To cancel a build job, send a request with the job_id:

   bashCopy

   curl -s -X POST http://localhost:7860/api/v1/build/1af960e9-12d5-48ec-9860-8a90a16f0b55/cancel \
     -H "Authorization: Bearer $TOKEN" | python3 -m json.tool
   

   Response:

   jsonCopy

   {
       "success": true,
       "message": "Flow build cancelled successfully"
   }
   

3. Confirm the monitor/job_queue endpoint reports the cancellation:

   jsonCopy

   {
       "backend": "redis",
       "active_jobs": 0,
       "bridge_count": 0,
       "consumer_wrapper_count": 0,
       "background_task_count": 0,
       "cancel_dispatcher_running": true,
       "cancel_stats": {
           "published": 1,
           "marker_hit": 0,
           "dispatched_owned": 0,
           "dispatched_foreign": 2,
           "publish_errors": 0,
           "dispatcher_reconnects": 0,
           "dispatcher_internal_errors": 0,
           "polling_watchdog_kills": 0,
           "activity_touch_errors": 0,
           "activity_get_errors": 0,
           "activity_parse_errors": 0
       }
   }
   

   dispatched_foreign increments when the signal is dispatched to a job owned by a different worker, which confirms the cross-worker cancel path is working.

   For more information, see Monitor the job queue.

Troubleshoot

See Troubleshoot multi-worker deployments.

Configuration reference

Monitor the job queue

The GET /monitor/job_queue endpoint returns a metrics snapshot for the running worker. It requires superuser authentication and returns HTTP 403 otherwise.

curl -H "Authorization: Bearer $LANGFLOW_SUPERUSER_TOKEN" \
  http://localhost:7860/api/v1/monitor/job_queue

Example response for the Redis backend:

{
  "backend": "redis",
  "active_jobs": 2,
  "bridge_count": 1,
  "consumer_wrapper_count": 1,
  "background_task_count": 0,
  "cancel_dispatcher_running": true,
  "cancel_stats": {
    "published": 5,
    "marker_hit": 1,
    "dispatched_owned": 3,
    "dispatched_foreign": 2,
    "publish_errors": 0,
    "dispatcher_reconnects": 0,
    "dispatcher_internal_errors": 0,
    "polling_watchdog_kills": 0,
    "activity_touch_errors": 0,
    "activity_get_errors": 0,
    "activity_parse_errors": 0
  }
}

For the in-memory (asyncio) backend, only backend and active_jobs are returned.

Response body

The Redis backend response includes the following fields:

Recommended Gunicorn settings

:::tip This tuning is optional, and it applies to Linux only. It does not replace the Redis job queue.

On Windows and macOS, langflow run uses one Uvicorn process, so LANGFLOW_GUNICORN_PRELOAD and GUNICORN_CMD_ARGS have no effect. :::

These recommendations are starting points from Langflow engineering benchmarks on Linux multi-worker deployments. After you apply these values, monitor performance, and then make adjustments using htop or btop while you run flows.

Add the starter values to your server's .env file after the Redis job queue settings, then restart Langflow. Copy the block that best matches your server:

Start with fewer workers so Langflow and local databases do not hit OOM.

LANGFLOW_WORKERS=5
LANGFLOW_WORKER_TIMEOUT=120
LANGFLOW_GUNICORN_PRELOAD=true
GUNICORN_CMD_ARGS="--max-requests 100 --max-requests-jitter 20"

A balanced default for a dedicated Langflow host.

LANGFLOW_WORKERS=15
LANGFLOW_WORKER_TIMEOUT=300
LANGFLOW_GUNICORN_PRELOAD=true
GUNICORN_CMD_ARGS="--max-requests 250 --max-requests-jitter 50"

Agent loops use more RAM per request, so a lower --max-requests value restarts workers more often to keep long-term usage consistent.

LANGFLOW_WORKERS=30
LANGFLOW_WORKER_TIMEOUT=600
LANGFLOW_GUNICORN_PRELOAD=true
GUNICORN_CMD_ARGS="--max-requests 150 --max-requests-jitter 30"

• LANGFLOW_WORKERS — How many Gunicorn worker processes run for concurrency.
• LANGFLOW_WORKER_TIMEOUT — How long a worker may handle a single request before Gunicorn kills it. Raise it if you expect long agent runs.
• LANGFLOW_GUNICORN_PRELOAD — Loads the app once in the Gunicorn master before workers fork so Linux can share memory across workers through Copy-on-Write. Recommended to leave enabled in multi-worker deployments for memory savings. Safe to leave off; behavior matches older releases when false.
• GUNICORN_CMD_ARGS — Recycles workers after a set number of requests so memory usage growth does not continuously accumulate. --max-requests restarts a worker after it processes that many requests; --max-requests-jitter adds a random extra 0–N requests on top of that limit for each worker. Spreading restarts over time avoids every worker reloading at once. If RAM usage increases over time, lower --max-requests before you lower worker count.

For more information, see the Scaling Langflow blog post.