Way to Handle Workflow Version Drift Across Multiple

Questions
1

Hi I’m running multiple n8n workers behind a load balancer, and I’ve started noticing strange behavior during deployments/updates.Load Balancer
↓
Multiple n8n Workers
↓
Queue Mode + Shared DB
The issue is that during workflow updates:
• Some executions seem to run the old workflow version
• Others pick up the new version immediately
• Long-running executions behave inconsistently after deployment
This becomes especially noticeable with:
• Queue mode
• Multiple active workers
• Long-running workflows
• Deployments during active processing
For example:
• Worker A processes Step 1 with old logic
• Deployment happens
• Worker B continues Step 2 with new logic
which can create inconsistent state or unexpected behavior.
I’m trying to figure out the best production strategy for:
• Safe workflow deployments
• Version consistency across workers
• Handling long-running executions during updates
• Avoiding mixed-version processing
I’ve considered:
• Draining workers before deploy
• Versioned workflows
• Blue/green deployments
• Queue pausing during rollout
For teams running n8n at scale:
• How are you handling workflow version consistency during deployments?

Describe the problem/error/question

What is the error message (if any)?

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

Information on your n8n setup

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:
2

Hi @Emmas This is a common issue in multi-worker setups, especially with long-running workflows. The main problem is that deployments can happen while executions are still running, so different workers may use different workflow versions during the same execution. Most teams avoid this by using:Versioned deployments + worker draining

Before deploying:
Stop new jobs from entering workers
Let current executions finish (“drain”)
Deploy the new version
Then resume processing

A lot of teams also:Use separate/versioned workflows
Keep old executions on old workflow versions
Route new jobs only to the new version

Try to avoid deploying directly during heavy active processing without draining queues first.

3

Adding a specific n8n mechanism for the draining step: set N8N_GRACEFUL_SHUTDOWN_TIMEOUT (e.g. 300000 for 5 minutes) on your workers before doing a rolling restart. When n8n receives SIGTERM, it stops picking up new jobs and waits up to that timeout for in-flight executions to finish. Combined with a rolling deploy (take down one worker at a time, not all at once), this eliminates the mid-execution version split. For the versioned workflow approach Niffzy mentioned - in practice the cleanest implementation is keeping a v1 and v2 workflow active simultaneously, routing new webhook events to v2 while old queue items finish on v1, then deactivating v1 once its queue drains.

4

Thanks @Niffzy @nguyenthieutoan Got it fix through version workflow