How to Set Concurrency Limits in n8n

Before setting a concurrency limit, assess how many parallel executions your server can handle. Check your available RAM and CPU cores. A general rule of thumb is to allow 1-2 concurrent executions per CPU core for CPU-bound workflows, or 5-10 per core for I/O-bound workflows that mostly wait on HTTP requests. If your workflows call LLM APIs, they are I/O-bound and can tolerate higher concurrency. If they process large files or run heavy Code nodes, keep concurrency lower. Monitor your server's memory usage during peak load to find the sweet spot.

Add the N8N_CONCURRENCY_PRODUCTION_LIMIT variable to your environment configuration. For Docker deployments, add it to your docker-compose.yml under the environment section. For npm-based installations, add it to your .env file in the n8n data directory. The value is an integer representing the maximum number of production workflow executions that can run at the same time. Set it to -1 to disable the limit entirely (the default behavior). Any value of 1 or higher enables the queue.

1# docker-compose.yml
2version: '3.8'
3services:
4  n8n:
5    image: docker.n8n.io/n8nio/n8n
6    ports:
7      - '5678:5678'
8    environment:
9      - N8N_CONCURRENCY_PRODUCTION_LIMIT=5
10      - DB_TYPE=postgresdb
11      - DB_POSTGRESDB_HOST=postgres
12      - DB_POSTGRESDB_DATABASE=n8n
13      - DB_POSTGRESDB_USER=n8n
14      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
15      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
16    volumes:
17      - n8n_data:/home/node/.n8n
18
19# Or in .env file for npm installations:
20# N8N_CONCURRENCY_PRODUCTION_LIMIT=5

The concurrency limit is read at startup and cannot be changed at runtime. Restart your n8n instance for the new setting to take effect. For Docker Compose deployments, run docker compose down followed by docker compose up -d. For npm installations, stop the n8n process and start it again. For systemd-managed installations, use systemctl restart n8n. After restarting, check the n8n logs to confirm the concurrency limit was applied. n8n logs a message at startup indicating the production concurrency limit.

1# Docker Compose
2docker compose down && docker compose up -d
3
4# npm / systemd
5systemctl restart n8n
6
7# Check logs for confirmation
8docker compose logs n8n | grep -i concurrency

Create a simple test workflow with a Webhook trigger node and a Wait node set to 10 seconds. Activate the workflow and send multiple simultaneous requests to the production webhook URL using curl or a tool like Apache Bench. Send more requests than your concurrency limit to verify that excess executions are queued rather than rejected. Open the n8n Executions panel to observe that only N executions run at a time while the rest wait in the queue.

1# Send 10 simultaneous requests to test a limit of 5
2for i in $(seq 1 10); do
3  curl -s -X POST https://your-n8n.example.com/webhook/test-concurrency \
4    -H 'Content-Type: application/json' \
5    -d '{"request_number": '"$i"'}' &
6done
7wait
8echo "All requests sent"

After running under the concurrency limit for a few days, review execution patterns to fine-tune the value. Check the Executions panel for executions that spent excessive time in the queue, which indicates the limit is too low. Also check server resource usage to see if there is headroom to increase the limit. If webhook callers time out waiting for responses, you may need to increase the limit or switch the Webhook node's response mode to Immediately so callers get a fast acknowledgment while the workflow runs in the background.