Version: 1.14.x (Next)

Best practices for Langflow on Kubernetes

This guide provides best practices for deploying Langflow in production environments on Kubernetes.

Resources and scaling

Langflow's minimum resource requirements vary by deployment type:

IDE (development): Deploy both the Langflow visual editor (frontend) and API (backend). Typically, this is used for development environments where developers use the visual editor to create and manage flows before packaging and serving them through a production runtime deployment.

The frontend service requires a minimum of 512Mi RAM and 0.3 CPU per instance with 1 replica.

The backend service requires a minimum of 1Gi RAM and 0.5 CPU per instance with 1 replica.
Runtime (production): Deploy the Langflow runtime for production flows, which is headless (backend only) service focused on serving the Langflow API. This is used for production environments where flows are executed programmatically without the need for the visual editor.

Minimum requirements include 2Gi RAM and 1000m (1 CPU) per instance with 3 replicas.

For more information about Langflow deployment types, see Langflow architecture on Kubernetes.

Estimate, test, and adjust

Start with the minimum recommended resources and replicas, then monitor and scale as needed based on your deployment's requirements and performance testing. Consider the following factors in your resource estimation and performance testing:

Flow complexity.
Volume of concurrent users and requests.

For IDE (development) deployments, consider that frontend activity also pings the backend service, so you typically need to scale both the frontend and backend together.
Request payload content and size, particularly for file uploads in production deployments.
Storage requirements for cache, file management, and the Langflow database.

An external PostgreSQL database is recommended for production deployments.
Infrastructure options that might require more resources, such as multi-core CPUs.

Use an external PostgreSQL database

An external PostgreSQL database is recommended for production deployments to improve scalability and reliability as compared to the default SQLite database.

Your resource allocation and replication strategy must be able to support the PostgreSQL service and storage. For example, for a runtime (production) deployment, you might allocate 4Gi RAM, 2 CPU, and multiple replicas for high availability. Tune PostgreSQL parameters, such as work_mem and shared_buffers, as needed based on resource requirements and usage metrics.

Recommended configurations include:

Persistent storage to prevent data loss on container shutdown
High Availability (HA) or Active-Active for automatic failover, scaling, and load balancing
Shared databases for multi-instance deployments
Shared storage, such as NFS or cloud storage, for multi-instance deployments to access large files stored on disk, such as in /opt/langflow/data/.

For more information, see Configure an external PostgreSQL database and Langflow database guide for enterprise DBAs.

Use HPA for dynamic scaling

Load balancing and dynamic scaling are recommended for runtime (production) deployments.

For example, consider using Horizontal Pod Autoscaler (HPA) in Kubernetes to dynamically scale based on CPU or memory usage. The following example shows a Langflow HPA configuration with CPU-based scaling:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: langflow-runtime-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: langflow-runtime
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 80

Failure points

Langflow's reliability in production depends on mitigating key failure points, particularly around the database, file system, and instance availability:

Database failures: See Langflow database guide for enterprise DBAs.
File system failures: Concurrency issues in file caching, such as /app/data/.cache, can cause IO errors in multi-instance setups. To avoid this, use a shared, POSIX-compliant file system or cloud storage. Use persistent volumes instead of ramdisk solutions that result in data loss on container shutdown.
Instance failures: Deploy multiple replicas to avoid service disruptions when a single instance fails. Use health checks to detect and replace failed pods.
Network and dependency failures: External APIs or services used in flows may fail, causing flow errors. Implement retry logic and error handling in flows or application code. Monitor network latency and dependency health.

Monitoring

Effective monitoring ensures Langflow operates reliably and performs well under varying loads:

Database monitoring: See Langflow database guide for enterprise DBAs.
Application logs: Collect and analyze logs for errors, warnings, and flow execution issues. Centralize logs using tools like ELK Stack or Fluentd. You can also inspect Langflow logs.
Resource usage: Track CPU, memory, and disk usage of Langflow instances. Use Prometheus and Grafana for real-time metrics collection and monitoring in Kubernetes.

To expose your Langflow server's Prometheus metrics, set LANGFLOW_PROMETHEUS_ENABLED=True (the default is false). The default port for the Prometheus metrics is 9090. To change the port, set LANGFLOW_PROMETHEUS_PORT.

With Prometheus enabled, Langflow also exports background job metrics prefixed with langflow_bg_: counts of queued, running, and suspended jobs, the age of the oldest queued job, cumulative started, completed, and failed totals, and p50 and p95 submission-to-finish times for jobs finished over the last five minutes. These durations include queue wait and time suspended on human input. The percentile gauges use a fixed window and cannot be combined into a percentile over a different window or across independent databases. Only the process that serves the Prometheus port collects them. Gauges refresh every 15 seconds by default; to change that interval, set LANGFLOW_BACKGROUND_METRICS_INTERVAL to a number of seconds greater than zero. All-time totals refresh on the first tick and then on the first tick at least five minutes after the previous successful refresh, reducing full-history scans. Use rate windows longer than this refresh cadence. Retention archives background outcome counts in the database in the same transaction that deletes the jobs. Totals include both retained jobs and that archive, so retention does not hide new completions or lower the baseline after a restart. Archiving also runs when Prometheus is disabled. Counters preserve the largest count observed per label set during the process lifetime, so terminal-state corrections do not appear as counter resets. They remain sampled job outcomes rather than an exact event ledger, and terminal-state corrections can change the baseline on restart. Jobs deleted before this version cannot be recovered. During a rolling upgrade, keep retention disabled until all processes that run the sweep use this version. Failed totals distinguish error, worker_lost, input_timeout (an expired human-input deadline), timeout (an execution timeout), and cancelled. With multiple replicas sharing a database, each replica exports the same database-wide snapshot and adds collection load. Scrape one replica for these metrics or deduplicate with max while retaining the backend, status, and reason labels where present; summing replicas multiplies the counts.
API performance: Monitor response times, error rates, and request throughput. Set alerts for high latency or error spikes.
Observability tools: Integrate with LangWatch or Opik for detailed flow tracing and metrics. Use these tools to debug flow performance and optimize execution.

Security

Running Langflow in production requires robust security measures to protect the application, data, and users. Follow industry best practices and use secure Langflow configurations, such as the following:

Container security: Apply security best practices for containerized applications. For example, set readOnlyRootFilesystem: true in runtime (production) containers to prevent unauthorized modifications. Restrict access to files and codebases containing sensitive data and configuration files that shouldn't be exposed to unauthorized users.
Secrets management: Store sensitive data like API keys and PostgreSQL credentials in Kubernetes secrets or external secrets managers like HashiCorp Vault.
Authentication, authorization, and access control: Start your Langflow server with authentication enabled, as explained in API keys and authentication. Restrict network and resource access with firewalls, network policies, network security groups, or VPCs. For example, restrict PostgreSQL database access to Langflow instances.
Encryption and privacy: Follow industry best practices and legal requirements for data privacy and encryption of data in transit and at rest, including GDPR requirements, HTTPS, TLS, and SSL. For example, configure PostgreSQL with valid SSL certificates and append ?sslmode=require or ?sslmode=verify-full to the connection string to enable SSL for database connections.
Security posture maintenance: Conduct regular security audits, keep current with software updates, and monitor for suspicious activity using intrusion detection systems.

Production preflight checks

To verify production infrastructure before any workers start, set the LANGFLOW_DEPLOYMENT_PROFILE environment variable to prod.

By default, LANGFLOW_DEPLOYMENT_PROFILE is set to dev and skips these checks. When set to prod, Langflow runs every check once and prints the full result. A fail aborts boot with a non-zero exit, so a misconfigured server never starts up. A warn does not abort and allows startup.

Preflight checks run for any Langflow process started with the prod profile enabled, not only Kubernetes.

To enable preflight checks, set the following in your .env file:

LANGFLOW_DEPLOYMENT_PROFILE=prod

Alternatively, pass the CLI option, which overrides the environment variable:

uv run langflow run --deployment-profile prod

Required checks

These checks abort boot when they fail:

Check	What must be true
Database	`LANGFLOW_DATABASE_URL` is a reachable PostgreSQL database. SQLite fails this check.
File storage	`LANGFLOW_STORAGE_TYPE` is an external object store such as `s3`, not local disk.
Encryption secret	`LANGFLOW_SECRET_KEY` is set in the environment to a usable Fernet key. An auto-generated key or a node-local `config_dir/secret_key` file is not enough. See `LANGFLOW_SECRET_KEY`.
pgVector	`PGVECTOR_CONNECTION_STRING` is set, the database is reachable, and the Postgres `vector` extension is installed (`CREATE EXTENSION vector;`). Production Langflow requires pgVector even if you are not creating knowledge bases yet.

Degraded checks

These checks report reduced capability. Telemetry and MCP only warn. Cache and the shared job queue abort boot if you selected an external backend that is unreachable.

Check	`ok`	`warn`	`fail` (aborts)
Cache	`LANGFLOW_CACHE_TYPE=redis` and Redis is reachable	In-memory default (`async` or `memory`). Caches are not shared across replicas.	Redis selected but unreachable. Unset `LANGFLOW_CACHE_TYPE` to boot with the in-memory fallback.
Shared queue	`LANGFLOW_JOB_QUEUE_TYPE=redis` and Redis is reachable	In-process default (`asyncio`). Jobs stay on a single pod.	Redis selected but unreachable. Unset `LANGFLOW_JOB_QUEUE_TYPE` to boot with the in-process fallback.
Telemetry	Product telemetry is enabled	`LANGFLOW_DO_NOT_TRACK` is set	Never fails
MCP serving posture	MCP is disabled, or the serving knobs below match the multi-tenant values	One or more knobs are still at a single-tenant default	Never fails

If this plane does not serve MCP, set LANGFLOW_MCP_SERVER_ENABLED=false. Otherwise, production preflight expects these values when MCP is enabled:

Variable	Expected in `prod`	Default
`LANGFLOW_SKIP_MCP_AUTO_INIT`	`true`	`false`
`LANGFLOW_ADD_PROJECTS_TO_MCP_SERVERS`	`false`	`true`
`LANGFLOW_MCP_COMPOSER_ENABLED`	`false`	`true`
`LANGFLOW_MCP_SERVERS_LOCKED`	`true`	`false`
`LANGFLOW_MCP_SSE_ENABLED`	`false`	`true`
`LANGFLOW_MCP_SERVER_INTERPRETER_HARDENING`	`true`	`false`
`LANGFLOW_MCP_SERVER_DOCKER_HARDENING`	`true`	`false`
`LANGFLOW_SSRF_PROTECTION_ENABLED`	`true`	`true`
`LANGFLOW_CONNECTOR_SSRF_VALIDATION_ENABLED`	`true`	`true`
`LANGFLOW_CONNECTOR_SSRF_ALLOW_LOOPBACK`	`false`	`true`
`LANGFLOW_DISABLE_TRACK_APIKEY_USAGE`	`true`	`false`
`LANGFLOW_MCP_SERVER_ALLOWED_PACKAGES`	Set to an allowlist (empty string blocks all package runners)	Unset
`LANGFLOW_MCP_SERVER_ENV_ALLOWLIST`	Set to an allowlist (empty string blocks all tenant-supplied environment variables)	Unset

Knowledge and Memory storage

Langflow 1.13 uses local SQLite storage by default. Local storage is intended for a single host with one worker. With LANGFLOW_DEPLOYMENT_PROFILE=prod, Langflow refuses to create knowledge bases and memory bases on local SQLite. For deployments with multiple workers or replicas, configure a shared pgVector or OpenSearch store. Chroma local storage and Chroma Cloud are retired. For existing stores, see Upgrade Knowledge and Memory storage.

Resources and scaling​

Estimate, test, and adjust​

Use an external PostgreSQL database​

Use HPA for dynamic scaling​

Failure points​

Monitoring​

Security​

Production preflight checks​

Required checks​

Degraded checks​

Knowledge and Memory storage​

See also​