Every request builds a graph that never gets freed. Here is why Flowise leaks memory, and the configuration changes that stop it.

The Problem

Flowise is straightforward to run locally. In production under real traffic, many teams hit the same issue: RAM climbs steadily with each request, latency increases, and eventually the server runs out of memory and crashes. On Render, Railway, and similar platforms, this triggers an automatic restart -- and users see errors or timeouts.

The root cause: by default, Flowise rebuilds the LangChain graph for every request and does not aggressively free the memory used. With concurrent users or high request rates, unreleased graph instances accumulate in heap memory.

This is a known architectural issue tracked across multiple Flowise GitHub issues. The fixes below are workarounds that significantly reduce the problem, but very high traffic (50+ concurrent users) may still require horizontal scaling with Redis caching enabled.

Fix 1: Enable Flow Caching

Flowise supports caching the compiled flow graph so it does not rebuild it from scratch on every request. This is the single highest-impact configuration change for memory and latency.

Set the following environment variable before starting Flowise:

# Add to your .env or deployment environment variables
 
# Cache compiled flows in memory (reduces rebuild overhead)
FLOWISE_CACHE_TYPE=memory
 
# Optional: limit cache size (number of flows to keep in cache)
FLOWISE_CACHE_SIZE=50
 
# If using Redis for horizontal scaling:
# FLOWISE_CACHE_TYPE=redis
# REDIS_URL=redis://your-redis-host:6379
If you are running a single Flowise instance, memory caching is sufficient and has zero infrastructure overhead. Only move to Redis if you need multiple Flowise instances behind a load balancer.

Fix 2: Set Node.js Memory Limits

Node.js has a default heap size limit of approximately 1.5GB (varies by version and platform). If your server has more RAM available, increasing this limit gives Flowise more headroom before it crashes -- buying time while you implement the other fixes.

# Set Node.js max heap size (e.g. 4GB)
export NODE_OPTIONS="--max-old-space-size=4096"
npx flowise start
 
# Or in Docker:
FROM flowiseai/flowise:latest
ENV NODE_OPTIONS="--max-old-space-size=4096"
ENV FLOWISE_CACHE_TYPE=memory
ENV FLOWISE_CACHE_SIZE=50
CMD ["npx", "flowise", "start"]

Fix 3: Configure a Process Manager with Auto-Restart

Given that memory leaks are partially inherent to Flowise's current architecture, the pragmatic production approach is: configure automatic restarts when memory exceeds a threshold. PM2 makes this straightforward.

// ecosystem.config.js (PM2 configuration)
module.exports = {
  apps: [{
    name: 'flowise',
    script: 'node_modules/.bin/flowise',
    args: 'start',
    env: {
      NODE_ENV: 'production',
      NODE_OPTIONS: '--max-old-space-size=4096',
      FLOWISE_CACHE_TYPE: 'memory',
      PORT: 3000,
    },
    // Auto-restart when memory exceeds 3GB
    max_memory_restart: '3G',
    // Restart delay to prevent rapid crash loops
    restart_delay: 5000,
    // Keep logs
    out_file: './logs/flowise-out.log',
    error_file: './logs/flowise-err.log',
  }]
};
# Start with PM2
pm2 start ecosystem.config.js
pm2 save
pm2 startup  # auto-start on server reboot

Fix 4: Use the Queue for High-Traffic Deployments

For deployments receiving more than 10 concurrent requests, enable Flowise's built-in queue mode. This serialises requests through a worker queue instead of handling them all simultaneously, preventing memory spikes from burst traffic.

# Queue mode requires Redis
FLOWISE_QUEUE_ENABLED=true
REDIS_URL=redis://localhost:6379
 
# Optional: limit concurrent workers
FLOWISE_QUEUE_CONCURRENCY=5
Queue mode was still marked experimental in early 2026 (GitHub Issue #4824). Test it thoroughly in staging before enabling in production. Monitor queue depth to ensure workers are keeping up with request volume.

Monitoring Memory in Production

The single most useful thing you can add alongside these fixes is basic memory monitoring. Know when your server is approaching the limit, before it crashes.

# Simple bash monitor -- add to a cron job (every 5 min)
#!/bin/bash
THRESHOLD=80  # percent
MEM_USAGE=$(free | awk '/Mem:/ {printf "%.0f", $3/$2 * 100}')
if [ "$MEM_USAGE" -gt "$THRESHOLD" ]; then
  echo "WARNING: Flowise host memory at ${MEM_USAGE}%" | \
    curl -X POST -H 'Content-type: application/json' \
    --data "{"text":"Flowise memory alert: ${MEM_USAGE}%"}" \
    "$SLACK_WEBHOOK_URL"
fi

Production Checklist

  • Set FLOWISE_CACHE_TYPE=memory (or redis for multi-instance)
  • Set NODE_OPTIONS=--max-old-space-size=4096 (or appropriate to your server RAM)
  • Use PM2 with max_memory_restart as a safety net
  • Enable queue mode (FLOWISE_QUEUE_ENABLED=true) for high-concurrency deployments
  • Add memory monitoring with alerts before the crash threshold
  • Test with realistic concurrent load in staging before going live