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 (including worker memory growth reports such as Issue #5059). The fixes below reduce the problem, but very high traffic (50+ concurrent users) may still require horizontal scaling with Redis-backed queue mode across multiple instances.

Fix 1: Know What Flowise Actually Caches

Flowise does not have a “flow graph cache” you can enable with an environment variable — FLOWISE_CACHE_TYPE and FLOWISE_CACHE_SIZE are not real Flowise settings. The Cache nodes you can add to a canvas (In-Memory Cache, Redis Cache, Upstash Redis Cache, Momento Cache) cache LLM prompt/response pairs to cut duplicate API calls — they do not cache or reuse the compiled flow graph, and will not fix the RAM growth described above.

The highest-impact configuration changes for memory are the ones below: a Node.js heap limit, a process manager that restarts on high memory, and queue mode for high-concurrency deployments.

# Add to your .env or deployment environment variables
 
# Flowise has no FLOWISE_CACHE_TYPE / flow-graph cache env var --
# LLM response caching is configured via a Cache node in the canvas UI.
 
# For memory stability under load, run Flowise in queue mode instead:
MODE=queue
 
# Queue mode requires Redis:
REDIS_URL=redis://your-redis-host:6379
WORKER_CONCURRENCY=5
If you are running a single Flowise instance, you likely don't need Redis at all — it's only required for queue mode (MODE=queue) or once you're running multiple instances behind a load balancer and need workers to share a job queue.

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"
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',
      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
MODE=queue
REDIS_URL=redis://localhost:6379
 
# Optional: limit concurrent workers
WORKER_CONCURRENCY=5
As of mid-2026, Flowise's own production guide recommends running in queue mode (separate main and worker instances) rather than treating it as experimental. Still, test thoroughly in staging before enabling in production — worker memory growth under sustained load is a known, still-open issue (see GitHub Issue #5059). 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

  • There is no FLOWISE_CACHE_TYPE setting — rely on the heap limit, PM2 restart, and queue mode below for memory stability
  • 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 (MODE=queue, REDIS_URL, WORKER_CONCURRENCY) for high-concurrency deployments
  • Add memory monitoring with alerts before the crash threshold
  • Test with realistic concurrent load in staging before going live