n8n Queue Mode Unsupported Node Version Error

 

 

Who this is for: System administrators, DevOps engineers, and n8n power‑users who run Queue Mode in production and need to resolve the Node.js version blocker. We cover this in detail in the n8n Queue Mode Errors Guide.

Quick Diagnosis

Step	Command	Result
1	node -v	Shows the current runtime version
2	nvm install 18 && nvm use 18 *(or your platform‑specific upgrade)*	Upgrades Node to a supported LTS
3	systemctl restart n8n *(or pm2 restart n8n / Docker restart)*	Reloads n8n with the new binary
4	Re‑trigger the workflow	The “unsupported version” error disappears

1. Why Queue Mode needs a modern Node runtime

If you encounter any n8n queue mode unsupported redis version resolve them before continuing with the setup.

Queue Mode uses native Node APIs that were added in later LTS releases. When the runtime is too old, n8n aborts early to protect job integrity.

1.1. Redis‑backed queue (default driver)

Feature	Introduced in n8n	Minimum Node
Async‑local‑storage support	0.150.0	14.15.0
AbortController usage	0.150.0	14.15.0

1.2. BullMQ worker pool (optional driver)

Feature	Introduced in n8n	Minimum Node
worker_threads enhancements	0.165.0	16.0.0
EventTarget polyfill removal	0.165.0	16.0.0

Note – If you switch drivers, the higher of the two minima applies.

2. Identify the exact Node binary used by n8n

If you encounter any n8n queue mode legacy version bug resolve them before continuing with the setup.

2.1. Systemd service

# Show the ExecStart line
systemctl show -p ExecStart n8n.service

Typical output

ExecStart=/usr/local/bin/node /usr/local/lib/node_modules/n8n/dist/main.js

2.2. Verify the binary’s version

/usr/local/bin/node -v

EEFA tip – In Docker the binary lives inside the container, so run docker exec <container> node -v instead of checking the host.

3. Upgrade Node for common deployment styles

Deployment	Recommended method	Upgrade commands
APT (Ubuntu/Debian)	NodeSource repo	curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash - sudo apt-get install -y nodejs
nvm (local dev)	Switch to LTS	nvm install --lts nvm use --lts
Docker (official image)	Pull newer tag	docker pull n8nio/n8n:latest
PM2 (production)	Reinstall binary globally	npm install -g n sudo n lts pm2 restart n8n
Heroku	Declare engine in package.json	{   "engines": { "node": ">=18.x" } }

3.1. Confirm the upgrade

node -v
# Expected output, e.g.: v18.17.0

After upgrading, restart the n8n process so the new binary is used.

4. Re‑enable Queue Mode post‑upgrade

4.1. Verify queue driver configuration

cat ~/.n8n/config

Sample excerpt

QUEUE_MODE=redis
REDIS_HOST=redis.internal

4.2. Reset internal queue tables

n8n reset --queue
# Docker equivalent
docker exec -it n8n n8n reset --queue

4.3. Start n8n in Queue Mode (if not default)

n8n start --queue

4.4. Smoke‑test with a simple workflow

curl -X POST http://localhost:5678/webhook-test \
     -H "Content-Type: application/json" \
     -d '{"trigger":"test"}'

Watch the logs for a clean start:

# Systemd
journalctl -u n8n -f
# Docker
docker logs -f n8n

You should see Queue worker started and no version‑related errors.

5. Troubleshooting checklist

Step	What to check	How to verify
Node version	Runtime meets minimum	node -v ≥ required (see §1)
Binary path	Service points to upgraded binary	systemctl cat n8n.service → ExecStart
Queue driver env	Correct QUEUE_MODE value	printenv | grep QUEUE
Backend reachable	Redis/Postgres reachable from host	nc -zvw3 redis.internal 6379
Cache cleared	Old compiled files removed	Run n8n reset --queue
Docker tag freshness	Image not stale	docker images n8nio/n8n – check CREATED date
PM2 config	Node version forced per app	cat ecosystem.config.js → node_args

Address any failing step before re‑testing the workflow.

6. EEFA (Expert, Experience, Fact, Authority) insights

• Pin the Node LTS version in CI/CD (e.g., node:18-alpine Docker base). This avoids accidental roll‑backs when a teammate uses an older global Node.
• Never forget to rebuild the Docker image after a host‑side Node upgrade; the container still runs the old runtime until rebuilt (docker compose build --no-cache).
• Why the error surfaces after an n8n upgrade – New queue features depend on APIs that older runtimes lack. n8n deliberately blocks start‑up to prevent silent data loss.

Conclusion

Queue Mode relies on modern Node.js APIs; running n8n on an outdated runtime triggers a clear “unsupported version” error. By pinpointing the exact binary, upgrading to a supported LTS (≥ 14.15.0 for Redis driver, ≥ 16.0.0 for BullMQ), resetting the queue state, and confirming connectivity, you restore reliable background job processing in production. Keep the Node version pinned in your deployment pipeline to avoid repeat incidents.